Do you really iterate?

Agile methods were born in response to the waterfall “all at once” release model. Their primary weapon to fight it is iterative development. Working in short iterations is a “poster boy” of agile, something people instantly understand, even without the knowledge of agile philosophy. It is also the first practice teams adopt. From my experience, no matter how few agile practices they use, they usually do iterations.

Or don’t they?

Are you sure you really iterate?

Iterative vs incremental

There are two ways of splitting work into a series of smaller steps: incremental and iterative.

Incremental means building a product piece by piece, from complete, finished elements. Think of a Lego bricks set. You add a new brick on top of the previous one, making your construction a bit more complete with each step, but don’t go back to reposition or change the color of the bricks you’ve already placed.

Iterative means starting with the rough product and gradually refining it until the final version emerges. Think of a wooden sculpture. You first chip out big pieces of wood, revealing a general shape roughly resembling a human body. In the next pass, you make arms, legs and a head. Then fingers, a nose and ears. Finally you carve the fine details like wrinkles or hair.

Incremental-only development

My observation is that many teams claiming that they iterate in reality use fully incremental approach.

They usually start with a strictly defined set of requirements or fine-grained mock-ups. Quite often officially approved. Then they build the app screen by screen. They properly integrate, test and demo their work after each “iteration”, but they rarely get any serious feedback nor refine already implemented features in any significant way.

Sounds familiar?

This is still much better than the waterfall approach and gives several benefits:

  • ability to calculate the team velocity, monitoring the progress of a project and forecasting its completion date
  • opportunity to integrate and deploy often
  • ability to prioritize features and to kill or release the product early when it exceeds the budget
  • opportunity to retrospect on and improve the development process at the regular intervals

However, all of these benefits are purely process related. Such an approach can help you improve the accuracy of your estimates, the quality of your code review or your deployment automation, but it won’t result in any product improvements from the end user point of view.

Incremental development helps improve how the product is build, but not what is built.

Iterative development

Iterative approach, on the other hand, focuses on what is built.

Teams doing iterative development usually start with only very sketchy requirements, typically in a form of user stories or very rough wireframes. They refine or even completely redesign each feature several times, getting meaningful feedback and acting upon it after each change.

Such an approach yields substantial benefits:

  • ability to release an MVP (minimum viable product) and to start generating revenue and getting real end user feedback as early as possible
  • more focused, more usable interface, not cluttered with “dead” features and unnecessary “bells and whistles”
  • features based on actual end users’ needs, not on guesses
  • very cost-effective development; correcting conceptual and design errors and eliminating unnecessary features happens early, when it’s still cheap.
  • ability to cancel or pivot the project without big losses

The correct process is iterative AND incremental

Of course, there is no such a thing as purely iterative development. To be able to effectively iterate – to get frequent feedback and continuously refine the product – you must work in small increments.

Incremental and iterative don’t have to be opposites. Think of them as a pyramid with incremental as a base and iterative at the top.

To be able to iterate, you must master the incremental process first. However, it’s only a first step, not the goal. Your customers are interested in your product, not your process. If you build a wrong thing, they couldn’t care less how effectively you built it.

Start with mastering the basics, but don’t get stuck in the middle of the pyramid!

At what level your current team is? Do you have any ideas how to help your team climb up the incremental/iterative pyramid? Please share below in the comments!


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s