Iterative vs Incremental Development? Is it 'vs' or 'and'?

So do you do iterative or incremental software development?

Be careful - this is a tricky question. Agile Software Development is based on iterative AND incremental (notice AND here) development. The article on the Wikipedia on iterative and incremental development explains the idea behind it - deliverying a shippable software product increment in every iteration. This reflects a well-known traditional change management approach defining a change as a well-defined transition from one stable version of software to another stable version of software product.

As a beginner project manager I lived in a confidence that I actually needed to choose between iterative OR incremental approaches. This is because I used a misleading metaphor for software product development. Let me dig into my past for a second...

I used to keep in mind a metaphor of a painter's dilemma. The painter's dilemma is a choice between iterative OR incremental approaches (notice OR here). Imagine two painters creating portraits. First painter's approach is to start with a sketch of the whole person and iteratively fill-in individual details across the whole person, details evenly distributed across a person. The second's painter approach is to sequentially work on individual parts, like an arm or leg or head till they are fully completed and mastered together with deepest details. The former approach resembles the way browsers display a picture that they download - starting from rough, obscured approximation of a picture and progressing iteratively till n-th approximation becomes a complete picture. The latter approach  is not based on approximations - a painter can switch to next part of the body only when he mastered the part of  a body currently being painted.

Having the painter's dilemma metaphor in mind as a project manager I was often tempted to go for iterative approach. It gives an overview of the whole project starting from the first iteration - it reflects the Top-Down programming paradigm - start with a do-nothing stub implementation of a program / system and dig down gradually into implementing individual areas. Also the iterative approach lets to postpone irreversible decisions till later which follows the Lean software development ideas.

As you can see such approach puts me into an inconvenient position between Agile approach and my conclusions from the painter's dilemma. Or does it? I understood my mistake during one of the projects when it turned out we were not able to close testing of any of a few dozens of features until very late stage of the project.

I suddenly understood that iterative approach is a kind of re-incarnation of waterfall. In fact it is called Agile-fall as I found out where iterations are in place, but they do not produce any business value as Stories are not ready to be delivered till the last iteration. Agile-fall in spite of using iterations delivers all Stories at the end of a project thus inheriting all disadvantages of a waterfall model's Big Bang effect. This completely breaks the Agile approach - to deliver working increments of software product in every iteration.

Clearly with respect to delivering value the incremental approach really shines. It allows a Product Owner to start making money early and have satisfactory Return of Investment (ROI), to stop after k-th iteration, to change requirements for unimplemented features. It is all possible as successive iterations deliver the most valuable increments possible at given moment.

And what about 'iterative' part of Agile's iterative AND incremental foundations? How does it apply? Is it AND at the end? Well, iterations are a tool providing Inspection - the second leg of SCRUM as Ken Schwaber used to call it. Thanks to iterations a Product Owner can assess quality of an increment. And they have nothing to do with increments of functionality evenly distributed across product as in the case of a painter's iterative approximations of a portrait - the value does not necessarily distributes evenly across project's functionality. Thus the approximation-based approach lying at the heart of painter's iterative approach is not a good model for delivering maximal value in an iteration.