Many of my clients are trying to use short feedback loops in agile approaches. That desire bumps up against their management’s desires for longer commitments. This continuum might help them think through their needs for commitment and innovation.
High Need for Product Innovation and Change
The more need for product innovation and change, the shorter the feedback loops need to be. It’s not useful for management to ask the team to provide larger commitments, as in “how long will this feature set take?” for at least these reasons:
- The act of estimation takes time away from doing the work and getting the feedback.
- The feature set will change. Any estimates don’t reflect the reality of the work.
- The commitment is to the experiments, not the plan.
The more change the organization needs, the more the team needs to work in small experiments, small stories, small deliveries.
And, management must accept the fact that if the feature team doesn’t do some analysis and learning up front (not a lot, but some), the team will refactor/reanalyze/redesign as they proceed, all of which might take more time than the managers desire. If the team is supposed to prototype and throw away, then the team might not need to the refactor/reanalyze/redesign, but not what to do when they write the code and tests for real.
The higher the need for innovation and changing the rank of the stories, the shorter the iterations must be or the more need for flow. (I wrote about this in Create Your Successful Agile Project.) You also might like When Should You Move from Iterations to Flow?
If you need to change the backlog more frequently than your iteration duration, stop using iterations. Use flow.
When the product requires much innovation and change, management doesn’t need estimates. Instead, the team needs to create very small stories, in the form of experiments. (See What’s Minimum: Thinking About Minimum Viable Experiments for more details.) The team needs very short feedback loops from the time they create the experiment to the time they receive feedback. The PO needs to sit with the team. The team might need to sit with (or visit) the customer to gain feedback as fast as possible.
Change the Commitments
Many teams do high innovation projects. Unfortunately, they don’t realize they need much faster feedback. They treat the high innovation work as if it’s moderate or low innovation. Management thinks it’s okay to ask a team for a commitment for features and estimates.
What management (product management and stakeholders) should ask for is a demo at least every day or even more often. When management sees the product direction, they can say, “Stop with this and continue with that.”
When everyone plans for high innovation, they change how they plan. The estimates aren’t “too long” or the team doesn’t deliver “fast enough.” Instead, the entire relevant parts of the organization change how they think about what they commit to.
Instead of committing to plans, everyone commits to fast feedback and fast decision-making because of that feedback.
The next post will be about moderate innovation.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Balance Innovation, Commitment, & Feedback Loops: Part 1: High Innovation Products Opinions expressed by Java Code Geeks contributors are their own. |
