You’ve started thinking in feature sets. Maybe you’ve experimented with rolling wave plans inside one quarter, so you can change and replan as you need to support your project or program. You’ve discussed flow-based roadmapping as a way to create MVPs and MVEs, release smaller value more often so you can make better decisions.
You know you need more feedback and resilience in your project/program, so you’ve created a product value team to reassess the roadmap on a regular basis. That helps the POs update the backlogs.
You’re thinking in iterative and incremental terms. Your managers are not yet. Your managers are stuck in what I call “how much” thinking:
- They want to see an estimate for “all” of it, regardless of when you might deliver the first piece of value. Implicit in that first piece is the idea you might stop there.
- They want you to commit to an entire quarter’s worth of work. Not the fact that you will deliver value during the quarter, but what the quarter’s work will consist of.
- They want to know exactly when you will deliver which features, even though you might have only a hand-waving perspective of what those features are.
Managers need commitments and predictions for a number of excellent reasons. They need to plan on revenue from products and services. They do need some ideas of what you can deliver and when because they might have to commit some form of dates to customers. In the case of a program, people outside the organization need to know which features they can plan on when especially if you are part of a very large product with many vendors.
These predictions and plans make sense when you think about your managers’ perspectives.
And, if you are like many product owners and program managers and project managers I know, it’s quite difficult to provide your managers the commitments they need. Here are some ideas about what you can do:
- Ask for clarity about the strategy for this product and any goals for interim releases. The more people understand and agree on what this product is supposed to deliver, and what this release will deliver for that product, the more likely everyone can agree on how much to plan, when to replan, and how often to deliver and receive feedback from whom.
- 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. The more you can release the pressures on them, the less pressure you will feel.
- Release finished features often. If you work at a place new to agile approaches, work on streamlining the releases so you always release once a month. (I like releasing to customers that often, but that doesn’t always work.) Then move to releasing every two weeks. Then one week. Then move to continuous delivery, even if it’s inside your organization. See the Frictionless Releasing posts.
- Measure your cycle time and actual rate of feature delivery. You can see some of these measures in Velocity is Not Acceleration.
Agile approaches create empirical measurements: what we have actually completed, not predictive measurements, what we want to have completed. You will need to train your managers in how to think empirically, not just in plans. You might want to use some of my wording, changing it so it’s not a career-limiting conversation:
“You’ve told me what you want to have happen. I’ve shown you what we can do in this time period. Let’s discuss what we can deliver and when to replan to provide you the maximum information, the most value for our customers, and the most resilience for our product.”
I don’t happen to think that should be a career-limiting conversation, but some managers become perturbed at this. Modify to fit your context.
The faster you can demo (and release) working product, the faster you will build trust with people across the organization and with your customers. That trust will extend to creating more flexible roadmaps, more flexibility with which features when, and more resilience in your projects and programs. The more you release working product, the more you can build trust.
If you show your managers your rate of delivery, and the sizes of what you deliver, will that help or hurt your relationship with your managers?
I guess I need a summary post to pull everything together. Here are the posts so far:
- Part 1: Think in Feature Sets
- Part 2: Rolling Wave Planning
- Part 3: Flow-Based Roadmapping
- Part 4: Resilience, Prediction, and Feedback
- Part 5: Product Value Team
- Part 6: Managers Want Commitments
The final part will pull this all together.
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Alternatives for Agile and Lean Roadmapping: Part 6, Managers Want Commitments Opinions expressed by Java Code Geeks contributors are their own. |
