How can we best use iteration?

At the heart of most Agile approaches is a cyclical approach.  Where conventional projects are a single step, development is a continuous process. There is no start and end point and we aim to work at a sustainable pace. 

We proceed continuously in a set of repeating steps called “Iterations”.  It is not a requirement to use iterations in order to follow agile approaches.  There are agile approaches which, unlike Scrum, do not focus on iteration (although it is fair to say this is less common).  There are some cases when personally I would not use iteration.  However, in general, iteration is a viable structure as a basis for the development process.

Shewhart cycle

The idea of viewing processes as a cycle is not new.  We can trace iteration back to the process control approaches of the mid twentieth century.  A very similar cyclic approach was developed by Walter Shewhart in the 1920s for process control. It is best remembered as being popularised by W.E. Deming (as the “Shewhart cycle”) in the 1950s. 

The approach is a repeating cycle moving between planning, execution, data collection and review and acting on that data to refine and review.  In the Shewhart cycle – Plan, Do, Study, Act. We learn by doing, and then incorporate that learning in what we do next.

Sprints

In the Scrum approach iterations are called “Sprints”.  In general, standardising the language helps with communication and I’m focussing on Scrum as a model.  However, I’m not a great fan of the name in this case.  To me a “Sprint” in running is a burst of activity which is temporary and not sustained.  By contrast, our goal is to build a continuous process where we can deliver value at a sustainable pace. 

However, adopting Scrum language definitely helps with messaging.  On balance, I generally standardise on the term “Sprint” rather than the more generic “Iteration”.  You will need to agree in your organization whether “Sprint” or “Iteration” is a better name.  As always, a definite decision on the language in your own organization is preferable to using both.  If you use “Sprint”, I would take care to explain about sustainable pace development. 

Controlling change

An iteration is a way of controlling the level of change involved in a complex environment.  We cannot see all the way to the end of the development in a way which lets us build a predictable plan.  If we could, the environment would be complicated, not complex.  In that case we wouldn’t need Agile approaches. And indeed we see that classical projects are linear and not iterative.

In a complex situation, you do not know all the answers at the start of the development and so the destination is not fixed.  What you want to achieve may change with time.  Feedback from the work which you have done already will inform your opinion about the final destination.  And how you will get to the end point will also change with time.  Learning from doing the work will give you answers about how to proceed which you could not know at the start.

Agile is not chaos.  We can always decide what is the best next step.  We can have a clear idea about the direction we should be heading.  We can decide what actions will reduce risk and gain the most understanding.  As a result we have what we can call a “planning horizon”.  We can plan effectively up to a certain point.  We cannot see beyond that point. 

Where classical project management seeks to give us a map, Agile development gives us a compass.  It shows us the best direction for now

Iteration exploits the planning horizon or the timebox.  If we have clarity of the steps for a period of time, we can make a detailed plan for that period of time and no more.

Predictability is a very desirable property. If we can achieve more predictability by careful planning that is a benefit. However in a complex world, you can believe you can be predictable when you can’t. This leads to situations where people build a plan early on, then can’t handle the situation where the plan falls apart. This is not uncommon when people use tools for complicated environments in complex situations.

Iteration structure

There is a key part of an iteration which is different from a classical “milestone” in a plan.  In traditional projects, a milestone will have a defined scope.  This might be completion of a phase of the work.  It will have an estimated date, and the project manager will report on changes in the estimated date.  If the plan changes, the milestone date changes, and may possibly move significantly.  So the scope is fixed and the schedule is variable.

By contrast an iteration is timeboxed.  That means that the duration, not the scope, is fixed.  This is a key point which may take some time for teams to become familiar.  If an iteration is two weeks long, we plan for the work we expect to complete in those two weeks.  We then spend two weeks on the work.  That two week period is fixed, regardless of what occurs over that time.  And it does not extend based on the amount that we complete.  After the fixed period we return to planning for the next iteration.

Timeboxing allows us to manage the learnings from the work in the most efficient way.  If the iteration were not timeboxed, we might spend a long time on work that we had expected to be easy.  We would have no fixed point at which to step back, reconsider and update the planning.  This tends to be the situation with classical milestones.  By making these fixed scope, there is risk they overrun substantially before review.

Scrum gives a simple structure to iterations which is effective.

• We start with the Sprint Planning session where we agree what we will work on for the next iteration. 
• We move into implementation, working on the items which we have planned. 
• At the end of the iteration, we have two review points. 
  • The Sprint Review looks at progress against the plan for the iteration and the wider plan for overall development. 
  • The Sprint Retrospective looks at how the team can improve and become more effective.

Good practices

I would advise implementing iterations for all or most teams. That is maybe controversial, but I find that iteration gives some useful tools and reference points for building good Agile. You can do good Agile development without iteration but I believe it needs more experience.

Decide what you will call these. Will you use the Sprint structure and naming from Scrum or a different approach (perhaps based on Extreme Programming or other iterative Agile approach). As part of a common language, I would recommend Scrum as a start, and implement Sprint Planning at the start of the Sprint and Sprint Review at the end.

The iteration cycle also brings a natural pause at the end of each iteration.  This gives a point at which the team can review progress.  A reflection point ensures that the team thinks about how to adapt in the future.  Use this to implement robust and regular Sprint Retrospectives.

The reflection point also has value in bringing the team together.  They can celebrate success, often by demonstrating what they have made.  This reflection point can be critical to ensure that a team work together as a team.