Is iteration always the answer?
Although most teams working with Agile approaches use iteration, there’s nothing in the Agile Manifesto which directly links Agile to iteration. There are statements in the Manifesto which can be well supported by iteration. These include “Deliver working software frequently“, “Working software is the primary measure of progress“, “At regular intervals, the team reflects“. However there is no requirement to have iterations to “be agile”.
Iterations are a great tool, but they are not the answer to every problem. An iteration has some overhead, or in Lean terms “waste” (as always, that sounds harsh, so familiarise yourself with what “waste” means in Lean). Like any planning area (as discussed in the Play on “noestimates”) we should always balance the value against the cost.
At one extreme, you may already know all the answers. Then it might be possible to plan out your whole development in a classical way. In that case, you would build a plan and execute that plan to the end. And that’s a great approach for the right work, although not “Agile”. As we have seen, this is unlikely in a complex software environment.
At the other extreme, you may be edging into a chaotic world and find you have almost no visibility of what will happen and find yourself finding your way day by day.
Adjust the iteration length
How long is an iteration? That is a choice for your organization. As with many parts of Agile, there is no enforced right answer. Iteration length is driven primarily by the stability of your environment.
Scrum recommends using a Sprint length of one to four weeks.
- If you pick too long an iteration, the team may struggle to keep the plan stable. The planning horizon may be less than the iteration length. This would result in the team adopting a lot of change during the Sprint.
- If you pick too short an iteration, the overhead of planning each iteration may be quite high. This is especially true when the team are new to the process.
Generally a good starting point for teams is two weeks per iteration. As with everything in the process, the team can use retrospectives to review how well this is working.
Not using iterations
Although iteration is a valuable tool, we need to remember it is not the end goal. The end goal is continuous development – a smooth flow of value to the customer. If iteration impedes this, or at least does not assist it, then it is “waste” and should not be adopted. In most cases however, the balance is likely to be in favour of iteration.
There are three scenarios where I would feel iteration is not needed. I feel none of these apply to most software development.
Not complex
There is no need for iteration if the environment is not complex. Imagine that the team can put together a full plan for completion. A reductionist approach is effective. They can write down all the work, predictably, and then execute reliably on that plan.
In that case we have a complicated environment, not a complex one. In most cases it will be simpler and more efficient to treat it as such and to use a fixed plan to completion.
However, I suspect this is unusual in software development.
Reactive work
The second case is more common. The team may have no long term plan. Work comes in to the team continuously and is reacted to immediately. This is typically the case for a support group, supporting customers or internal developers. An iterative approach relies on stability over the iteration.
We build a plan for the iteration and deliver on the plan. If a team is driven entirely by a support queue of short term requests, we may be able to shorten the iteration time. If we plan the work into week-long batches, we can still use the same mechanism to plan and prioritise.
But if a week response time is really not working, and each item must be reacted to immediately, iteration is not the answer. We now have a continuous flow process by the nature of the work.
When a Sprint’s horizon is too long the definition of what is being built may change,
The Scrum Guide
complexity may rise, and risk may increase.
Experience
The final possibility is that the team might evolve beyond needing iterations. Iterations give very clear checkpoints for planning and review. The very best teams may find they don’t need these. They plan backlog brilliantly, refining constantly. They talk to stakeholders all the time, showing every piece of work and discussing its impact on the planning. It is possible, but few teams operate at this level.
Good practices
I would advise that you consider iteration as a starting point. However, it is worth reviewing whether any teams should not be using iteration. If so, be very clear why this is a good practice.
If not using iteration, make sure you consider what you are getting “for free” with iteration and will need to ensure. For example, there are clear points for planning and review. There is a visible stable plan at each iteration which can be communicated. There are regular pauses for reflection. These will need to be build into any continuous flow process.
Leave a Reply