Is it possible to balance the product innovation and feedback we need, with the commitment our management wants? Maybe. I tried to how my thinking for these questions in this series:
- When does it make sense to ask for or offer estimation and commitments?
- When does it make sense to ask for more feedback instead?
- How about when it does make sense to create small or larger estimates for the product?
Let’s start with the need for very fast product feedback.
High Change: Do You Need Estimation or Feedback Now?
The more frequently you need to innovate in your product, the less estimation and commitment you need, for now. In fact, you don’t need to offer estimation or commitment because you ask for much more product feedback. You show people who might ask for an estimation or a commitment your progress at least weekly, if not more often.
Note: in high innovation work, the team might need feedback hourly—at minimum, daily—not just from a product owner, but from the product value team and maybe customers.
To create that progress, the product people and the team create very small stories. The product people rank these stories, so the team can work on the most valuable piece of work. The team might work together, keeping their WIP limit to one or two items, to make sure they finish their work to obtain the feedback.
Your team might even sit with the customer to obtain faster feedback.
Moderate Change: A Little Estimation, Some Feedback
If you only need moderate change, where you can plan for a few weeks at a time, you need estimation in the small. That estimation is about fitting the work to the time available. There’s not much point in planning for an entire feature set and estimating it unless you can complete all that work in a couple of weeks.
My caution about estimating for more than an iteration at a time:
In a moderate change environment, the team might have to stop working on a given feature set and move to another feature set. Should they estimate the entirety of each feature set? Not for me. Especially if you have a cadence or iteration and small stories, don’t bother estimating. Make the stories very small and count them.
What if you can complete a feature set in a couple of weeks, and really have it be done, build and test automation, and any user documentation or internal documentation complete? I high-five you. I haven’t seen this occur often, but maybe if your team mobs and your feature set is small, you can do this.
In a moderate change environment, the team still needs small stories. The team still needs frequent feedback. You might not need the feedback several times a day. My experience is the team needs feedback anywhere from once a day to several times a week. It all depends on your product.
Estimation and commitment in the small (for the next few weeks) make sense. I have not seen quarter-based or project-based estimation and commitment make sense in moderate change environments.
Low Change: Manage the Estimation Costs and Time
If you don’t have a lot of product innovation, go ahead and plan for an entire quarter at a time. If the managers want estimates, make the estimate and explain your assumptions to management.
(See Predicting the Unpredictable for various estimation approaches and how to explain assumptions. See Create Your Successful Agile Project for how to use cycle time to reduce the time you spend on estimation.)
My concern here is that the product owner or product value team hasn’t taken the time to think through the feature sets or to refine the stories. The team(s) spend time refining and estimating, and then a month into the quarter things change.
If your team has to change what they do one month or six weeks into a quarter’s estimation or commitment, the product feedback loop is too long. The team wasted at least some of their estimation time.
Instead, consider using flow-based roadmapping. Explain what you can commit to for a quarter, and show your options for what you will do next.
Product Feedback Loops are Different than Project Feedback Loops
I’ve focused this series on product feedback loops, not project feedback loops. Some projects—even when people can plan for an entire quarter’s worth of product—require frequent kaizen or retrospective events. The team doing the work might want daily or weekly project feedback loops for their work. The product feedback loops might be only quarterly.
Each product is different. And, different products require different kinds of innovation at different times. Here’s how I’ve seen some organization balance their need for high product innovation with their management’s desires for estimates:
Alternative 1: Research First with an “Advance” Team
One of my clients uses an R&D Engineering team to explore several architecture possibilities before they commit to the project.
This is okay if the “advance” team restricts their time to explore and define the bare minimum decisions. They also need to fully debrief with the project team who will do the work. Too often, I’ve seen the advance team know they have uncovered all the gotchas. Then, two weeks to two months later, the regular team uncovers more risks that the Advance team didn’t see. Too often, management blames the regular team for not knowing. (Grumble.)
Alternative 2: Research First with the “Regular” Team
Another client uses the first two weeks to a month as spikes to research and learn. The team spikes daily or several times per week to learn what the risks are and where they need to explore more. I prefer this approach if you think you need to research first.
Alternative 3: Integrate Research and Delivery with Frequent Project Portfolio Replanning
(Note, this is Research and Delivery, not Research and Development!)
I much prefer this alternative, where the team who will research is also the team who does the work. Here, the team not only explores, they deliver as they proceed. I’ve seen this work on relatively new products, or products where the minimum adoptable feature set is small.
When the team has done “enough” on this product for now, the senior managers replan the project portfolio and the team moves to another product.
Consider Your Planning and Estimation Options
When I separated my product feedback loops from project feedback loops, I learned I could plan and estimate differently.
Identify where you are. If you don’t like my continuum, develop your own. So far, this one’s working for me.
My guidelines:
- Don’t plan for more work than you can do before you have to change.
- Don’t estimate for more work than you can do before you have to change.
- Do consider how you can create granular stories and see the complexity in your feature sets. That way, you can show why your estimation is “so long.”
- Do consider learning as a team to manage risk and create shorter feedback loops.
Use the right level of planning and feedback loops that work for your product and project.
The entire series:
- When everything requires experimentation and change: Balance Innovation, Commitment, & Feedback Loops: Part 1: High Innovation Products
- When you can plan for a month or so: Balance Innovation, Commitment, & Feedback Loops: Part 2: Moderate Innovation Products
- When you don’t to change planning, but you still need to deliver: Balance Innovation, Commitment & Feedback Loops: Part 3: Low Innovation Products
- Summary post: Balance Innovation, Commitment, & Feedback Loops: Summary
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: Summary Opinions expressed by Java Code Geeks contributors are their own. |
