(2017-08-31) Alternatives For Agile And Lean Roadmapping Think In Feature Sets

Johanna Rothman: Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets

Very few people or teams can accurately estimate a quarter’s worth of work.

Here is an alternative. Think about feature sets (which helps with the idea that this is Big Work), counting features, MVPs (to validate a business hypothesis), and MVEs (to learn something small with an experiment).

Count the features in the feature set. Yes, just count them.

Part 2: Rolling Wave Planning Inside One Quarter

When POs realize they might not need all the features in a feature set for an MVP or an MVE, they see the possibilities for more frequent planning

You always have a two-month wave where the first month is clear and the second month is supposition

this work would change how the customers used their product, from start to end. The POs were pretty sure they couldn’t commit to anything as large as two months. They decided to use one-month rolling wave planning.

you decide on the duration of the detailed plans, and as you finish one week, you plan the next week

Part 3: Flow-Based Roadmapping

Couple that pressure for changing what the teams commit to, and I’ve seen more failures with quarter-based planning than I’ve seen successes.

Consider lean roadmapping where we intend to pull work instead of iteration-based roadmapping where it’s too easy to push work.

I specifically think about releases as MMF (Minimum Marketable Features).

I specifically use the term MVP, Minimum Viable Product, to help people realize it is the minimum we could release to validate a business hypothesis

If you want to try this, make sure your MVPs are minimum. You might want to use MVEs in places, to learn quickly and decide what to do next

In my experience, the less we commit to, the more flexible and resilient the project or program is, and the better the outcome

Part 4: Resilience, Prediction, & Feedback

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

Part 5: the Product Value Team

Instead of incurring the time and cost when you bring everyone together, consider the Product Value Team.

Because the product depends on all three of these feature sets, the POs coordinate in a PVT, product value team, along with the product manager.

Part 6: Managers Want Commitments

You’re thinking in iterative and incremental terms. Your managers are not yet. Your managers are stuck in what I call “how much” thinking:

Here are some ideas about what you can do

Ask for clarity about the strategy for this product and any goals for interim releases

Build relationships with the people who want commitments and predictions. Understand the pressures on them. See what you can deliver for plans that will help them meet their pressures

Part 7: Summary

Let me summarize what I’ve been talking about in these posts. The problem I’m seeing is that too many teams and organizations plan too much in too much detail too soon. Instead of architectural BDUF (Big Design Up Front), it’s project planning as BDUF. They expect one single person (a product manager or a product owner) to do all that planning. That’s a legacy of waterfall thinking.

If you want to take advantage of agile approaches for maximum innovation and speed, consider these ideas...