Risks are warnings!

Risks are warnings!

Has the adoption of Agile techniques magically erased risk from software projects?  Or have we just changed the mechanism and timing of how we recognize and manage risk?  Or more frighteningly, by changing the project environment through adopting Agile techniques, might we trick ourselves into thinking that risk has been abolished?

Risk is defined as “any uncertain event that can have an impact on the success of a project.” Risk mitigation is about predicting the future.  Does using Agile change our need to predict the future?  I think not.  The difference is with Agile, our time horizon may be as short as one to two weeks, so our need to predict risks (and the future) will be different, but does not change.  What does change is how we approach the topic of risk management.  Instead of a risk management plan and a risk log, a more Agile approach to risk management might be generating additional user stories. The user stories document the risk and will be reviewed during each sprint planning session.

Why change to an Agile approach to risk management in which the team must manage risk? Risk is driven by uncertainty – by what we don’t know, but think we might want to know (or what we don’t know we don’t know).  Whether with a crystal ball or formal process, we need structure to understand uncertainty.  If we don’t embrace an Agile mindset that encompasses the whole software project lifecycle, we will not get the maximum benefit from Agile techniques.

Non-Agile Risk Management Overview:

The classic risk management typically focuses on a big event in which the project or program manager attempts to identify the things he or she doesn’t know (the uncertainties), then to quantify the unknowns so that they can be managed.  This is typically done at the beginning of the project.  Developing the risk management plan would include the following steps:

  • Risk Identification
  • Evaluation
  • Categorization
  • Prioritization

This classic model of risk management that begins with a major event early in the project, perhaps even during chartering, always includes the admonition that the risk management plan is to be revisited . . . periodically . . . maybe . . . hopefully.   Unfortunately, it is very easy for the risk management plan to become shelf-ware, or at the very least only to be reviewed at phase gates.  My experience is that risks are considered FAR too infrequently (usually when they become an issue). Note: the SDLC model that is used, of course, influences the timing and cycle of the risk management plan.

A few of the attributes of Agile that make it different from the more classic waterfall model include:

  • Sprints (Short and Time Boxed)
  • Planning and Re-planning Often (Sprint and Release Planning)
  • Involvement of the Business
  • Fast Feedback Loops

These attributes will affect how risks are identified and managed. (For the full discussion, read here.)

The adoption of Agile techniques has not magically erased risk from software projects.  In order to incorporate risk management into Agile we need to change the mechanism and timing of how we recognize and manage risk. Instead of risk being the bastion of the project manager, Agile methods empower the team to manage risks.