Over a million developers have joined DZone.

Alternatives for Agile and Lean Roadmapping: Part 7, Summary

DZone's Guide to

Alternatives for Agile and Lean Roadmapping: Part 7, Summary

In this post, we finish up our series by giving a brief synopsis of the past six articles, thus reviewing the various ways to apply Agile and Lean.

· Agile Zone
Free Resource

The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.

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:

Consider using the term, feature sets, related features that produce value, instead of epics or themes. That will help other people realize the largeness of what you are discussing. When they think about the largeness, they might see more options for MVPs, MVEs, and releasing, especially for small and early value.

The more you want to incorporate feedback into your planning (either the small planning or the larger planning), the more you can consider rolling wave planning, especially if you are trying to plan for a quarter at a time. To be honest, if you are using agile approaches to manage change to the product and to incorporate feedback, I'm not sure how you can plan for a quarter. Roadmap? Absolutely. Plan? Not so much. (I have a slideshare called Think Big, Plan Small: How to Use Continual Planning.)

I suggested that if you need more change than a time-based roadmap might provide you, consider a scope-based roadmap, using principles of flow.

I wrote about the problems I've seen with big planning and the fact that the larger the effort, the more teams need resilience and feedback in their planning.

Then I said the PO can't do all the roadmap and backlog planning/refinement alone. I suggested you consider the Product Value Team. The Product Value Team has the customer and internal contacts to gather the knowledge, distill it, and plan and replan at a reasonable (for you) cadence.

I had some suggestions for what to do when managers want commitments. Remember that if you work in rank order and release often, you might deliver what they need, not necessarily what they know they want now. That goes to the evolving nature of the actual product in development.

I've been grappling with the whole "scaling agile" idea. I wrote a scaling series about it earlier this year. This roadmap series is about scaling the product development capabilities.

You might not like these ideas. I'm not offended. Here are the questions I suggest you answer:

  • What would have to be true for you to be able to create useful plans?
  • What assurances can you provide your managers?
  • How can you deliver small value every day and maintain a sustainable pace?

Agile approaches change our entire notion of planning in the large and small. They change what we can deliver because we can deliver much more than we might have thought we could. The difference is we deliver small chunks of value all the time.

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training

agile ,lean ,roadmaps ,product owners

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}