3. Iterations

As in XP and Scrum, work is conducted within the framework of time-boxed iterations - also called ‘sprints’. These are normally two weeks in length, sometimes one week, sometimes longer, although iterations of three weeks should be avoided. Iterations of four weeks or more, while once common, are often seen as as too long now.

Changes to iteration length should be rare. Teams may occasionally decide to move, say, from two-week iterations to one-week iterations, or to four-week iterations. Once changed, the team will stay in this mode for several iterations before considering another change.

Ad hoc changes to iteration length should be avoided, although at times such as Christmas it might make sense to suspend iterations, or have just one iteration of a longer length then usual.

What is not allowed is extending an iteration by a few days because the work planned for the iteration has not been finished. Not only does this disrupt the following iteration, it also destroys the value of doing work in iterations in the first place. It destroys the deadline effect, it destroys benchmarking, and it negates the ‘get good at doing things in short bursts’ ethos.

Having to work to a deadline not only focuses individuals’ attention, it also limits the work in progress, forces teams to address problems that might otherwise be hidden, and stops procrastination. People are actually quite good at working to deadlines.

The next iteration starts immediately after the previous one ends. Often the end of iteration meeting for one iteration simply flows into the planning meeting for the next iteration. The planning meeting (described below) marks the start of the next iteration. During the meeting the board is reset for the next iteration of work. Once the planning meeting is complete, work begins.

The first big difference with Xanpan iterations compared with Scrum or some other methods is that work can, and does, flow between iterations. Taking work into an iteration does not mean that the team is in any way committed to doing the work.

During the end of iteration review, work still in the ‘to do’ section of the board is examined and may be returned to the backlog, or removed (de-scoped) completely if the team and Product Owner agree. In most cases though work remains in ‘to do’ and is simply left in play and carried to the next iteration, forming the starting point of planning.

The second major difference from Scrum is that Xanpan allows both planned and unplanned work. If teams can plan all the work for the next two weeks and stick to the planned work, great; if not, then the team accepts the work and does it. By tracking the planned versus unplanned work, this can be factored into forecasts.

Xanpan differs from Scrum on this point for several reasons:

• Allowing work to flow from iteration to iteration creates Kanban-style flow mechanics.
• Forcing stories to be small enough to fit within an iteration regularly results in stories that are too small to have any business value - especially for teams new to iterations. It is more important that a story delivers business value than that it fits in an iteration.
• Over time teams will get better at slicing stories small enough to fit into an iteration and big enough to have value. Over time the team will get better at delivering stories in one iteration. However, this is hard when a team is moving to iterative working.
• Teams in some domains, such as embedded and telecoms, or using some technologies, such as C++, and those working with unfamiliar, often legacy systems, find it harder to reconcile small stories with business value.
• Rather than use Scrum style commitment, teams are encouraged to try and do more work than they expect to do, and it is accepted that not all work taken into the iteration will get done. There is little to lose by trying for more. Statements about what will be delivered at the end of the iteration are statements of probability, e.g. “The highest priority story is almost certain to be delivered, the next is probable, the next maybe and the last unlikely.”

In an ideal world a team would size every story to fit within an iteration and deliver value. Teams are encouraged to aim for this. But even here there is a problem:

Assume there are two stories: A and B; each will take 7 of the 10 working days in the sprint. Both are acceptable: the team starts on A and completes it as expected. On day 8 the team is ready for a new story. Do they pick up B? Some Scrum teams would not, as they may never have scheduled the work in the first place. At some point, in planning or when A is done, they will look for a piece of work that is 2 days long.

This is the Scrum equivalent of dry-stone walling. A suitable story may not exist: even if it does, who is to say it is a priority? Why wouldn’t the team start on the next highest priority story rather than go hunting through the low priorities for one that happens to be the right size?

3.1 Releasable

The key point about the end of the iteration is that the team should have a releasable product. This does not mean that the product is released: hopefully it is, or it moves straight to release after the end of the iteration. Essentially whether a product is released at the end of an iteration or not is a business - most likely a marketing - decision. At the end of every iteration the team gives the business an opportunity to release the product as is.

