Agile Risk Management

September 21, 2007

Risk Management processes may have the air of a traditional, process-driven project management activity. However, agile methods are great risk reduction vehicles, and are actually very well aligned for rapid risk identification and reduction.

What is a Risk?
A risk is some event or circumstance that could transpire and impact the project. The PMBOK talks about good risks (opportunities), but most risk literature focuses on events with potential for negative impacts (project risks). The risk management process outlined in the PMBOK is shown below:

Wheres the Risk Response Doing Step?

One step absent from this process is a Risk Response Doing step that focuses on

executing the actions identified in the risk mitigation plan. In the defense of the PMBOK, these activities get moved to the project plan and scheduled with the regular work activities. However the apparent lack of a doing step mirrors a problem seen on many projects. Namely, that risk management is undertaken as a separate (sometimes once only) passive activity that does not drive enough action on the project to prevent the risk happening. As a result we see risks occurring and can point to the risk list to where it was identified, yet not enough was done to prevent it happening.

Agile Risk Reduction

The iterative nature of agile projects allow us to tackle high risk areas of the project sooner rather than later. This gets problems out in the open while there is still plenty of time and budget to work on them and reduces the effort invested in work that needs scrapping.

Agile projects are said to be business value and risk driven. This means that we choose practical bundles of work based on priority assigned by the business and tackling the remaining high risk items left in the prioritized feature list (Product Backlog). So if we have stories with residual risk we would want to move that up the queue and undertake it as soon as possible. Making this balance tradeoff between business value and risk mitigation value was the subject of the Smart Planning post . Both can be attributed a dollar value for objective comparison, but most project teams perform a subjective comparison based on discussions and trade-offs.

Agile Risk Management Steps

The process for finding, sifting, sorting and creating resolution plans for risks on agile projects remains close to those of traditional projects. The traditional steps of assigning Probability and Impact scores to risks and then calculating Severity as their product should still be undertaken. However, while the basic mechanics are the same, how the process integrates into the lifecycle and the frequency of running the process varies considerably.

Repeat Every Iteration

The risk management process is repeated every iteration. As part of the iteration retrospective the remaining risks can be reviewed and the probabilities and impacts validated. The team can be asked to identify new risks and remaining features that still carry risk identified for selection in the next iteration.

Listen for Potential Risks at the Stand-Up

Daily stand-up meeting are an excellent source for potential risks identification. Todays issues and blockers could become tomorrows risks and problems for the project. So it is important to pay attention to the issues being raised and transfer any appropriate issues to the risk list and undertake the necessary risk assessment steps.

Agile Risk Management Strategies

Actively attack the risks before they can impact the project. Look for remaining risks and find ways to mitigate them in the next iteration. Think beyond just technical risks and consider the business and HR based risks too. For instance: Not sure if the sponsor is committed to the project? Try ordering that expensive kit you need and see if they approve it Or Not sure if the DBA group is on board with working with an agile team? Then move up your database work and try some, see if there really are problems. Be careful; use your common sense, but look beyond just technical risks. Maintain a risk burn down graph Track progress on risk reduction via a risk burn down graph. These useful graphs summarize the risk profile for the entire project and can be used to illustrate new and escalating risks. They are also useful for showing the progress made in early iterations where more work was done on architectural risk reduction rather than purely delivering business functionality. See this post on Creating Risk Profile Graphs

Conclusion
Agile methods are adaptive; they have checkpoints and review questions hard-wired into their processes to allow us change the project approach to fit our evolving environment. We can also use these checkpoints to manage and reduce project risk. With an awareness of the risks as we continually re-plan the project we can adapt the plan to also incorporate risk reduction activities.