People talk about agile being iterative, and about it being incremental. Sometimes they use the two words interchangeably. The words do mean different things, and agile is both iterative and incremental, but in different ways.
Iterative is about going round and round. We do something, and then we repeatedly revisit and revise it. Agile is iterative for the product, meaning that we try to create a very rudimentary product and get it out the door, but then continually refine and revise. Each time round the circle we should aim to release the product again. Slowly the product becomes more and more refined.
Incremental is about going up and up—or adding more and more. Agile is incremental for the value we deliver, meaning that the first release of the product delivers a bit of value, the next release delivers a bit more, and so on. At every step we deliver a bit more value—whatever we define “value” as being for this particular project.
The value and the product are different. The product is the thing we make, and the value is the benefit we get from it. By going round and round on the product we get to deliver more and more on the value. Although if we don’t release the product each time our value is limited at best.
So-called waterfall development allowed the product to be built up incrementally, and the result was that there was almost no value until the last piece was put in place.
Agile software development often focuses on being able to iterate on the product. But the reason we iterate on the product is so that we can get incremental value. If a particular project or programme delivered value incrementally without being iterative on the product then I think that would still be a good result—indeed, I would probably still call it an agile project. That’s why I talked before about the importance of getting partial value from partial delivery.
niksilver.com 
I agree. Iterative seeks to deliver value incrementally. But that’s only the ‘sunny scenario’. Reality shows that often iterative deliveries provide feedback that our assumptions are wrong. The faster we find out, the less we wasted. Some call this ‘fail fast’.
In order to prevent wasting time, we better do prespectives rather than retrospectives. In the prespective we imagine the result of the iteration and already can correct before we spent the time.
But ultimately, it is difficult to predict the behaviour of the users, hence we should iteratively ‘deliver to real stakeholders doing real things in real circumstances’ and observe. That’s quite different from the concept of a ‘demo’ we see in Scrum.
Walter Shewhart in the 30’s recognized that the behaviour of physical phenomena can be predicted by laws, based on measurements of known parameters. The parameters determining human behaviour, however, are less known (hence called ‘complex’), causing that behaviour (using our product) to be less predictable.
This observation led to the original Shewhart Cycle (1932), which Deming presented to Japanese management in 1950: Design – Manufacture – Sell – Investigate – Redesign – continue cycling. This later became the Deming Cycle: Plan – Do – Check (or Study) – Act.
This is the basis of iterative delivery.
Good that Agile recognized the value of it.
Actually, Winston Royce, the author of the famous ‘waterfall’ paper (1970), also recognized the need for iterations. The problem was that readers of his paper stopped reading at figure2 (showing a picture that later became called ‘waterfall’). If they would have continued reading his text, they would have read his observation that doing one waterfall (one iteration) does not work. Waterfall in itself is good: first think then do. Iterative delivery is doing many waterfalls in sequence. So the ‘original’ waterfall paper already stated that we should do iterations.
Poor old Winston Royce. I think there’s a lesson in there about how not to present your ideas (which doesn’t speak well of readers).