When work flows from iteration to iteration regularly there should always be some stories that are completed in an iteration even if some are carried over. Occasionally there may be an iteration where nothing is complete; this isn’t good, but it might happen. If it happens regularly then there is probably a problem that needs to be addressed.

Increasingly teams are not only practising continuous integration, but continuous deployment. As work is ready it is pushed to release. When teams get good at doing two-week releases, this is a logical next step. This mandates that each story - each blue - is in its own right releasable.

3.2 Iteration sequence

Although an iteration follows the same basic sequence as a Scrum or Extreme Programming iteration for completeness, it is best to talk through the iteration.

An iteration starts with a planning meeting; these are described in detail in the next chapter. During this meeting the Product Owner will present the work they would like done in the next iteration. This work should be presented in absolute priority order - 1, 2, 3, … - no Moscow rules, no equal priority.

The development team will break this work down into tasks. The team and Product Owner then need to reach agreement on what will be done. Xanpan uses a variation of the XP velocity system to gauge how much work the team should achieve. Teams are advised to accept slightly more work than they expect to do, but to expectation-manage the message. Nothing is guaranteed, so it is important that those who want to know what the iteration will produce understand that some things are more likely than others, and some things won’t be delivered.

Once the iteration planning meeting is complete, work begins. Each day - preferably first thing in the morning - the team hold a stand-up meeting of no more than 15 minutes to synchronise and share their progress and issues. Ideally no other meetings are needed.

At the end of the iteration the team should at the very least undertake a demonstration to stakeholders. It might well be that the Product Owner has seen the work, as it is completed and has no need for a demonstration: they may even be the one running the demonstration.

The best teams will go straight to release - after the demo or perhaps skipping the demo altogether - as the iteration closes. It is then time for the review and retrospective.

The review is purely a bookkeeping exercise: count the cards and points, update any tracking systems, file any reports and so on. Retrospectives are intended to help the team improve their working in the next and subsequent iterations.

