Sunday, June 08, 2008

Iterative and Incremental redefined redux

The agile community has written much about this in the past year or so:
Apologies in advance for being a "stick in the mud" on this one - I'm not particularly happy with the definitions so far. I searched around some more on the WWW and came across one I like a lot that I think better meets our needs.

It is from the paper What is Iterative Development? (part 1), by Ian Spence and Kurt Bittner,
Iterative and Incremental Development:
A style of development that involves the iterative application of a set of activities to evaluate a set of assertions, resolve a set of risks, accomplish a set of development objectives, and incrementally produce and refine an effective solution:
  • It is iterative in that it involves the successive refinement of the understanding of the problem, the solution's definition, and the solution's implementation by the repetitive application of the core development activities.2

  • It is incremental in that each pass through the iterative cycle grows the understanding of the problem and the capability offered by the solution.

  • Several or more applications of the iterative cycle are sequentially arranged to compose a project.
Sadly, development can be iterative without being incremental. For example, the activities can be applied over and over again in an iterative fashion without growing the understanding of the problem or the extent of the solution, in effect leaving the project where it was before the iteration started.

It can also be incremental without being truly iterative. For example, the development of a large solution can be broken up into a number of increments without the repetitive application of the core development activities.

To be truly effective the development must be both iterative and incremental. The need for iterative and incremental development arises out of the need to predictably deliver results in an uncertain world. Since we cannot wish the uncertainty away, we need a technique to master it. Iterative and incremental development provides us with a technique that enables us to master this uncertainty, or at least to systematically bring it sufficiently under control to achieve our desired results.

I like that this definition separated iterative from incremental and then defines them together. I would summarize it as follows (but I like the above better, even if it is longer):
Iterative development is the cyclical process of repeating a set of development activities to progressively elaborate and refine a complete solution. The “unit” of iterative development is an “iteration”, which represents one complete cycle through the set of activities.

Incremental development
is the process of developing and integrating the parts of a system in multiple stages, where each stage implements a working, executable subset of the final system. The “unit” of incremental development is an “increment”, which represents the executable subset of the system resulting from a particular stage

Iterative and Incremental development
therefore ...
the application of an iterative development lifecycle to successively develop and refine working, executable subsets (increments) of a solution that evolves incrementally (from iteration to iteration) into the final product.
  • Each iteration successively elaborates and refines the understanding of the problem, and of the solution's definition & implementation by learning and adapting to feedback from the previous iterations of the core development lifecycle (analysis, design, implementation & test).
  • Each increment successively elaborates and refines the capability offered by the solution in the form of tangible working results that can be demonstrated to stakeholders for evaluation.
An Agile Iteration is a planned, time-boxed interval (typically measured in weeks) whose output is a working result that can be demonstrated to stakeholders:

  • Agile Iterations focus the whole team on collaborating and communicating effectively for the purpose of rapidly delivering incremental value to stakeholders in a predictable fashion.
  • After each iteration, the resulting feedback and data can be examined, and project scope & priorities can be re-evaluated to adapt the project's overall performance and optimize its return-on-investment
So in addition to the non-agile-specific definitions above, we see that Agile iterations are adaptive, in that they use the previous results and feedback to learn, adjust and recalibrate for the next iteration. And Agile increments are tangible, in that they can be executed and made accessible to stakeholders for demonstration and evaluation.

That's my story and I'm sticking to it!


Jurgen Appelo said...

Hi Brad,

You might be interested to know that I also researched the differences on iterations and increments, and turned it into an essay. It has been published in Methods and Tools recently:

We Increment to Adapt, We Iterate to Improve

Brad Appleton said...

Hi Jurgen! Congrats on getting the essay published in Methods and Tools. I remember you giving me an "early peek" of a draft a month or so ago.

The thing that dissatisfies me about definitions of the above based on intent (e.g., to "learn & adapt" vs. to "improve & refine") is that such intent does little to identify the distinguishing characteristics that should be observable. I think that not only can the intent just as well be different and still be iterative/incremental, but more importantly, the intent can be as described and the lifecycle might end up being neither iterative nor incremental.

I guess it comes down to the fact that I'm still a "patterns guy" at heart, and believe the definition of iterative & incremental needs to identify both"a process and a thing" (structure). Describing the intent just doesn't do that for me. It describes one reason for possibly many, and which may not be distinctive or differentiating.

I also totally do NOT buy into any of the definitions of iteration as REWORK. I think it is only rework if you already did the work once and come back and redo what you already did. If you simply add to what you already did before, and did it in a strictly additive manner, that's not rework at all! That is just plain WORK, which was "deferred" until more/better information was available.

Kevlin Henney said...

I have another article about the distinction here:,289142,sid92_gci1284193,00.html

Most discussions of iterative development assume that it is just equivalent to iterative refinement and do not emphasise the cyclic nature of an iteration. The clue is in the word, but it is worth being explicit about distinguishing from other forms of refinement, e.g., phased refinement, and to emphasise the implication of a rhythmic process as opposed to other kinds of timing.

Brad Appleton said...

Hi Kevlin! Thanks for the URL to your article. I like it a LOT (wish I had seen it when I first blogged the above).