Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at Iterative vs. Incremental Development
What is iterative and what is incremental development? Even the experts are confusing themselves when describing it. Perhaps our language is an inadequate reflection of reality.
Jeff Patton thinks software should be built the way an artist works. The artist "iterates" on the whole thing and the potential of the whole picture is visible in every iteration from the initial sketch to the final painting. The complete work comes gradually into focus. Patton calls this "iterative" development.
However, this is exactly what Mills and Brooks call "incremental" development. They advocate growing software like a plant. This is a similar metaphor to the way an artist's sketch "grows."
Harlan Mills of IBM first published this concept in “Debugging Techniques in Large Systems” Prentice Hall, 1971. (Any software system should be grown by incremental development.)
Fred Brooks popularized the concept in “No Silver Bullet: Essence and Accidents of Software Engineering” first published in IEEE Computer, April 1987 with the final version published in the anniversary edition of “The Mythical Man Month.”
So Patton has the right idea, but his use of the term iterative development is wrong. Incremental development is iterating on the whole thing (each iteration is a minimal useable feature set that is potentially shippable).
Patton slams the common practice of building one feature completely in an iteration, then a second feature in a subsequent iteration. He calls this incremental development (wrong!). He is out of step with the terminology used by computer scientists over many decades.
Key to the Mills/Brooks concept of incremental development is the idea that every iteration is usable in some way (potentially shippable software). The first Scrum shipped all increments at the end of each iteration and they were used by internal consultants “in anger” to execute on revenue generating customer projects. It was only “potentially shippable” because the Product Owner (Don Roedner) was not ready to release it to the general market.
Patton is not clear on what we meant by potentially shippable software which is that every iteration is useable. “Potentially shippable” was first described by Ken Schwaber in his OOPSLA 1995 paper on Scrum after observing the first Scrum team. This first paper on Scrum is republished in “The Scrum Papers.” Perhaps Ken and I could have been clearer on what “potential shippable software” means.
So Scrum is both interative and incremental development when done properly. Each iteration delivers a fully functional increment, just as a plant works at every stage of growth. If it does this every iteration is “potentially shippable" and in the ideal case is shipped to a set of end users who use it to get real work done and provide feedback.
posted by Jeff Sutherland @ 1:51 PM
10 Comments:
This is a wonderful post highlighting the differences between two approaches. Thanks for putting light on this topic.
I think there is a real simple distinction to make between the two.
Iterative is about time while incremental is about the product your are developing.
Every increment adds something to the product, while every iteration is a specified amount of time in which incrementals are being done.
If you think about these terms in this way, it becomes very easy to map the definitions right.
Hi,
I fear I am now even more confused. :(
I have the suspicion, that there are more than two concepts involved, which are named "iterative"/"iteration" and "incremental"/"increment".
When you say "The first Scrum shipped all increments at the end of each iteration" this indicates to me, that an iteration is either something larger so that it can subsume increments, or something based on a completly different basis.
When reading your whole blogpost, I can only guess, that in your opinion, an iteration just describes that you are working in a time-boxed fashion. Hence iterative development only says, that for a fixed period of time, you are working on a fixed set of things. The underlying principle of iterative development is time.
When I understood you right, the underlying principle of incremental development is functionality. An increment is a small amount of functionality, by which software is grown, so that it adds new value to the customer and is potentially shippable.
Now, when I compare that distinction (time - interative / functionality - incremental) to what Patton writes, I get the impression that Patton is saying that there are different ways to gradually grow software. You can either grow it one brick at a time, never touching a finished brick again (what he calls incrementally). Or you can start with the whole system/painting with low details, and refactor it completly with every step (what he calls iterative), adding more detail.
I would argue, that in reality you need both of what Patton describes (i.e. your painting varies in details over the canvas, and you also overpaint certain areas later), but in terms of using iterative and incremental, I suspect that he used the same terms to make a completly different distinction.
To summarize:
Mills/Brooks/Sutherland: incremental - functionality vs. iterative - time
Patton: incremental - brick by brick vs. iterative - add more details.
Andreas
As I understand it, "iterative" reflects on HOW you work, whic is repeating your work process (and reflecting on how to improve upon it between iterations), while "increments" is what you actually deliver. Every iteration you deliver one or more increments to one or more functional areas.
Iterative development is more than just timeboxed development, it is a full process cycle - in Scrum, you have Planning at the start and Review and Retrospective at the end. Each day you have a Daily Scrum, each little piece of functionality is designed, coded, tested, reviewed, deployed.
Incremental product development go hand-in-hand with any iterative development method, but incremental does not describe the method, it describes the product improvements delivered, and some are delivered in each iteration.
I think Ådne Brunborg comments are perfect.
I agree with many of the points here except for those mischaracterizing what I said, wrote, or think. I would encourage readers to please read through the essay Jeff references, forgiving the huge number of gramatical errors, and form your own opinions about what I think. With all due respect, I don't think Mr. Sutherland has.
I _do not_ think that software developement should work like art iterating over the entire piece. Nor do I describe two different styles of development with two different names. Rather I worked hard to deccribe two different concepts we all should understand. And, I clearly stated we commonly use both iterstive and incremental strategies in agile development.
Hoping that Jeff's post leads to meaningful discussion on the topic.
Jeff Patton
A groups of Agile leaders are converging on the definition of iterative and incremental. The two concepts really need to go together. The discussion now seems to resolve around what potentially shippable means.
I want every increment to be shippable and at PatientKeeper every product was in a shippable state at the end of every sprint and was deployed in production at multiple large hospital sites. That is the ideal. It is hard to achieve and even PatientKeeper has fallen off the wagon since I left. Sigh ...
It was true that certain features might not be turned on for production use but they were in the code and demoable at the production site.
The requirement for the first Scrum team was slightly less rigid in that we deployed only to internal production at the end of each sprint. It is true that some features would be in larval form but the larva was visible.
It sounds like Ken Schwaber wants a less rigorous potentially shippable (in deference to all the ScrumBut out there?)
I think I'm in radical agreement with Jeff Patton here:
Iterating "the whole thing" is an overstatement and not what I believe. I believe we should work to identify a smallest releasable slice of a product that demonstrates an end-to-end useful product, then iteratively refine that; building as much as possible in a first time-box with the intent of validating that we're building the right thing. The story mapping approach I teach and use arranges stories left to right in a value stream, then top to bottom by necessity. The top "slice" gives me the whole value stream, and only the necessities. This is the first part to begin working on. I do prefer to think of it holistically and build as much of it as working software as possible - although it may not yet be refined enough to be shippable to outside customers. (On story mapping: http://www.agileproductdesign.com/blog/the_new_backlog.html)
A groups of Agile leaders are converging on the definition of iterative and incremental. The two concepts really need to go together. The discussion now seems to resolve around what potentially shippable means.
I want every increment to be shippable and at PatientKeeper every product was in a shippable state at the end of every sprint and was deployed in production at multiple large hospital sites. That is the ideal. It is hard to achieve and even PatientKeeper has fallen off the wagon since I left. Sigh ...
It was true that certain features might not be turned on for production use but they were in the code and demoable at the production site.
The requirement for the first Scrum team was slightly less rigid in that we deployed only to internal production at the end of each sprint. It is true that some features would be in larval form but the larva was visible.
It sounds like Ken Schwaber wants a less rigorous potentially shippable (in deference to all the ScrumBut out there?)
I think I'm in radical agreement with Jeff Patton here:
Iterating "the whole thing" is an overstatement and not what I believe. I believe we should work to identify a smallest releasable slice of a product that demonstrates an end-to-end useful product, then iteratively refine that; building as much as possible in a first time-box with the intent of validating that we're building the right thing. The story mapping approach I teach and use arranges stories left to right in a value stream, then top to bottom by necessity. The top "slice" gives me the whole value stream, and only the necessities. This is the first part to begin working on. I do prefer to think of it holistically and build as much of it as working software as possible - although it may not yet be refined enough to be shippable to outside customers. (On story mapping: http://www.agileproductdesign.com/blog/the_new_backlog.html)
I'm sorry to see Jeff Sutherland misunderstanding both Jeff Patton and the prior literature on the subject. I've been researching and publishing on this very question since 1991, most recent (most readable?) is at http://jeffsutherland.com/2010/01/iterative-vs-incremental-development.html (short URL http://ac.cockburn.us/1936 ).
Jeff is not saying you have to iterate on /everything/ to be iterative, but "iterative" implies reworking in it's very nature.
Similarly you don't have to add /everything/ to be incremental, but "incremental" implies adding stuff in it's very nature.
Most good teams do both. The trouble comes when you do one but not the other.
Jeff's alarm call is that too many would-be-agile people increment without planning to iterate. I agree with this alarm call.
However, in the meantime, please everyone stop exaggerating the terms and the positions. You all know as I do that success and the interesting bits lie along the multi-dimensional gradients.
cheers - Alistair
Incremental is usually used to denote something more as in - "There was an incremental benefit in the process" or "We had an increment in the pay".
However iterative is used to denote repetition of activity as in - "The calculation was iteratively done". Let us try with an example.
A sculptor chipping away till he feels the sculpt is right is repetitive but we normally do not claim his action to be iterative. There is an element of feedback to verify the first set of activity by an external means . The sculptor also reviews his work with an internal image he has in his mind. Hence the element of external standard.
In a development process there is classical process of Edit, Compile, Link and Go. In the newer IDEs these steps are blurred. Now this process - ECLG - if I may call it is iterative to finally develop a 'potentially shippable product' . I would call it an appreciable improvement in the eyes of the end user of the product. So Incremental in additional functionality or benefit for the end user and Iterative in the process to achieve that incremental benefit.
I suppose what Ådne Brunborg said summarises...
Post a Comment
<< Home