Time Boxed Iteration Considered Harmful
Iteration, or iterative development, is good.
Time boxing, is good.
Time boxing iteration, is bad.
Basically, iteration and time-box are two different things.
Iteration: Also called ‘successive approximation’, is a problem-solving or computational method in which a succession of approximations, each building on the one preceding, is used to achieve a desired degree of accuracy.
Time-box: Is a time management technique where each time-box allots a fixed period of time for a given activity.
Time-boxed (or fixed-length) iteration does bring some benefits like focus, rhythm, regular feedback, etc. Even freezing scope within an iteration has some advantage too, like forcing the stakeholder prioritizing seriously.
But fixed-length iteration does have some pitfalls, on both practice level and subconsciousness level.
Subconsciously, velocity based planning for time boxed iteration focuses on utilization, not value.
Since iteration length is fixed, the team needs to find enough tasks to fill it at the iteration beginning. It may introduce some unnecessary tasks for this moment. We should focus on the baton, not the runner.
Subconsciously, time boxed iteration implies the feedback cycle is same as the iteration length.
For example, we will show case to clients at the end of iteration. It doesn’t mean we cannot do it more frequently, more instantaneously. While nothing can stop mature teams doing right thing, there is something gives immature teams excuses not doing what they should do.
At practice level, time boxed iteration couples planning and developing.
By coupling, I mean practices like iteration planning meeting becomes an inherent overhead of iteration. We have to have a regular planning meeting for each iteration. We can only do it in a fixed interval. Yes, we have to and can only do it at the iteration beginning. It might be too inflexible to embrace changes, or becomes an unnecessary overhead.
At practice level, time boxed iteration couples delivery related work and team grow up related work.
Though running retrospective meeting in a fixed interval is reasonable, it doesn’t mean the planning rhythm or delivery rhythm has to be fixed. Again, it could be more flexible.
Then what’s the alternative?
The answer lays on the essence of iteration. The short answer is:
Each Story is an Iteration
According to the definition of iteration above, any finished work which can be used as the baseline of other works, any finished work which advances the progress to the final result, is an iteration. So let’s take the idea of iteration to the logical extreme: each story is an iteration. Each completed work item represents a successive approximation towards that which our customer values, each builds on the one preceding. We learn from its implementation when each work item is completed.
Fine Granularity is hard to track?
Lots of methods come to rescue. FDD(feature driven development), MVP(minimum viable product), story map, each one can help to organize tasks to self-consistent groups. Time boxing is just one way to organize tasks. DON’T be limited by time box!
Continuous delivery decouples the delivery and team building.
For delivery related activities, like analyzing, coding, testing, deploying. iterative is ok. And if we take the idea of iterative development to the logical extreme, we will get continuous delivery. It makes the time-boxed iteration meaningless.
For team building related activities like retrospection, keeping it in a fixed-interval way is ok, though we can always do it on demand.
In a summary, below are the alternatives for time-boxed iteration:
- Kanban shifts the focus from runner to baton, from utilization to value.
- Kanban and Continuous Delivery streamlines the delivery, making time-boxed iteration useless.
- FDD, MVP, etc, are good ways to organize baton.
References:
