Many organizations ask teams to forecast when the team can deliver a feature. (Or finish a project.) That request often means the teams spend a ton of time forecasting, not delivering. Instead, what if managers told the team when the managers want to make a decision? The team could deliver enough to help the managers make those decisions.
Instead of feature deadlines, we have decision deadlines.
We change the feedback loops. Instead of teams being responsible for delivering product, the managers are responsible for explaining when the managers want to decide. (That’s the point of all those feedback loops in the image above.)
We change the drivers for the feedback loops.
How Changing the Feedback Loop Drivers Might Work
Here’s how changing the feedback loops might get interesting.
Let’s assume the managers want to replan the project portfolio every quarter. The teams have to deliver at least once a quarter.
If the managers want to replan the project portfolio every month? The teams have to deliver at least once a month.
What about product decisions? The product value team might need to see product deliverables at least once a week.
When the feedback loops start with management decisions, the teams can say, “Here’s what we need to give you the information so you can make a good decision.”
Instead of teams saying now, “We need more time to deliver that.”
If managers realize the teams don’t have the tools, the time, the hard resources—whatever the teams need—the managers might rethink what they ask of the teams. In addition, the managers might:
- Focus on one overarching goal at a time. Teams would not multitask. The managers might reduce organizational WIP.
- Realize that an agile culture starts with the questions the managers pose and the answers they need.
- Build more empathy with the people doing the work.
Instead of product deadlines, we get decision deadlines. I bet teams could generate reasonable backlogs of what to deliver when, if they knew the decisions the managers want to make.
You’re Just Turning the Equation Around!
A sharp client said, “You’re just turning the equation around.”
I agreed. And that’s when I said, “You’re asking the teams to predict all kinds of things about the product. They can’t. However, you know the decisions you want to make. You have much better insight into those decisions. Why not clarify those decisions for the team? They might deliver what you need, not what you say you want.”
The client started that a month ago. So far, (fingers crossed), the teams are doing less “mandatory” work and delivering more. It’s early in this experiment.
If you find that your team labors under deadlines, consider making the deadlines for the management decisions, not for the teams. Let the teams deliver what management needs to make a decision. Or, make it obvious when the team can’t.
And please let me know what happens. It’s possible this is a one-off early success.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Use Decision Deadlines to Plan for Product Deliverables Opinions expressed by Java Code Geeks contributors are their own. |
