There seem to be two schools of thought on how best to explain iterative and incremental delivery. In the interests of clarity, the “incremental versus iterative” school, represented excellently by Alistair Cockburn, seeks to keep technical definitions separate as far as possible. The “incremental and iterative” school deliberately emphasises the intertwingliness of it all (in fairness both schools I’m not including people who blur the line unthinkingly).
Just for the purposes of this post I’m in the second school. Here’s a cute, mutually recursive definition that describes a healthy delivery process:
Incremental: new goals agreed and achieved with each short iteration, building on previous work
Iterative: seeking to be objectively better with each small increment, learning from previous work
If that’s healthy, what would unhealthy look like?
Ugh – you really do need both! If you’re big on planning, break the big rocks down into smaller rocks, and make sure you leave enough gaps between them in every iteration for learning. If you’re big on flexibility (at the extreme, on-demand scheduling), don’t settle for ad-hoc; step back regularly from your individual work items and agree on which goals you’re (self-)organising around.
Related concepts: refinement and fidelity (see this by Karl Scotland). It’s smart to start with crude solutions that kinda work, then refine them incrementally and iteratively (both at the same time):
Credits: Thanks to everyone who commented on my crude, kinda-working prototype micro posts on Slack, Twitter, LinkedIn (and LinkedIn group), also privately on Facebook. In particular: Steven Mackenzie, Roy Marriott, Karl Scotland, Sean Blezard, Ray Edgar, Graham Berrisford, Rob Ferguson, David Daly, Becky Hartman, and Lowell Lindstrom.