Iterations! “Done” does not mean "never to be changed again!"

One of the hardest things to understand in agile software development seems to be the concept of “iterative“ development.

Especially in conjunction with the concepts of done-done and definition of done.

In my experience people – developers and customers alike – tend to be confused by the opposing forces of “embracing change” and getting the current iteration of the product to a “done” state in “production quality.”

Although there are several very good explanations on the web, like the one from Alistair Cockburn, it seems very hard to express the basic concepts concisely.

The default example nowadays seems to circle around the different ways to paint the Mona Lisa, so let's start with that one:

• Incremental:
  • (could be similar to waterfall with milestones)
    • partition the canvas into an arbitrary number of rectangles
    • Start painting at the top left rectangle
  • This approach has the added benefit that you could dispatch a subteam to paint the bottom right rectangle and thus ‘scale’ the project. 1
• Iterative:
  • (closer to the standard approach in agile projects)
    • Do a rough sketch of the whole picture in pencil
    • Get customer feedback on the sketch
    • Erase some lines and areas
    • Get customer feedback on the sketch
    • Do broad fills with colors
    • Get customer feedback on the intermediate
  • In this approach you might even have one iteration where the Mona Lisa was blonde

While this model does a fine job in explaining the difference between iterative and incremental, it does not really address the topics of ‘done’ or shipping.

Partially that is due to the fundamental difference between Software and pictures – it is easy to keep on working on software after shipping, because we ship something that is mechanically created from the stuff we write. (No matter whether it is compiled and linked, compiled and put in a jar, packaged or anything else – we still don't have to let go of the stuff we created to ship to customers). There is a huge difference between paintings and software, so for me this is where the analogy stops.

In painting we get value from the customer feedback. In software products we oftentimes can get much more value from real-world use of the product we’re building. Or to be exact: from using the current state of the product that we are building with real customers.

Now to be able to do this, we have to do both – we have to build an increment of our product that is fully functional. And we have to iterate over parts that we already had ‘done’ the last time around.

Let’s look at a simple example – a sign up dialog.

We might want to offer some high-tech login integration via facebook, google and twitter later on, but since we’re just a tiny startup and haven’t yet gotten around to deciphering all the fine details of the OAuth2.0 protocol, for the time being we only want to enable registration via e-mail for the first launch.

So our first iteration of the login dialog only includes e-mail. But what about the design? Since we already know that we also want Google and others integrated, we could already do a real nice UI-design for all the options, couldn't we?
Well – we could. But we shouldn't. We would have to deal with a whole bunch of decisions about things that we only have vague ideas about. And would have to maintain those decisions for quite a while. One agile way of addressing this in an iterative, incremental way, would be to build an increment that is of production quality and make sure that it is easy to re-iterate over this part easily by employing techniques from good software craftsmanship.

So the first increment would contain a finished part of the product (with all the colors, to stick with the Mona Lisa metaphor) to make it really usable, but we would be willing and take precautions to change it later on (paint it over) to iteratively add new functionality.

So long for now
  Michael Mahlberg

Footnote: Scaling and iterations

Actually this also shows that this kind of work-breakdown and scaling is manageable if the expected result to be is known beforehand. We can now easily(?) put nine illustrators on nine pieces of a gigantic billboard that is to feature the Mona Lisa as long as each illustrator knows which part they are responsible for. But that would not have worked for creating (developing) the Mona Lisa in the first place.

Sprints – Give me a break

An iteration in Scrum is called a sprint ...
Scrum is at least six years older than the agile manifesto ... The Agile manifesto’s principle 8states that “[everybody] should be able to maintain a constant pace indefinitely.”...

How does this compute?

Sprints are related to Scrum

First of all let's re-iterate a well-known fact that often gets overlooked anyway: Scrum is not agile. WHAT? Of course Scrum is an agile Method! But that relationship has a direction. Speaking in terms of set theory what I am getting at is the fact that Scrum is just a Subset of "Agile." Looking at the history of Agile, Scrum is just one of the contributing methodologies that were instrumental in defining "Agile" (via the Agile Manifesto). And in Scrum – if you have read the old book by Schwaber and Beedle – the Idea of the Sprint was "to be able to work un-interrupted towards an agreed upon goal" (paraphrased). With these bounding conditions it makes sense to talk about a sprint, where you look neither left nor right, but focus only on the problem at hand. As long as you are sure that you are able to deliver a “potentially shippable product increment” at the end of the sprint (and not some loosely related artifacts that might be welded together in an upcoming future sprint).
But the metaphor only goes so far – the way I understood it from Ken back in 2005 and try to live it these days – sprinting here mostly refers to the focus on the sprint goal, not to the total exhaustion one would deem acceptable for winning the gold medal at a 100m sprint at the Olympic Games.

Sustainable pace is related to XP

The principle of “sustainable pace” comes – almost verbatim – from eXtreme Programming's definition of this XP "Rule" of set(ting) a sustainable pace. Here the focus actually was on not exhausting ones resources. And no, a resource in this context is not a human being, but a persons mental and physical energy reserves and such – just in the same way a marathon runner uses the phrase “at 35k I just had no resources left.”

All models are wrong - but some are useful!

"Sprint" is a Token, a word that identifies an artifact in the Scrum framework. It happens to be a metaphor as well. Metaphors only translate into different domains so far. As pointed out by the aforementioned quote some models are useful. And to me the Sprint-model is useful with regard to the focus on the next goal, not with regard to the total exhaustion of ones resources.

Your mileage may vary of course, but I think that decomposing the different aspects of the metaphor helps a lot in deciding how to live those aspects in your concrete situation.

So long,
    Michael