Iterating and Incrementing to 'Get What You Need'

In Don't know what I want, but I know how to get it, Jeff Patton described a few ways in which Agile teams and business users miscommunicate, and argued that the agile community needs to be clear about the terms 'iterating', 'incrementing' and 'shippable'.

Jeff started by describing some phrases that highlight the need to better explain the concept of iteration to businesses and software development teams:

• "We know what we want. Can you estimate how long it will take to build?"
• "We need to get these requirements nailed down before we can start development."
• "Customers [don't know] what they want"
• "Customers always [change] their mind"

Jeff then goes on to describe iteration and incrementing as distinct concepts, both of which are used by agile teams to deliver value, although they are often conflated and confused, and the reasons each are used.

Describing incremental development:

By incremental development I mean to incrementally add software a time. Each increment adds more software - sorta like adding bricks to a wall. After lots of increments, you've got a big wall.

• We use incrementing to gradually build up functionality so if development takes longer than we expect, we can release what we've incrementally built so far. ("If" is in italics because I honestly can't remember a project I've been on where development took less time than expected.)
• We release incrementally so that we actually get that business value we're chasing. Because, we don't really get return on investment till people begin to use the software we've built. Until then, the expected business value is just an estimate. And, if you think software development estimation is tough, try estimating return on investment.

Describing iterative development:

By iterative development I mean that we build something, then evaluate whether it'll work for us, then we make changes to it. We building expecting to change it. We never expected it to be right. If it was, it's a happy accident. Because we don't expect it to be right, we often build the least we have to to then validate whether it was the right thing to build.

• We iterate to find the right solution.
• Then given some good candidate solution, we might then iterate to improve a candidate solution.

Where things really fall apart in Agile development is when no one plans to iterate.

He went on to argue that he use of the world 'shippable' further confuses the situation:

For a customer, someone who intends to sell or use the software, shipable means they could actually sell and use the software. This means the minimal number of features all need to be present. The software needs to be useful for it's intended purpose - at least as useful as the old software or paper process it replaces. The software needs look and behave well - have a high quality of fit and finish - particularly if this is commercial software and you've got competitors breathing down your back.

Shippable means done. Completely done and dusted. There's no need to iterate on something done - really shippable done.

Saying "shippable" to people in the customer role means implies they'd better get the requirements right because that's the way Agile development works.

So, in order to help customers understand iteration, he suggested:

We need to explain to those in customer and product owner role that it's important to write user stories that they don't intend to release. To write stories that they intend to evaluate, learn from, improve, or toss out as a failed experiment.

In conversations with my friend Alistair, he proposed writing three story cards instead of just one. The first story card has the actual story on it. The second one is a placeholder for the inevitable changes to the story after we see it. The third for the fine-tuning after we see those changes.

This is an example of planning to iterate. It would relieve a lot of stress from the hand-wringing gun-shy customer worried about getting it right because the story needs to be "shippable."

Images copyleft Jeff Patton.