Many teams claim to follow agile and lean practices, yet are still challenged to deliver valuable software on a regular basis. Often, agile practices increase the transparency and visibility of the delivery process and, in turn, the intrinsic quality of the produced results. This creates the perception of an agile delivery model from within the system but rarely is the outside perception aligned with that view.
Defining a roadmap with incremental releases is not easy, yet the benefits are significant when done well:
- as valuable functionality is delivered into production, customers can start using it and provide feedback that the team and organization can learn from;
- some of the financial return from the functionality can be generated earlier with only a part of the total investment made, increasing the overall ROI for the initiative;
- smaller releases have fewer moving parts and therefor provide a higher level of control, leading to fewer surprises;
- the functionality and solution are put to a real test, with real customers in a real environment reducing the overall risk for future, potentially more impactful releases.
The importance of the latter two topics cannot be overstated. Smaller releases reduce – assuming appropriate engineering practices are implemented – the risk that something will go wrong during deployment, reducing chances of unplanned downtime, increased operational cost, customer dissatisfaction and negative brand exposure. In fact, risk reduction is an important rationale for organizations embracing agile principles and practices.
Many organizations have a risk management process in place. The idea is that teams following this process have a handle on the actual risks related to the delivery of the product, allowing them to mitigate the risks in a meaningful way or at least to assume a calculated risk instead of an unknown one. More often than not, however, this process is treated as yet another check box that teams spend just enough time thinking about to make it through the compliance gates, but not enough to get meaningful benefits from it. Time wasted and at best, a superficial trust in the risk management process is the result.
But there is a better way. It is possible to leverage your risk management process to drive the roadmap.
Unlike the typical risks; – team members might be reassigned leaving our team with insufficient capacity, our UX designer might not be able to turnaround wireframes fast enough or we might run out of budget – real business and technical risks help define what could be your next most valuable release. It not only makes the risk management process more valuable, it also creates an incentive to spend more effort identifying meaningful risks. In Powerful Roadmaps I explain how this has helped our customers improve their product development, and how you can do it too.
And even if you don’t share this view, consider an alternative view: if your risk management practice is ineffective, an approach that renders it more transparent, directional and thus more valuable might be worth a try.
