Often teams first begin their agile journey with an iteration-based methodology, such as Scrum. This is because the dependable cycle of iterations that these methodologies impose on teams introduce a feeling a stability and predictability.
However, after a team finds success with an iteration-based methodology, it’s often not long before that same team starts to hear the siren call of shorter iterations.
And why not? After all, shorter iterations certainly come with some advantages. But the most commonly cited advantage of a shorter iteration is actually a misconception.
Often teams, as well as their organizations, are lured into shorter iterations by the promise of faster development. After all, if an agile team working in 2-week iterations seems to move faster than their non-agile counterparts, then that same team working in 1-week iterations should move twice as fast. Right?
Not exactly. Working in shorter iterations actually allows teams to deliver sooner…which isn’t quite the same as moving faster. While the ability to deliver sooner is still advantageous to teams, it’s important to recognize this distinction.
Teams working in shorter iterations may not necessarily produce code at a faster rate than those teams working in longer iterations, but they will deliver that code more frequently. And this higher rate of delivery means that these teams will become more adaptive, both in terms of their product and their process.
Teams who deliver code more frequently are better positioned to measure the market’s response to those deliveries and then adapt their product strategy accordingly, improving their chances of success. And by the same token, these same teams are also afforded more opportunities to reflect on their own product delivery process and to experiment with changes in hopes of improving that process even further.
However, longer iterations are not without their benefits, either. The most commonly cited benefit of longer iterations is that they tend to be more efficient. However, this often isn’t as straight-forward of an assumption as it first seems.
Many teams believe that the greater efficiency of longer iterations stems from the fact that a smaller proportion of the team’s time is spent in planning and review events, as opposed to delivering the work at hand. But the flaw in this assumption is in failing to realize that as the time to the next delivery increases, the amount of planning that must occur between those deliveries must also increase. In fact, this point is so salient to teams who are following the Scrum framework that the Scrum Guide provides explicit guidance to how the duration of a team’s planning events are expected to change as the length of their iterations, known as Sprints, increase.
For example, for a 1-month Sprint, the Scrum Guide recommends a Sprint Planning event of 8 hours but also specifies that this event should be proportionately shorter as the Sprint decreases in duration. This awareness of how a team’s planning commitment changes in relation to the length of their iteration tells us that it’s unlikely that teams will spend a smaller proportion of their time in planning during longer iterations.
But even without the reduction in the proportion of time spent planning, there is still one major benefit to longer iterations. This benefit is that your team is able to work for a longer period of time on a single set of tasks without interruption. This longer period allows your team to build momentum in their work, attain greater focus, and increases the chances of your team achieving a state of flow. This single benefit alone is often enough to justify working in longer iterations to most teams.
There’s also one other key benefit to longer iterations that, at first, may not be as obvious. While the higher frequency of delivery of shorter iterations enables a team to be more adaptive to changes in the market, this higher adaptability can also result in thrashing for a team whose Product Manager uses that adaptability to chase a new opportunity every iteration.
A longer iteration encourages Product Managers to redirect their team’s focus less frequently, which gives Product Managers more time to reflect on new opportunities and decide whether they’re the best use of their team’s time and energy. This helps to maintain their team’s focus longer, which can result in that team being more effective over the long term.
As we’ve discussed, both shorter and longer iterations each have their own advantages. So, if this is the case then how do you know which is the better choice for your team?
The right choice of iteration length for your team is likely to be more a function of the specific product that your team is building, and where it is in its lifecycle, rather than of your team itself. A newer product, whose team is still trying to identify the optimal vision and strategy for that product, often benefits from the greater adaptability afforded by shorter iterations. This is because the higher frequency of delivery enables more experimentation by the team and faster decisions based on the results of those experiments.
More established products, on the other hand, whose vision and strategy are largely established are more likely to benefit from longer iterations. While long stretches of time between opportunities for feedback does increase the risk to your product, established products tend to be more stable and carry less risk between deliveries so they are less prone to this risk than a younger product.
For this reason, many teams find it beneficial to begin development of a new product with shorter iterations and use these iterations to quickly identify the most promising vision and strategy for their product. After the product’s most likely path to success has been identified, then these same teams will often evolve towards longer iterations to take advantage of longer periods of focus as their product matures.
The prevailing belief that shorter iterations are always better for all teams is a fallacy. While both shorter and longer iterations have their own benefits, the right choice for your team depends more on the product that your team is building and where it is in its lifecycle.
This means that your team is likely to see the most benefit by allowing the needs of your product, as well as what decisions are most likely to make that product the successful, drive their choice of iteration length.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
