Iterate / Inspect and Adapt – nice in theory…
Iterate, inspect, and adapt sounds easy in the classroom — this post examines the real-world blockers that prevent teams from actually closing the learning loop.
On paper, it all makes sense. You iterate in order to deliver business value as early and frequent as possible, and to learn as early as possible about mistakes or opportunities, both in what you build as well as how you build. So far so good.
Now, there are several things you hear from teams starting to work in fast iterations:
- We cannot really accomplish any meaningful amount of work in this short time. Look at the features we’re asked to work on, no chance we can finish that so fast…
- Wait – you mean we actually want to have this potentially shippable every iteration? That means we need to have it stable. In order to reach stability we need to do a test cycle. We need some time to do that. The term “Feature/Code Freeze” usually comes up at that point. See my earlier post about this.
- Can we do design in one iteration, coding in another, testing in yet another?
All in all, if what you are looking for is a way to surface the heavy large batch stuff in your engineering organization, look no further than to raise the idea of fast iterations, not to mention to actually start doing them… ;-) Lucky for us, when we implement Agile/Scrum/Lean, that is exactly what we are looking for.
At this stage fast iterations trade some lost productivity for the gain of early ROI and better visibility of project progress, requirements changes. In some cases, at this level the cost and benefits are not that far from each other…
Its crucial at this point that the team/organization transition to a place where the lost productivity is negligible, while the early ROI grows. This requires both reducing the cost of the small batches as well as pushing the product to its customers more frequently. Without these two actions, it will be hard to justify continuing to pay the price of fast iterations, and some regression to long iterations or lower chance of shippable product will ensue.
How do you reduce the cost of small batches?
One of the keys is to introduce Continuous Integration with a fully automation regression suite reduces the price of testing.
Tomorrow I’m talking in a Test Automation Open day about this and related concepts. You are welcome to check out my slides .
I’ll continue to write about this subject in the future. I believe its key to making Agile work in real life.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →