- Iterative vs Incremental - from the first (and original) Wiki Web
- The Neglected Practice of Iteratation - by Jeff Patton
- Difference between Iterative and Incremental Development - nice visual depiction
- No Waterfall Trap -- an even better visual depiction of the difference between iterative and incremental
- Alistair Cockburn (pronounced "Coh-burn") has written several papers on the subject:
- Using Both Incremental and Iterative Development -- Crosstalk, May 2008
- Iterative and Incremental Development: How & Why you should be doing BOTH -- Better Software, April 2008
- Incremental means adding, Iterative means reworking -- Jan 2008 (I dont care for this definition, but the article has lots of good references/resources)
- Iterative and Incremental Development: A Brief History -- by Craig Larman and Victor Basili, IEEE Computer, June 2003
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:
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 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.
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 is 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.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:
- 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.
- 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
That's my story and I'm sticking to it!
4 comments:
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
http://www.methodsandtools.com/mt/download.php?summer08
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.
I have another article about the distinction here:
http://searchsoftwarequality.techtarget.com/news/article/0,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.
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).
Post a Comment