Risk management: Agile’s Achilles Heel?

Risk management is sometimes thought to be Agile´s Achilles heel. In this post I discuss how on the contrary, risk management is inherently entwined within Agile.

Risk management in Agile

Risk management is a vast subject that fills many books. As with many modern-day challenges, it is not something that can be managed with the one and most appropriate approach.

On the one hand, Agile-managed projects can benefit from traditional PM methodologies as project managers may engage any techniques available for quantitative and qualitative risk analysis (ROI, EMV, etc.). It can, however, be problematic to fit these procedures into the Agile schedule.

On the other hand, when applied consistently, an Agile framework inherently mitigates risk. Daily stand-ups, Scrum planning meetings and release planning meetings are examples that support risk management. In his book Agile Project Management: Creating Innovative Products, Jim Highsmith outlines five Agile project management techniques that mitigate risk in relation to the project’s schedule:

  • Team involvement in planning and estimating
  • Early feedback on delivery velocity
  • Constant pressure to balance the number and depth of features with capacity constraints
  • Close interactions between engineering and customer teams
  • Early error detection/correction to keep a clean working product

What is more, Agile principles address many risks that frequently lead to project challenges and failure. According to the Standish Group’s 2011 Chaos Report, Agile projects are three times more likely to succeed than traditional projects.

 

Iterations and the concept of failing fast

All Agile methodologies are built on repeated cycles called iterations. The terminology varies depending on the method, but the core concept is solid. Daily routines consist of team progress reviews, development, testing and integration in the preproduction environment.

In every iteration the team develops a selected backlog of requirements. Changes to the requirements are not allowed during the iteration. At the end of each cycle, the outcome is integrated with the preproduction environment and form a product increment.

A set of iterations leads to a release event. In this phase, product increment(s) are deployed to internal or external usage.

Iterations support the concept of failing fast by facilitating early detection of critical problems that may prevent the project from moving forward. This often saves long-term investment of work that leads to useless results.

 

Definition of done

An important risk-reducer in Agile is the concept called definition of done: a set of rules and conditions that specify when a requirement is completed. The Agile team and the product owner agree on the contents of definition of done. Mark C. Layton points out some most common conditions in his book Agile Project Management for Dummies:

  • Developed: The development team must fully create the working product requirement.
  • Tested: The development team must have tested that the product works correctly and is bug-free
  • Documented: The development team must have created notes about how it created the product
  • Integrated: The development team must have ensured that the requirement works in conjunction with the whole product and any related systems

 

Risk burn-down chart

To help the project manager to better understand risk involved, we can use a PM tool called a risk burn-down chart. When registering a particular risk’s severity level, it might be beneficial to present it using a stacked chart. The image below shows five examples of risks tracked using this method:

example of burn-down chart

The most important conclusion is that risk severity levels should decrease over time. Risk burn-down charts can be used in Agile projects for each iterative cycle (sprint) to manage the risks of the project. The virtue of risk analysis is its rapid assessment.

 

Risk-adjusted backlog

The main sources of project risk are assumptions and/or unknowns. By evaluating the risk of items in the product backlog, we may re-prioritize them based on the risk outcome. For example, high impact items with associated risks can be delivered earlier than initially planned. By doing so, the backlog becomes a risk-adjusted backlog.

Conclusion

Whilst traditional PM methodologies may be difficult to fit into an Agile schedule, it is important to remember that Agile approaches inherently reduce risk in product development:

  • Adding or changing user requirements at any time in the project allows one to respond to potential threats or opportunities at any stage
  • Iterative delivery reduces investment-related risk
  • Regular feedback reduces deviations between expectations and the completed product
  • With the concept of definition of done, each sprint ends with a working build and a usable product
  • Early detection of problems supports failing fast

 

Applying Agile correctly, and having skilled people assigned to appropriate responsibilities, should be more than enough to assess and control risks in most cases.

 

Published