What is an Iteration?
In Agile terms, an Iteration is a fixed period (a ‘timebox’), usually very brief (typically 2-3 weeks, though longer for new Agile teams or teams who are new to Agile), within which an agreed scope of work (stories) will be delivered by a team.
A single team may carry out one or many Iterations within a single release. Individual iterations are identified and scheduled in the Release Plan.
This is what an Iteration looks like:
What is Iteration Management?
Iteration Management is the process the Agile team uses to execute the individual Iterations identified in the Release Plan. That is:
- It translates the Iteration’s why (the purpose assigned to it in the Release Plan)
- and what (the backlog items assigned to the individual Iteration)
- into who and where (the Iteration Team)
- when (the Iteration schedule)
- and how (the Iteration Plan and its associated tasks).
The Iteration Management process
Despite its name, Iteration 0 is not at all like other Iterations. It is actually part of Release Management.
The Iteration Management cycle
Iteration Management spans all the tasks needed to implement the Release Plan. This includes:
|Plan the Iteration|
|Refine the Backlog|
|Conduct a Showcase|
|Deploy implemented stories|
These tasks are described in more detail below.
The Iteration Management tasks
Based on the task list outlined above, Iteration Management can be divided into a small number of tasks.
Plan the iteration
The Iteration Planning process
Overall, this is what Iteration Planning looks like:
For a step-by-step account of Iteration Planning, see here.
Iteration Planning in the Agile lifecycle
As the diagram below shows, Iteration Management begins with planning the iteration early in the Agile lifecycle as a whole. This is not the only point at which the iteration is managed – iterations are open to change, refining and replanning at any time.
This process produces the Task or Story Board and agrees the detailed tasks the team will undertake during the iteration.
Although it is rarely discussed, about 90% of an iteration consists of the team getting on with implementing stories. Agile depends entirely on the assumption that the main reason people come to work is because they want to create robust, high quality solutions to the ever-expanding, ever-changing needs of users and of the organisation as a whole. So there should be no problem with the team knowing what to do with their time, given the opportunity.
Managing the team’s Daily Work involves only a very a few basic ‘management’ tasks and ceremonies:
- Daily Stand-Up Meetings, where progress is tracked.
- Updating the Task or Story Board, Burn Chart and other ‘information radiators‘.
It’s also during this Daily Workflow that the basic technical activities take place:
- Routine development tasks (i.e., working with the user to complete stories).
- Committing code to the mainline regularly, to ensure that any technical issues are found and fixed quickly.
- Once the story is complete, optimising the code by various refactoring techniques.
But perhaps the most important thing about the Daily Workflow is the way it is designed to minimise interruptions. It achieves this most of all by making sure that the team is careful insulated from disturbance:
- As a self-organising unit, the team does not need to obtain information from external experts or decisions from external authorities.
- The completeness of the cross-functional team means that they seldom need to look outside – and so break the rhythm of everyday productivity.
- The Iteration Lead and Product Owner provide an effective interface with the outside world, so team work is seldom disturbed by outside demands and events.
- Where outsiders are allowed in, it is on condition that they observe rules that minimise disruptions.
- The developers’ issues, obstacles and problems are sorted out for them by the Iteration Lead.
- Collocated teams have minimal breaks in their work caused by distant and indirect forms of communication.
The result of all this should be iterations that look like this:
That is, apart from Daily Stand-Ups and a very few short extra tasks at the start and end of each iteration, the team should be focused entirely on the backlog.
Yet everyday work remains an issue. The crucial problem is for the team to understand and implement to the full the full range of Agile disciplines. Conversely, it needs to be constantly aware of, and working to eliminate, the great enemies of agility:
- Fear – of failure, and of the consequences of challenging authority.
- Rigidity, whether in the face of change from outside or opportunities for new experience from within the team.
- Isolation – from users, from the business and operational environment, and from each other.
- Silos, especially of their own making.
- Loss of perspective.
- Disempowerment from any of the key areas of decision-making on which rapid, flexible delivery depends.
Where these are detected – even a hint – the team needs to work to bring any such threat to the surface, admit to its own failings and work to deal with them.
Refine the backlog
At least once during each iteration, the team should take out an hour or so to walk through the backlog, not only for the remainder of the current iteration but also for the remaining iterations of the current release and, if possible, for later releases.
The aim of this activity is to apply any new experience or knowledge gained in the course of the current iteration to improve the backlog. This may include challenging the continuing relevance of future stories, reviewing estimates and priorities that no longer seem realistic, and so on.
This activity makes it much easier to plan future work quickly and realistically.
Click here for more on refining the backlog.
Near the end of the iteration, the team presents any completed stories to the Product Owner and (usually) any concerned stakeholders.
This is not an acceptance process – the stories have already been agreed by empowered users who worked with the developers to implement them in the first place. Rather, it is to demonstrate progress, reassure the participants and to encourage an open exchange of views and ideas about the work that has been completed – and the work that is still to come.
Click here for more on conducting showcases.
Deploy implemented stories
In general terms, once the Showcase is complete, the team releases the solutions they have implemented. However, exactly how this happens depends heavily on the individual organisation’s deployment strategy. Some common options include:
- Deployment directly to end-users.
- Delivery to a formal deployment team.
- Implement to a staging area, from which some other organisation will eventually deploy it, typically according to a schedule the development is not involved in.
Where there is a complex mix of Agile and non-Agile teams, the situation can quickly become still more elaborate.
Key to successful Agile is making as much of this process as automatic as possible – what Agile refers to as ‘continuous integration’ – or, more and more frequently, ‘continuous deployment’.
This is not only a technical issue. In addition to the right tools, the whole sequence of functions and authorities involved in the delivery process need to be aligned so that the process can be completed in a smooth, uninterrupted sequence. This is frequently a major challenge, as the different units involved often have quite different approaches, including:
- Complex interfaces.
- Different approaches to and rules for acceptance.
- Manual vs automated or tool-based practices.
- Mismatched tools.
- Mismatched schedules.
- Mismatched agendas.
The last step in an iteration is the Retrospective. Much like a traditional ‘lessons learned’ session, this is a short meeting at which the team will:
- Review what happened during the iteration (successes, failures, risks, unprecedented problems, etc.).
- Identify ways to improve.
- Agree priorities and a plan to make the necessary changes.
For more on Retrospectives, click here.
How does the Agile team use the Iteration Plan?
As far as the team are concerned, the Iteration Plan takes the day-to-day form of the Task or Story Board, and is under constant management by the team as a whole, especially during Daily Stand-Up Meetings.
By showing how the iteration will unfold through its various iterations, the Iteration Plan encourages the team to visualise their future work in more concrete terms, to think about the flow of work as a whole, and to ask questions like:
- What obstacles stand in the way of implementing the backlog as quickly and reliably as possible?
- Will my current work have a positive or negative effect on later work – mine or anyone else’s?
- What future issues should I be raising now, so we don’t get held up in future?
- How can I help my team mates with their work?
- Is this the best way to meet our overall iteration and release objectives?
- Am I accumulating technical debt that someone else will have to deal with?
Knowing the answers to questions like this will make it much easier for the team to anticipate change and avoid making bad, short-term decisions. Conversely, with this kind of insight, what might have been no more than a series of uncoordinated tasks can be turned into a smooth, well-structured iteration.