When Done Actually Means DONE

In presentations I’ve given on agile hardware development, there’s one slide I have that seems to get the point across better than any other as far as how agile development differs from the waterfall-like process a lot of hardware teams follow. I’ve used it a few times before and I find myself counting on it again for my talk at Agile2011 in Salt Lake City.

In prior talks, I’ve built up to this slide with a verbal contrast between waterfall and agile. I talk about waterfall development as a sequential process that culminates with one big bang deliverable. Progress is tracked against a master schedule and based on what pre-defined tasks have been completed. The lessons learned at the end of a project are applied to the next project (i.e. you have a chance to improve once/project). I don’t claim that waterfall is exactly what hardware teams do, but it’s close’ish and the task based planning certainly does widely apply.

The agile model, on the other hand, is an iterative process where each iteration culminates in production ready code equivalent to some subset of the end product, meaning you can quit and release whenever you and your customer want. Progress is measured based on which features are complete at a point in time and lessons from each iteration are applied to the next (i.e. you have a chance to improve several times/project).

These are obvious differences, but the underlying message is never quite apparent until we get to the visual. That’s where people can see that the critical difference is in the definition of DONE.

Let’s say a team following a waterfall model is half done building an XYZ, which to the team means their design documentation is done, the design has been coded and they’ve built some of the verification infrastructure. Lot’s of good stuff there, but because the team has based its progress on predefined tasks they’ve completed as opposed to what they know actually works, half done can be pretty misleading. The documentation they have could be severely out-of-date, the design is probably somewhere between buggy and dead in the water and the verification environment might not even compile yet. Needless to say, the second half of the project is going to take much longer than the first half did!

Contrast that with the the definition of done in the agile model. Here, progress is based on features. When a team says “we’re half done”, they mean it. With little warning, they could release a product with half of the intended functionality. They know it’s done because it’s been tested, it’s been through the back-end, the software has been written and it’s ready to go.

Two different ways to measure progress; two very different meanings for the word DONE. To me, its this visual contrast with the waterfall and a redefinition of what it means to be DONE that helps the value of agile development really stand out.


Q. How do you measure ‘done’? Code that’s written or code that’s production ready?

5 thoughts on “When Done Actually Means DONE

  1. Wonderful slide; it helps get the “mental model” right.

    In the waterfall model there are clearly defined / visualized steps to “done”, while those are somewhat lost in the agile model. I would add dashed vertical lines to the agile model to represent the discrete progress made on the way to “done” — that is, in agile mode there are still discrete chunks, but there are more of them, and they happen much more often.

    I write “done” in quotes because it’s rather elusive… I’m thinking whether our metal perception of “done” also needs adjusting when going agile. Needs some thought…

  2. Would a wavy vertical line better represent agile progress? A simple vertical line implies lock-step progress. While a wavy line does not express the complexity of real interaction, it does imply that different portions can be in different phases and even that total progress can advance when different portions fall back (responding to corrective feedback from other portions).

    Just a thought.

    1. paul, interesting suggestion.

      Incidentally, I’ve used “lock-step” to describe the teamwork required to push that vertical line across the figure. I like the vertical line because it’s an ideal and I want to set the bar high. The wavy line, though, certainly makes sense and could be more likely in practice. As long as the line doesn’t get too wavy (ie. someone is getting too far ahead and/or others are getting left behind) I reckon a team would be in pretty good shape and could be a reasonable way to think about things.

      Others have suggested a line that angles from near the bottom right corner to near the top left (i.e documentation leads, implementation lags). That might happen in practice too, though I don’t like that idea. I think that comes from trying to shoehorn existing practice into agile process where our current ideas on how teams work together hinders their potential.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.