In relation to this topic two very important topics come to mind that would be a logical extension of what I have talked about. The first one being the most obvious one;
Internal vs External
Because of the authority we could leverage to our external users and partners, the lessons-learned and practices have been very well implemented throughout the entire ecosystem of our solutions.
The irony would have that for the internal users, clients, stakeholders this dynamic is different. Of course we implemented the 2-week sprints, and the UX/UI driven prototypes. Yet the connection of the original vision of the product and the business needs stays an ongoing challenge. The key issue here in my personal view is mostly the dynamic between the two teams. At the current time the developers seem more like the requesters than the users they are building the solution for, due to lack of concrete input for the details of the end-result. This mostly requires some changes in processes surrounding the sprint planning and roadmapping, but also a sort of culture change where we set shorter-term, concrete goals and let go of a kind of perfectionism. Which leads me to the second point
There is a variety of slogans surrounding failing fast, and with good reason. Over the last 18 months I have also spent significant effort changing the dynamic and mindset of the team from a perfectionist, 100% complete, 100% sure mindset to a more agile, progress is progress mindset. Something that I will also elaborate on a little further in a next article.
The current shorter sprint format allow us to make necessary adjustments as we go, meaning we can start with lower fidelity products and start improving them right away. Historically once a project was finished resources would immediately be allocated to other (very important or longer term) projects and that which was delivered wouldn’t change over the course of a couple of years. Nowadays every sprint should make incremental improvements to the solutions that matter the most.
It might mean that we need to be flexible and allow our focus to shift from project to project, or solution to solution a lot more times than we historically had to with our monolithic approach. But isn’t that the textbook definition of agile?