Some times, we want longer iterations.
We waste to much time in meetings and other activities associated with iteration turnovers, so we decide to extend the duration of the iteration. Let’s make those planning meetings, estimation workshops, retrospectives and what-have-you happen less frequently. We might even get some work done, right?
Sadly, longer iterations don’t change how customers interact with us. We continue to get expedite requests, like having to fix a bug (which obviously shouldn’t have been there in the first place). Now that iterations are longer, we appear less responsive to our customers, which of course wasn’t the idea at all. To compensate, we could introduce mid-iteration releases?
Moreover, with longer iterations management feels less in control, because feedback is less frequent, and problems seem to pile up more now than before. That wasn’t the idea in the first place, so they feel compelled to introduce stricter reporting. How about a mid-iteration report?
Finally we get to the iteration turnover. We have experienced flow and feel great, except lack of coordination within and between teams makes our stuff not work that well together when we integrate. We decide to talk more. So we introduce a regular integration planning meeting with the other development teams. Would twice each iteration do?
Making iterations longer can be comfortable for a while. It feels better to work longer periods at a time undisturbed, and it feels better to spend our working time developing as opposed to attending meetings.
What's the scent of your learning cycle?
Longer iterations are however nothing more than a dangerous painkiller, which conceals the real problems we have. Double the iteration length, and iteration turnover gets four times as painful and half as useful. The reasons we have iterations in the first place is to create learning opportunities. Why would we want less of them when we could have more?
Longer iterations create room for more waste, forcing us into compensations that drive more compensations. We get iterations within iterations. We get wasteful reporting. We get less coordinated and produce more bugs. We stop doing retrospectives because we don’t have time to follow up on the resulting action points anyway. The resulting problems call for more meetings, and we get tempted to extend the iterations even further, which makes iteration turnovers even more painful. In the end we’re so sick of iterations that we start longing for waterfall.
Taiichi Ohno, the great engineer and systems thinker at Toyota had a helpful analogy about rocks and water. Imagine your process being a river with rocks on the bottom. The water is our level of comfort, and the rocks are everything which we shouldn’t be doing. Ohno calls them waste, which he defines as everything we do that doesn’t bring value to the customer. When the water level is high, we hardly see any rocks, hence the only way to find waste is to lower the water level. In other words, make ourselves less comfortable.
How does this translate to the pain of iteration turnovers? We do more of it. We have those turnovers so frequently that we have no other choice but to get good at it. In other words: When iteration turnovers are painful, we make the iteration duration shorter.
Here’s a question to ask our team: What would it take to go to half the iteration length, while keeping our current velocity?
We would have to make meetings shorter and more efficient. We would have to reduce the defect rate. We would have to make deployments faster. We would have to stay coordinated at all times, both within and between teams. We would have to follow up rigorously on action points from retrospectives.
That’s when we stop curing symptoms and start acting on root causes of problems. That’s when we start doing continuous process improvement.
That’s when we want even shorter iterations.
