larlet-fr-david-cache/cache/37cd715a092a39b7d0bb4284a676671b/index.md

title: Incremental and iterative
url: https://blog.agendashift.com/2018/02/22/incremental-and-iterative/
hash_url: 37cd715a092a39b7d0bb4284a676671b

<p>There seem to be two schools of thought on how best to explain <em>iterative</em> and <em>incremental</em> delivery. In the interests of clarity, the “incremental <em>versus</em> iterative” school, represented excellently by <a href="http://alistair.cockburn.us/Incremental+versus+iterative+development"><strong>Alistair Cockburn</strong></a>, seeks to keep technical definitions separate as far as possible. The “incremental <em>and</em> iterative” school deliberately emphasises the intertwingliness of it all (in fairness both schools I’m not including people who blur the line unthinkingly).</p>
<p>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:</p>
<blockquote><p><strong>Incremental</strong>: new goals agreed and achieved with each short iteration, building on previous work</p>
<p><strong>Iterative</strong>: seeking to be objectively better with each small increment, learning from previous work</p></blockquote>
<p>If that’s healthy, what would unhealthy look like?</p>
<ul>
<li><strong>Incremental only</strong>: big backlog up front (BBUF?), backlog-driven development (the BDD acronym is already taken), no time for learning</li>
<li><strong>Iterative only</strong>: constant tinkering, chasing metrics, busywork, no meaningful alignment on goals</li>
</ul>
<p>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.</p>
<p>Related concepts: <em>refinement</em> and <em>fidelity</em> (see this by <a href="https://availagility.co.uk/2009/12/22/fidelity-the-lost-dimension-of-the-iron-triangle/"><strong>Karl Scotland</strong></a>). It’s smart to start with crude solutions that kinda work, then refine them incrementally and iteratively (both at the same time):</p>
<ul>
<li><strong>Incremental refinement</strong>: make refinements you had the good sense to defer</li>
<li><strong>Iterative refinement</strong>: make refinements based on feedback</li>
</ul>
<p><strong>Credits</strong>: Thanks to everyone who commented on my crude, kinda-working prototype micro posts on <strong><a href="https://www.agendashift.com/slack">Slack</a></strong>, <strong><a href="https://twitter.com/asplake/status/965507482150981632">Twitter</a></strong>, <strong><a href="https://www.linkedin.com/feed/update/urn:li:activity:6371283089888550912">LinkedIn</a> </strong>(and <a href="https://www.agendashift.com/linkedin"><strong>LinkedIn group</strong></a>), 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.</p>