Risk management for agile projects

What are the implications to project risk management when you choose to deliver a project using an agile approach?

Here are a few similarities:

Risk needs to be managed through the project’s lifetime, not just at the very beginning. Even though the team might tackle high risk requirements earlier in the life of an agile project than they might a traditional one, this doesn’t mean that they shouldn’t keep an eye on threats and opportunities through late stage iterations.

Risk bias and appetite need to be assessed when managing risks. How a team, risk owner or sponsor will identify or respond to risk is tied to their individual perceptions. Influencing stakeholders to ensure that risk gets effectively managed is a critical skill for both a project manager and a Scrum Master.

Multiple perspectives need to be considered when identifying risks. Risk is a many dimensioned thing – using a single checklist, consulting a single group of stakeholders or only focusing on one source of risks is likely to leave the project exposed to threats from multiple angles. Technology, operations, change and stakeholders are just some of the potential sources of risk which need to be evaluated.

And some differences:

Close involvement of customers and key control partners throughout the life of a project increases the likelihood of effectively identify and manage emergent risks. Unlike on a traditional project where certain stakeholders will only be present at the beginning and the end of a project, on an agile project, ongoing involvement through multiple iterations provides the opportunity to better incorporate multiple perspectives.

The impact of operational risks is likely lower as expected changes are correspondingly smaller but are likely to be more frequent. Rather than having one or two “big bang” releases which will result in significant changes in the procedures or behaviors for impacted stakeholders, agile projects will deliver change incrementally.

Planning ceremonies at the beginning of each iteration and retrospectives at the end provide the team with a regular opportunity to consider risk. While the use of a risk register is a good practice regardless of whether an agile or traditional approach is used, having a watch-list of key risks in the team war room or online collaboration site will help to keep the level of vigilance high.

Risk should be a key input into back log refinement. Requirements which are critical to achieving the business outcomes but contribute significant risk should be tackled early in the life of the project in support of the principle of failing fast. Those which are nice-to-haves but are very risky might be de-prioritized or eliminated to help reduce the project’s overall risk profile.

Risk management is an important discipline regardless of the approach taken to complete a project. But as with all PMBOK knowledge areas, how it is applied needs to be tailored to fit the context of a project, the maturity and culture of the team and the organization.