I have often been asked a question about why people rarely talk about a formal risk management process with Agile. From my own long coaching experience, I have given a lot of reasons and examples to answer this question but decided to pick the following five as being the most important and relevant for Project Management.
- Customer involvement in the development and delivery process
One of the biggest risks when it comes to software projects is related to customers and related stakeholders feeling that the delivered software does not meet their expectations. Too many issues come up in acceptance testing delaying product deployment. One of the programs that I coached several years ago moved from conventional working to Scrum. They were doing several releases of their product every year and their biggest challenge related to too many critical issues in the first month after release. When they moved to Agile/Scrum, we observed that they had no critical issues in the first month following a release for four consecutive releases. The customer who was skeptical about Agile initially was obviously delighted. While there were a number of reasons for this outcome, one significant reason was stakeholder / customer involvement both early on as well as for every iteration to prioritize requirements as well as for the show and tell sessions during and at the end of every iteration. This is a default way of working with Agile and hence one does not need to plan and track such actions as mitigations for risks.
2. The Product Owner role
One major risk upfront during planning for software projects or product releases has to do with too many conflicts in requirements from different stakeholders and no effective way to deal with them. Project managers are often caught up in trying to satisfy all different stakeholders and end up not satisfying any of them. This is where the role of the Product Owner (PO) in agile is significant. The PO is expected to work with different stakeholders on their requirements, resolve conflicts and come up with a prioritized list of requirements / features for the development teams to work with. Dealing with trade-offs between scope and schedule is the responsibility of the PO. And POs play an important role in bridging the gap between the customer’s expectations and the development team’s implementation of the requirements. The key is to obviously understand the importance of the role and ensure the right person with the right skills is given the PO role.
3. Collaboration within and across teams
Too many risks in software projects concern ineffective collaboration among development, QA and other functions as well as ineffective dependency management across teams / programs. Delayed and late deliveries to QA, strong boundaries in working across functions and programs, poor communication among the various cross-functional teams are major reasons contributing to poor quality, delays in delivery and frustrated customers. With Agile, collaboration is a core value and cross-functional working for planning as well as day-to-day execution and tracking are default practices that mitigate these risks naturally. Constructs such as release planning help plan and manage dependencies across teams, and practices such as daily stand-ups expose risks early with effective team involvement and collaboration helping in addressing them before they become issues. In the customer example I had given before, good collaboration between dev and QA was one of the significant factors that contributed to high quality product releases.
4. Early and continuous testing
Test cycles and duration are unpredictable in most typical conventional software projects. Late and exhaustive testing towards the end of the delivery life cycle catches unexpected issues impacting both costs and schedule. Most projects plan this as a risk and use in-process reviews, early testing and shift-left strategies as mitigation actions to deal with them. With agile, delivery of working software in each iteration is a default practice and early and continuous testing ensures you don’t have too many issues to address at the end. Investment in automated testing ensures consistent, repeatable tests as well as testing that would be more cost effective.
5. How progress during development is measured
Most software projects measure progress based on % of activities or effort completed against the plan. The inherent risk with this method of tracking is the 90% complete syndrome where the last 10% of the work seems to take for ever to complete. Projection of project end date based on this often goes awry causing the PM and team long and sleepless nights towards the end of the project to ship the product. Quality often gets compromised in the process. Agile deals with this risk through short, focused iterations to deliver working software and by measuring progress only against completed functionality (burn down / burn up of features / stories) so at any point in time measured progress is real progress and delays are seen well in advance. As a result, you also have an option of negotiating trade-off on scope vis-à-vis schedule with the customer through the PO.
Among other things that I have seen that reduce risks has to do with the way Agile deals with complexity through practices such as size estimates based on complexity, use of spikes etc.
What we have seen in essence, through these five reasons, is how risk management is inherently built into the principles and practices of working with Agile. The focus with Agile shifts to helping the teams and management internalize Agile values and principles (which defines the spirit of agile) so the stated practices are more effectively implemented.
So, are there any risks to be managed explicitly with Agile at all?
The answer is yes but these represent a relatively smaller number and include aspects such as skill issues in teams, resource constraints such as those related to people, hardware etc., lack of investment in training, automation, CI/CD implementation – all of which can contribute to risks that need to be dealt with.
JV