Retrospectives may be as informal as a once-around-the-table opportunity for everyone to say how they thought the last iteration went and what they suggest for the next one. Alternatively, they may be formal, with set exercises such as dialogue sheets (http://www.dialoguesheets.com) or from a book (e.g. Derby and Larsen 2006; Kerth 2001).

With the retrospective complete, it is time for the next iteration planning meeting. There might be a lunch or coffee break between the two meetings, but there is no need for a lot more.

3.3 Mid-week to mid-week

Figure 3 deliberately shows an iteration running mid-week to mid-week. My experience, and the experience of others assisting teams, is that running iterations mid-week to mid-week is more effective than running them Monday to Friday. Why this should be so is difficult to pin down, but there are several reasons that I believe contribute:

• The ‘Friday afternoon effect’. If an iteration resets on a Monday, then anyone completing a piece of work on Friday will not be particularly motivated to start another piece of work. In many environments it is common to finish early on Friday, or take a long lunch. If the iteration has several more days to run, there is less incentive to ‘slack off’ on a Friday afternoon.
• Monday refresh. I believe there is research showing that people are more effective at the start of a new week. I hasten to add I have not read this research myself, which is a little lax of me. Anecdotally many people, if asked, say their most productive day is Tuesday. Assuming there is truth in these tales, it is a good reason to avoid meetings on Monday and Tuesday.
• Public holidays. In the UK and many other countries many public holidays occur on Mondays. This means that there is more chance of an iteration meeting being disrupted if it is scheduled on a Monday.
• Personal holidays. Again in the UK and many other countries individuals are more likely to take a Friday or Monday off as a long weekend. Consequently planning meetings on these days are more likely to be missing a team member.
• Meeting rooms. In a surprising number of organisations booking a meeting room can be difficult, either because there is a shortage of rooms or the booking process is complex. Therefore it is worth striving to book rooms further in advance on a regular basis, and minimise changes. Indeed, it can be impossible to book a meeting room in some companies for the day after a public holiday, because all the meeting conveners are trying to move their meetings back one day.
• Regular schedule. Keeping to a very regular schedule has many benefits, one of which is that meeting rooms can be booked weeks, months, even years in advance. If you have an electronic booking system, set the meeting to repeat with no end date.
• Time zones. Although it is best to collocate teams, many find this is not an option. A team in Holland has programmers in Houston; a team in London has analysts in New York, a team in Pennsylvania has members in Bangalore and so on. Thus holding any whole team meeting means someone may need to work late or arrive early. Asking team members to work late on a Friday, or arrive early on a Monday, encroaches on family time and space.

There are probably more reasons that could be added to this list. None is in itself conclusive, and you might choose to argue with some of the points. As I said, experience - not theory - shows mid-week to mid-week is best. Perhaps the best advice is to experiment for yourself.

3.4 Iteration length

The default length of an iteration is two weeks. You need a pretty good reason to do anything different. If in doubt, do one-week iterations at first. You may later extend them to two weeks or four weeks.

I find monthly iterations to be too long. Remember that software has diseconomies of scale: pushing up to a month allows too much to change, and means that too much needs to be planned and scheduled in a planning meeting.

There are natural human rhythms and rituals based on weekly, fortnightly and monthly iterations. The working week is a week long, many people take two weeks for their summer holidays, the lunar month is almost 28 days. I have never heard of a natural cycle that takes 21 days. In English and many other languages there are words for these time-frames: week, fortnight and month. What we do not have is a word for a three-week period - and I have yet to find a language that does! It is hard to think of any human or natural cycle that takes 21 days to complete. Yet it is not uncommon to come across teams that run three-week iterations. Usually these teams exist within a corporate IT environment, and it is not uncommon to find mini-waterfall processes within the three-week iteration.

Typically when asked “Why did you choose three weeks?”, they reply “Because we don’t think we could do anything useful in two weeks”. This misses an important point of short iterations: they exist to make you better.

Working in short iterations has many benefits: predictability and routine, reference benchmarking and more. However the iterations themselves are not the biggest benefit. The biggest benefit comes from the changes that need to be made, the problems that need to be resolved, the processes that need to be changed, and so on, in order to work effectively in short iterations.

Iterations are not an end in their own right - rather they are a tool for making you better. Forcing yourself - and others, processes, tools and so on - to produce something useful, valuable, in two weeks, forces change for the better.

A team that is just starting with Agile is well advised to start with one-week iterations in order to practise the starting and stopping activities, see problems and resolve them.

3.5 Release schedules

Many teams will synchronise software releases with the iteration, so a new version of the software appears every two weeks. Better still, individual blue cards would be releasable, so the team could release multiple times during an iteration. Stories of Kanban, XP or Scrum teams releasing many times during a week are increasingly common: this is the start of ‘continuous deployment’.

Before trying for releases during the iteration, a team need to be capable of releasing at the end of the iteration (or even releasing at all). For a team which currently finds it difficult to release the first objective is to be able to release every two weeks. Once this can be done fairly painlessly they can then consider more frequent, even smaller, releases.

For every team releasing during an iteration there are probably more teams releasing at the end. And, as far as I can see, there are more still who release after several iterations. For example, six two-week iterations followed by a quarterly release used to be fairly common. Releasing every second iteration, so once a month, is also common.

I myself ran a team that made one monthly release after four one-week iterations. Occasionally there was a fifth iteration to stay with the publicised release schedule of ‘first Tuesday of the month’. The first planning meeting of the new cycle was longer than the subsequent ones. While features did change, it was broadly possible to see what was coming for the next month and work on the details iteration by iteration.

3.6 The CEO test

Imagine you have just finished an iteration, perhaps yesterday or the day before yesterday. The CEO walks in and says “Bad news, we are out of money, we can’t make payroll”. While you are taking in this shocking statement he adds “Of course, if you have something I can release today, we can get some revenue and we have another month”.

If your answer is “Sure, here’s one we just finished”, then everything is OK.

If on the other hand your answer is “Well we just finished something, we are code complete on some stories, but we need another month or two of test-fix-test-fix”, then you are out of work and out of pocket.

Never be tempted to do more work which looks done but isn’t. Get good at finishing things completely, to release standard. Do fewer features and more quality.

Do this and you not only give your CEO options - you change the game.

3.7 References

Derby, E., and D. Larsen. 2006. Agile Retrospectives. Pragmatic Programmers.

Kerth, N. L. 2001. Project Retrospectives. New York: Dorset House.