Agile software development generally revolves around a production system that is based on iterations or sprints. These are short periods of activity with a view to producing what is referred to as "potentially deployable code". Several iterations are put together end to end or sometimes with overlapping phases across distributed teams to form what are referred to "periods of sustained activity".

If iterations can be implemented in software development they can be very effective in many ways - best to look this up in the scrum papers as I don't want to focus on that here. What I'm interested in today is the difference between running iterations and incremental software development or phased software development. I want to do this because there are many teams who would say they run iterations or sprints when in fact they are running increments or phases and therefore missing out on the real benefit of iterations or sprints. I think this is best illustrated with some diagrams as follows:

In the first instance the customer gives us some requirements. Traditionally these would be analysed and a plan offered for their delivery with some contingency added in for safety and the whole lot attempted in one go. Even these traditional plans may have contained phases of development but often this whole block of requirements might be referred to already as "phase 1" - which introduces awkward conversations at the beginning of every meeting where people struggle to agree that they are there to discuss "build phase 3" of "program phase 1" and it all gets a little confusing and frustrating and... risky.

To ensure we implement true iterations the first course of action is to reduce the requirements into potentially deployable chunks of functionality, size them and arrange them in priority order, thus.

Note that its important to understand the value of these chunks too. The priority must be based in part on their relative value. This will help us to work with the customer to identify where the division is between "must have" and "nice to have" - red arrow in the diagram above. This helps later to support negotiations with the customer over change of requirements and setting and responding to their expectations. Next divide the chunks into iterations or sprints - roughly equal sized groups of chunks.

Note that here its important to have some understanding of when the customer would like to see some software deployed. Ideally and sensibly this is sometime after the point where we estimate all the "must haves" can be delivered - if its the other way around then we have a different challenge - lets make this assumption for the sake of the point I'm trying to make here. Next we run the first sprint.

Suppose we manage to deliver all the green functions but fail to deliver the red ones. For the first time we encounter the difference between iterative software development and incremental software development. If we decide to or are under pressure to delay the end of the sprint to make sure we complete the red items we can be certain that we are running an increment or phase. On the other hand if we ask the question "are the delivered green functions collectively deployable?" then we are running iterations. It doesn't have to be deployable but the customer may be pleasantly surprised and realise that the software delivered so far if deployed will add value to the business in which case it should be deployed.

Now we come to running the second sprint. But here we find that the customer has generated more requirements (purple). This can happen anyway as we all know so well but its actually more likely to happen in terms of feedback to the work completed in sprint 1. This is good and should be considered a process of validating the communication of original requirements and the team's interpretation of them.

Before we can run the second sprint we need to add in the new requirements because they are more important than those in the 3rd sprint. In order to do this we need to remove some of the original sprint 2 candidates. We also need to learn from sprint 1 just how much work the team can produce in the sprint period and make sure that the quantity of work included in sprint 2 does not exceed this limit.

What we're left with is the remainder of the requirements - they still contain 2 of the features we wanted to deliver in sprint 1 but this is traded off by the fact that we are going to fit in 2 new requirements that the business didn't even realise they needed ... and we're going to be able to deliver these before the green arrow. Further down the line this process may result in a trade off that ultimately means the red arrow overtakes the green one but because we are running proper iterations this won't matter. Lets recall that if we were running increments or even an all or nothing traditional waterfall project we would be in a bit if a state already - we would be behind schedule and we wouldn't be aware of the new important requirements.

In addition iterative software development allows us to focus on the detail only of the next sprint this is important - lets consider the 2 features we dropped from sprint 2. There is all likely-hood that these may no longer be required at all - its possible that the 2 new requirements are a better solution to the problem the original two were intended to solve. This benefit is only half realised when running increments - the benefit of focusing on detail only of the next sprint is there but the advantage of realising some requirements become redundant is difficult to realise. In this example note that sprint 2 contains only 1 of the requirements that we missed in sprint 2 the other has been abandoned.