Get certified - Transform your world of work today


We Iterate . . . So We Are Agile?

1 March 2013

Unusual Concepts

Do you know that working with iterations does not make you automatically an Agile team? Moreover, it does not even mean, necessarily, that you are using iterative development.

Paradoxically, it is possible to be Agile without use of iterations. This is true if your team is using Kanban, for example.

Let's get into details.

What is iterative development?

"Iterative development acknowledges that we will probably get things wrong before we get them right and that we will do things poorly before we do them well" (Goldberg and Rubin, 1995).

Iterative development can be compared with an idea that is transformed into a rough prototype of a product, which evolves and becomes better over time. Most likely it will be quite a crude product, as it may miss many features. The good news is that it will allow us to get fast feedback and decide if we want to move on or not.

Let's use a metaphor, developing Mona Lisa — which John Armitage introduced in his paper "Are Agile Methods Good for Design?" (2004). It is a brilliant example, using a portrait to demonstrate the iterative development approach.

I need to point out here that this example is exaggerated. What I mean is that you do not necessarily have to "iterate" the whole product at once. Iterative development simply supposes any change made, not requiring obligatory global changes throughout a product.

What is the incremental development?

Incremental development implies adding piece after piece, similar to building a house one brick after another.

Again using the example of the painting, the incremental development approach would look like a gradual creation without any changes made, only additions. It is impossible to imagine that Leonardo da Vinci was able to create any of his masterpieces in such a strange way.

As Alistair Cockburn writes in his blog, "The word increment fundamentally means add onto. The word iterate fundamentally means re-do."

In real life and in our projects, we mostly run into a combination of iterative and incremental types of development, though clean variants are sometimes possible. Thus iterations and iterative development are not the same. Scrum uses the right terminology: In Scrum, iterations are called sprints.

Iterative development deals with change

Scrum determines a sprint as a timebox of one month or less. There are a lot of "Agile" teams that suffer from excessive incremental development. The product owner constantly compels a team to add new features; a product rapidly grows until it bursts like a soap bubble because nobody needs it. Vitally important feedback is not received in time and, as a result, the necessary changes are not brought in. Total failure.

There are a huge number of Waterfall teams that perish from unrestrained iterative development and endless changes. Those teams live in the vicious circle of permanent alterations; they don't have time for moving and evolving their product.

Agile development suggests the combined approach, where a balance is maintained between incremental and iterative development.

How to find such a balance?

There is no prepared recipe for success. You will have to create it by yourself, taking into account a concrete project, your environment, and the product you're working on. But there are a few principles that are useful to follow:

  1. Be prepared for the inevitable changes. If you've done something once, this is not an iterative development. A product without changes is a bad product.
  2. Get permanent feedback. Only validated knowledge (Eric Ries, 2010) is valuable for us. Do you think your product is brilliant? Maybe you're right, but this is just your assumption. Put it as quickly as possible in the hands of the users and get their feedback.
  3. Let the user stories go through the backlog up to three times. This approach is preached by Alistair Cockburn and Jeff Putton.
  4. Use Scrum, which ideally fits the incremental iterative development process. Scrum has built-in mechanisms for this.


Cockburn A. The Impact of Object Orientation on Application Development. IBM Systems Journal, November 1993.

Patton J. The Neglected Practice of Iteration. StickyMinds. Dec 2007. Online at

Cockburn A. Using Both Incremental and Iterative Development. Online at

Sutherland J. Iterative vs. Incremental Development. Online at

Ries E. The Lean Startup. Crown Business. 2011.

Schwaber K., Sutherland J. Scrum Guide. October 2011.

Kenneth S. Rubin. Essential Scrum. Addison-Wesley Professional. 2012.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up