Category Archives: Agile Risk Management

What is Agile Risk Management?

People might think that Agile Risk Management is an oxymoron because there is a common stereotype that an Agile project is totally unplanned – so why would you take a planned approach to Agile Risk Management if the whole project is unplanned?  That stereotype is closely related to the very common misconception that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall”.  The truth is that there is a continuous range of approaches from heavily plan-driven at one extreme to heavily adaptive at the other extreme with lots of alternatives between those extremes and you should fit the approach to the nature of the project rather than force-fitting a project to one of those extremes.

A similar thing is true regarding risk management.  There is no single approach to doing risk management and it’s not a binary choice between zero risk management and a totally rigid and controlled approach to risk management.  You need to fit the risk management approach to the nature of the project:

  • For high risk projects where the customer is very sensitive to risk, it probably makes sense to do a fair amount of risk management to identify, analyze, mitigate, and monitor those risks.
  • For lower risk projects where the risk is less of a concern to the customer, a more informal approach to risk management may be appropriate.

The overall process for doing risk analysis in an Agile environment is generally the same as a traditional, plan-driven project; however, it may not be as formal and it may not be as disciplined.  The general approach follows these stages:

  • Risk Identification – this might consist of a brainstorming session to identify potential risks in the project
  • Risk Analysis – this involves further study to determine the probability and impact of each risk
  • Risk Response – this involves determining what, if anything, should be done to mitigate the risk
  • Monitoring and Control – Finally during the course of the project, the risks are monitored and controlled

An Agile approach is inherently well-designed for dealing with risks:

  • Risks are generally directly related to uncertainty in a project and an Agile approach is intended to be flexible and adaptive in order to deal with uncertainty.  For that reason, it is easier to adapt to risks in an Agile environment as the project is in progress.
  • In a traditional, plan-driven project; a considerable amount of re-planning may be necessary to adapt to risks as the project is in progress; and, for that reason, it may be more important to plan for risks upfront in a traditional, plan-driven environment.

Another factor is due to the iterative and incremental nature of development in an Agile project, it’s not too difficult to structure the Product Backlog to address high risk items early in the project; and, if there is a lot of uncertainty associated with those risks, a “spike” can be performed to evaluate the risk without having a major impact on the project.

It’s easy to lose focus on risk management in an Agile environment because there is no well-defined focal point of responsibility for risk management as there may be no project manager to be the focal point for that.

  • In an Agile environment, the focus on risk management is typically owned by the entire team just like the focus on project management is typically owned by the entire team.
  • Another factor is that because an Agile approach is more adaptive to risks, there tends to be a “cavalier” approach to not worry about risks.

However, it doesn’t have to be that way.  It’s primarily a matter of:

  • Making a conscious decision of how much (and what kind of) risk management is needed based on the nature of the project
  • Training the team in the basics of risk management
  • Building in some focus on thinking about risks in all of the Agile/Scrum ceremonies (Daily Standup, Sprint Planning, Sprint Review, Sprint Retrospective, etc.)
  • Determining how the risk management effort will be managed – how will risk management be done and how will responsibilities for risk management be distributed among the team?

This is only a brief overview.  I’ve just finished some detailed training on Agile Risk Management and I will be adding that to my “Mastering Agile Project Management” online training course in the next few weeks.  Check that out here:

Mastering Agile Project Management Course

A Broader View of Risk Management for Agile

I recently participated in a LinkedIn discussion on risk management that was heavily focused on a conventional approach to risk management built around a plan-driven approach to project management. I wanted to share my thoughts on a broader view of risk management for Agile project environments as well as a traditional plan-driven project management environment.

First, let me preface this post by saying that I’m not an “Agile zealot”. If you’ve read any of my other posts or books or taken my training courses, I’m sure you recognize that I think that there is a widely-held misconception that:

  • “Agile” and “Waterfall” are polar opposites of each other, and
  • There is a binary and mutually-exclusive choice between the two approaches

I think we need to broaden our view of project management to see “Agile” and what is commonly called “Waterfall” as complementary to each other rather than competitive and recognize that traditional plan-driven project management is not the only approach to project management. I prefer to think of a continuous range of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme that looks something like this:

Increasing Agility and Adaptivity

And, the right thing to do is to fit the approach to the project rather than force-fitting a project to some arbitrary model (whatever it might be – Agile or plan-driven). One of the biggest characteristics that would influence the choice of an approach is the level of uncertainty in the project.

