Alternatives for Agile and Lean Roadmapping, Part 4: Resilience, Prediction, and Feedback
If you're looking to get greater insight into your product, and you're trying to use Agile processes, feedback loops are a necessity.
Join the DZone community and get the full member experience.Join For Free
One of my clients was trying - valiantly - to make their quarterly planning sessions work. They prepared, got the big hotel room. They had plenty of supplies. The planning even went well.
However, within two weeks, their plan had no relation to reality. That meant that for the next ten weeks, the product owners were "on their own." And, because the product managers were out of the office so much, they had a terrible time deciding what to do to benefit the entire program.
These POs were smart. They knew what they needed to do for their own projects inside the big program. However, they didn't have insight into what they could do when their products required change based on feedback, and how to incorporate this change so that the product still provided value for the entire program. They needed more resilience than one-quarter's worth of planning could provide.
You might not have that particular problem. However, I have seen this problem:
The larger or more important the effort, the more feedback the teams need and the more the product owners need to re-plan to provide the most value to the effort.
You don't need to be a programmer to have this problem. You could be a product owner such as the one I coached a year or so ago. He had a total of 12 people working in two teams, all on one product. As they released value, they received feedback that guided this PO's backlog creation.
The PO's problem? He couldn't predict more than about six weeks of work at a time. He needed more resilience in the project. His managers wanted more prediction.
Resilience in a project or program is why I've been recommending rolling wave planning or lean planning. These alternatives help people see minimum work in terms of feature sets, plan minimum feature sets or parts of feature sets, and re-plan the work when it makes sense to do so.
Here are ways to think about this question:
- Do you need to build or run experiments to learn? How long are those experiments?
- Do you need to validate business hypotheses to understand what your customers will and will not buy?
- Do you need to release small and then release to your entire customer base based on what you learned in the small release or to manage risks?
You might have more questions. These are all questions that suggest larger planning is not as helpful. As I said in Part 1, you might find that the discussions from larger planning are helpful. However, the planning itself might not be worth it because you need to re-plan.
I don't know of a project or program longer than a few weeks that doesn't need feedback. In my experience, all projects/programs need feedback. Maybe your project or program is different.
Different projects/programs require different amounts of resilience. If you are using Agile approaches to see the product's progress, but you can predict everything because you already know how to do this work, terrific. Plan for an entire quarter.
However, if you are more like the projects and programs I see, consider shorter planning and replanning alternatives.
My next post is about how to re-plan with a Product Value team for a project or a program. I'll address the managers-wanting-prediction problem after that.
Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.