Alternatives for Agile and Lean Roadmapping: Part 5, the Product Value Team

If you need to plan more often than once a quarter, how do you know how to replan? Instead of incurring the time and cost when you bring everyone together,  consider the Product Value Team. (In past writing and presentations, I’ve called this the Product Owner Value Team. I am trying to change my term …

Alternatives for Agile and Lean Roadmapping: Part 4, Resilience, Prediction, & Feedback

One of my clients was trying—valiantly—to make their quarterly planning sessions work. They prepared, getting 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.” …

Alternatives for Agile and Lean Roadmapping: Part 3, Flow-Based Roadmapping

In Part 1, I wrote about thinking in feature sets so everyone could see smaller chunks of work. (If you can see them, you might be able to plan for smaller and deliver smaller.) In Part 2, I suggested smaller rolling waves than an entire quarter (two months, or preferably one month) so people could …

Alternatives for Agile and Lean Roadmapping: Part 2, Rolling Wave Planning Inside One Quarter

In Part 1, I wrote about thinking in feature sets and how to quickly create a feature set of—with any luck—smaller features. That’s because features don’t arrive at the same rate and they change in value, during a quarter. Because features change in value and because some feature sets need to deliver value on a more regular …

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

Many teams and organizations try to create one-quarter roadmaps. Here are the problems I see: Teams spend a ton of time estimating what they might do and then they select what will fit into a quarter. They feel or are asked to commit to all that work. The product managers and project portfolio managers depend on …

Defining “Scaling” Agile, Part 4A: Sharing Agile Outside of Product Development

Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance. In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream: …

Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development

Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches: Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis) Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis) Part 3: Agile Product …

Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities

In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities. …

Defining “Scaling” Agile, Part 2: Program Management for Product Development

The first post was about scaling functions to working as collaborative agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program. The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a …