If you think of a broader approach to project management in those terms, it has a big impact on how you might do risk management. Here’s how I see some of the key differences in a risk management approach that might be associated with a more adaptive approach to project management in a very uncertain environment:

Why is Risk Management Different in an Agile or More Adaptive Environment?

  1. Definition of “Failure” – Risk is associated with the failure of a project, so how you define “failure” has a big impact on how you do risk management.
    • In a traditional plan-driven project, the requirements of the project are typically well-defined and a “failure” would normally be associated with failing to deliver those requirements within the required cost and schedule budgets allocated for the project. In that kind of environment, it wouldn’t normally be considered a failure if the project met the requirements it was supposed to meet within the cost and schedule goals but failed to deliver the appropriate business value.
    • That approach works fine in an environment where it is possible to relatively accurately define the requirements of the project before the project starts and three is a reasonable level of certainty that if you meet the defined requirements, the project will automatically produce the appropriate business value that is required.

    • An Agile or more adaptive approach is best in situations where it is much more difficult to define detailed requirements for the project prior to the start of the project and there is far less certainty of what is required to produce the appropriate business value. In that kind of environment, there is a much larger risk that the project won’t produce the required business value even if it does meet the defined requirements within budgeted cost and schedule goals. That’s a very important difference between an Agile (or adaptive) approach and a more traditional plan-driven approach.
  2. Relationship to Upfront Planning – Since an Agile approach normally has a lot less upfront planning, it typically requires a more dynamic approach for identifying and managing some of the risks while the project is in progress rather than a comprehensive approach to identify and anticipate risks before the project starts.

    Note that this is not an all-or-nothing choice between zero upfront planning and highly detailed and rigid upfront planning – the approach to planning could be anywhere between those extremes and the approach to risk management should be consistent with the level of planning.

    The important point is that it just isn’t practical to take a comprehensive approach to identify and anticipate all risks in a project with a very limited amount of upfront planning.

  3. The Relationship to Business Value – The risk of not producing the appropriate business value in a very uncertain environment is a very different kind of risk and requires a different kind of risk management approach. That kind of risk isn’t necessarily totally black-and-white – you could produce a relatively mediocre product that met the letter of the requirements but really didn’t provide much business value.

    A conventional approach to risk management is generally based on avoiding and eliminating risks and uncertainty as much as possible so that the project will deliver predictable results, but that approach can work against you if you have a goal of maximizing business value. (See my previous article on Management of Uncertainty in Agile Projects).

    In many cases, risk is associated with opportunities to provide a higher level of business value. With a conventional approach to risk management, you might try to reduce the level of uncertainty and ambiguity associated with user requirements as much as possible prior to the start of the project and you might also tend to favor a low risk approach of using tried-and-true technology rather than “pushing the envelope” a bit to use riskier technology that might provide a higher level of value to the user. From a conventional risk management perspective, that may be the right thing to do but it could easily result in a very mediocre product that doesn’t provide much business value.

How is the Approach to Risk Management Likely to be Different in an Agile environment?

Some people might think that risk management isn’t appropriate in an Agile environment – I don’t believe that to be the case. You can do as much or as little risk management as needed depending on the nature of the project – it just requires a different approach to risk management.

  1. It needs to recognize a broader definition of “failure” – a project can fail by failing to deliver business value even if it meets defined requirements and meets its cost and schedule goals
  2. The approach to risk management needs to be consistent with the overall level of upfront planning in the project – that might mean a less comprehensive identification and analysis of risks prior to the start of the project and a more dynamic approach to risk management as the project is in progress.
  3. Instead of seeing all risks as a bad thing that should be avoided and eliminated, we need to recognize that some risks are related to opportunities. For that reason, a decision to avoid or eliminate risks needs to consider the impact of potential missed opportunities as well as the impact of the risk.

Advantages of an Agile or Adaptive Risk Management Approach

In fact, an Agile or adaptive approach can have a lot of advantages for developing a very effective risk management approach. Steve Gordon commented that Agile or adaptive thinking provides the ability to structure a project to fail early and inexpensively to minimize the impact of a risk on the overall project. Wayne Mack also suggested several more specific risk management advantages that an Agile or adaptive approach can provide:

  • “Technical risks are addressed through early prototypes (“spike stories”) and side-by-side comparison of alternatives (‘A/B testing’)”
  • “Integration risk is mitigated through early and continuous integration. User acceptance risk is mitigated through early product review”
  • “Cost and schedule risk is mitigated through incremental releases – we always have something to show for the money spent; it is no longer an all or nothing trade-off”