What if you don’t need to experiment to reduce risks? You may have technical risks in terms of getting it “all” done. Especially for a given release date. In that case, you have a low need for product innovation. Your planning feedback loops can be longer.
I’ve seen this occur in some of these circumstances:
- A port from one platform to another. We know what we have to do. The technical risks are not in the knowing, but in how things work or will work on the new platform. We need short feedback loops in the project/program to see where we are and make small adjustments.
- At the end of a long project or program. We don’t need to replan features as often, but we do need to keep checking on our execution. Again, those small adjustments, to make sure we finish.
- Products that keep the lights on or extend a product’s capabilities, but do not transform the organization’s capabilities.
You can estimate and commit for longer, barring technical problems. Even if you do encounter technical problems, agile approaches help manage those problems with short project feedback loops. Given that you’ve already experimented, you’ve learned enough to finish proceeding with the work. You don’t need a lot of feedback to change the requirements. You’re closer to the right side of this continuum.
Low Need for Product Innovation and Change
If you don’t need to change the plans too often for a given product because the innovation need is low, go ahead and plan for a quarter, or even more, at a time.
I have not worked on many of these products over my career.
The last time I worked on one of these products was in the late 70’s. I was supporting a product nearing the end of its life. We thought we had about another year of value remaining in this product. I enjoyed working with the customers, and I had a chance to experiment with hardware. I was a happy developer.
We could plan a quarter’s worth of work, and I could churn it out. I could interrupt some of that work to help other people on their projects. Their project work was more valuable than mine, so it was fine.
The innovation wasn’t in the product. The innovation was in my learning—how I learned the internals of that product, which would help me in the future. And, I learned to develop as a team with an electrical engineer and a mechanical engineer.
Once I learned all that I told my boss I wanted off that product and onto a new one. We were ready to sunset the product, so it all worked out.
I didn’t need a lot of product planning feedback, although I did need some. I did need to estimate approximately what I could do in a quarter. Since the estimations were gross estimates, I was off. Sometimes, I underestimated, and I pulled from the next batch of work. More often, I overestimated what I could do. I had a ranked backlog, so I could finish in order.
We didn’t release on the same day every quarter, so it wasn’t exactly a release train. It was pretty close.
I have not worked on a project or product like this since then. In the last decade in my practice, even the products who appear to be in “sunset” mode, seem to need more innovation than anyone originally expected.
Low innovation products don’t need to account for experimentation in the planning. They still need short feedback loops in the execution to continue to make microadjustments in how we work. We still need to assess risk and manage the risks with short feedback loops.
I’ll talk about the various feedback loops in planning and execution in the next post.
Series so far:
- 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
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 3: Low Innovation Products Opinions expressed by Java Code Geeks contributors are their own. |
