Several of my clients have intertwined problems. Everyone agrees they want innovation:
- Which products and services the organization offers. (The project portfolio)
- What features the product offers, or the problems the product solves. (The product roadmap)
- In the team, to solve the problems in a way that will attract users/buyers/customers. (The team’s backlog and how the team works.)
Everyone says they want innovation. They feel as far from innovation as they did when they used a waterfall approach. Why?
Let’s examine what people want in more detail first.
What Do People Want?
The managers want:
- The teams to go “faster.” Often, because they want to start the next project.
- Forecasts for an entire project. (They think the team is a feature factory.)
- Change the project portfolio more rapidly than the team(s) can finish enough features.
The managers say they want innovation, which is why they want the teams to go faster. That’s one of the reasons they want to know when the project will be done.
In contrast, the POs:
- Want the ability to change the order of the feature sets and the features in the feature sets.
- Think they need “all” of a feature set to release full features, not to release incrementally. (How much thinking, not how little thinking.)
The POs also want innovation.
And, the teams:
- Can’t seem to estimate for an iteration. Or, if they work in flow, their cycle time is all over the map, so their short forecasts don’t work.
- Don’t want to spend time forecasting an entire release because they know they will be wrong. Or, it doesn’t seem worth the time. Or, they know someone will ask them to change the forecast to make an earlier date.
Everyone seems frustrated by the various delays. My clients continue to ask the “when” questions:
- When will the team finish this feature set?
- What’s your estimate for this item on the roadmap?
- When can we change the project portfolio?
You might have more questions.
These nice people all want the same thing: innovation. And, they have trouble moving fast “enough” to create that innovation.
These problems and questions are all about delays in the system’s feedback loops. Those delays lead to pushing the team to do “more” and pressuring the team to deliver “faster.” That pushing doesn’t help.
It’s time to see these feedback loops, starting with the team.
How Long Are Your Team’s Feedback Loops?
This image is the product-only feedback loop. You can calculate your loop duration with cycle time.
The team and the PO have total control over these loops and their feedback—unless the organization works across the architecture, as in component teams.
When the PO and the team create small stories (1 day, preferably), they can see the outcome of that story.
What if your team can’t complete a story in under a week? Or, what if a story takes several weeks?
That’s not a story. That’s a feature set. You can tell if you have more than one story by counting the acceptance criteria. My guideline is 3 acceptance criteria, as Given-When-Then.
If we persist in thinking one giant thing is a single feature, we’re not using the various Product Options with Minimum Outcomes to help us carve out the work.
When the team limits its WIP (Work in Progress) and limits the number of total stories in progress, the team reduces its overall cycle time.
Is the PO available “enough” to the team? If the team has to wait more than about 30 minutes for the PO to accept or reject a story, I say, no, the PO is not available enough to the team. (In many teams, the PO is an Overloaded Operator.)
The team and the PO have a lot of control over their cycle time. (If the team is a part of several component teams, consider the Experiment from Component Teams to Feature Teams.)
That’s not the only feedback loop. Many teams and POs need to change the roadmap more frequently than they expected.
How Long Are Your Roadmap Feedback Loops?
Many of my clients feel the need to change the roadmap more often than once a quarter. (I totally agree with them.)
However, the longer the team takes to finish any given feature, the longer the PO (or product value team) has to wait to change the roadmap. Especially if the team creates experiments and needs to see results.
What’s the gating factor? Team cycle time. (Yes, the same cycle time as above.)
The next gating factor? Product people decision time.
Again, the Product people and the team have total control over the duration of these feedback loops:
- Continue to create small stories (1 team-day or shorter).
- Break the feature sets into parts. (Part 1, Part 2, Part 3, etc.)
- Move from planning an entire quarter/year to rolling-wave planning.
The longer the roadmap feedback loop, the less frequently anyone can change the roadmaps. That might mean we stick with a roadmap even when the circumstances change.
Even worse, when we have to wait for the roadmap to change, we can’t change the project portfolio or the organizational strategy as often as we want.
How Often Do You Want to Change the Project Portfolio?
The more often the teams finish a feature, the more often the product people can change the roadmap.
Even better, the more often the product people can say, “We’ve done enough,” either for the entire product or for a feature set.
If the product people think we’ve done enough for the entire product, the organization can move to a different project in the project portfolio.
My clients can solve their current challenges and answer their questions when they optimize for fast cycle time in the teams (the inner loops in blue in these images.)
Create Short Feedback Loops Everywhere
I started with the team here, showing the feedback loops for the team. I still think that teams—assuming they use an incremental lifecycle or an agile approach—can control their cycle time more than they might think.
When a team maps their value stream and measures their cycle time, they can see what happens when they work. They will see where they have the possibility of reducing their delays. They will see if they are part of component teams, instead of being a feature team.
When managers or leaders, such as the PO, measure their management cycle time, they can see the effect of long decision times on the team. Especially if those decisions take the PO away from working with the team.
And, when everyone starts to measure their cycle time, they can forecast without spending a crazy amount of time trying to estimate from insufficient data. (Will their forecast be wrong for the first few weeks for a brand new product or project? Probably. However, that’s the idea of “do something first, then estimate,” also in Predicting the Unpredictable.
If you want innovation, you need to manage for change. That often means reducing the wait time for everything, including any management or leadership decisions.
Short feedback loops will support your innovation. Reduce wait times and you’ll see how much faster everything can be.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Multiple Short Feedback Loops Support Innovation Opinions expressed by Java Code Geeks contributors are their own. |
