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.