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.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Planning: Risk Management to Manage Uncertainty Opinions expressed by Java Code Geeks contributors are their own. |
