Planning: Risk Management to Manage Uncertainty

Many organizations plan to create certainty, guarantees of some variety. What if we thought about agile planning as a way to manage uncertainty?

When I look at long roadmaps with all the “must-do” feature sets and the pressure managers put on teams to commit to delivery, I wonder about this question:

How well do we understand the problems we want to solve?

I find these questions help me:

  • Do we understand the customer’s current problem(s)?
  • Is this the same problem the customer had before? Our delivery might have changed the customer’s thinking about the problem was. Our delivery might change our perspective on this problem.
  • Did we already deliver enough to solve this problem and we can move to another problem?

The less we understand the problem(s), the more we need to experiment. The more we need experiments, the more we need rolling wave planning.

The more we use rolling wave planning for learning and feedback from those experiments, the smaller the stories need to be. That’s so we can obtain feedback.

The smaller the stories, the more frequently we can update the planning. The more frequently we can update the planning, the more we can create somewhat firm roadmaps for the near term and more hypothesis-driven roadmaps for the long term. (See the Agile and Lean Roadmapping Series.)

In preparation for my talk at Agile 2018, I created this table to explain how not every problem set is the same.:

The left-most column is about well-understood problems. If we understand the customer problems well, we might be able to plan (and execute against) a six-quarter roadmap.

It’s relatively easy to create a roadmap, populate it, commit (in some way) to it, etc. That’s because the problems don’t change.

We might still have problems where management wants the teams to break the laws of physics, but that’s actually a manageable problem. (At some point, the Queen of Denial recognizes reality.)

In the middle column, if we mostly understand the problems, maybe we use a limited horizon and expect to use rolling wave plans with MVPs or some such minimums. We need the feedback to refine our plans. (I happen to prefer a three-month rolling wave, but that might not be enough planning for you.)

The risks here are that the problems change faster than our rolling wave and deliveries. Can you “guarantee” or commit to anything? You might, especially if you keep commitments to not more than one month of work. (I’m not positive about even a month, but that’s quite product-dependent.)

Now, the right-most column table is where I see many organizations slipping into desiring guarantees instead of managing uncertainty. When we have significant uncertainty, I like to have a “roadmap” of the Big Ideas and Experiments, not of feature sets. I like a one-month rolling wave to see how small we can make those Big Ideas and Experiments. (Yes, I need to create an image for that.)

An agile approach works well for Mostly Understood and Not At All Understood problems because we need to see progress and verify that the progress solves the variety of problems.

We don’t need an agile approach if we have a well-defined unchangeable customer problem. We might use an agile approach to help everyone understand our progress, but we don’t need an agile approach.

The more we need feedback to inform our future planning, the more we need an agile approach. That means an agile approach to planning, even at the roadmap level so we can manage uncertainty, not eliminate it.

5 Replies to “Planning: Risk Management to Manage Uncertainty”

  1. All projects operate in the presence of uncertainty, which comes in two kinds
    – Reducible – Epistemic
    – Irreducible – Aleatory
    Certainly can Never be created, so any firm attempting to do that is on a false path. Both these uncertainties create risk. Reducible Risk and Irreducible Risk
    There’s a myth that Agile is a risk management process, but it’s not. Agile is a participant in Risk Management, by providing rapid feedback of actions take to “handle” the risks created by uncertainty
    Here’s how to “manage” in the presence of uncertainty and the resulting risks https://goo.gl/t3UfZl
    Even for the well-understood condition in the left column uncertainties exist. The risk “handling” plans for those in the left will be much different than those in the right
    For Agile SW development here are some more resources for managing in the presence of uncertainty https://app.box.com/file/276484824896

    1. Glen, thanks. I also like Julia Wester’s post on Aleatory and Epistemic Risk – a brief intro.

      I’m not sure why you say agile approaches aren’t a way to manage risk. All life cycles manage different kinds of risk. See Selecting a Lifecycle.

      Yes, uncertainties always exist. The problem I’m trying to address is the issue of certainty and commitments to what’s in a roadmap more than a month out. We can envision much farther out than we can commit. Even if it’s a weather problem, we always have some schedule uncertainty. The problem I see too often is when an organization needs more feedback, but asks for commitments. Not for work in general, but for specific features and those features aren’t well defined because we don’t know what they need to be yet.

    1. Oran, thanks. I agree that teams who think they’re in that right-most column do need to “balance” discovery and delivery. I wrote balance in quotes because sometimes, it’s lots of little spikes to understand the problem and experiment with solutions; and sometimes, it’s a little discovery with lots of delivery of finished product. The balance, in my experience, is rarely 50-50.

      I didn’t know there was a name for this. Thank you!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.