Agile Done is Not Enough

One of the key features of all agile approaches is to do things in small batches. This comes from agile’s birth in Lean and the Toyota Production System. The idea: progress is best measured when something is done.

What is done? There are many descriptions of done available. For example, here and here.

The definition in short is: the software has been deployed. However, this definition is inadequate because it doesn’t consider the software being used by real users.

At Simply Business we use Build-Measure-Learn from Eric Ries’The Lean Startup which defines an activity of learning, where the definition of done is very different. In Build-Measure-Learn, we only look at the software as done when we have learned what we want to learn from it.

The steps are usually:

• define a hypothesis (experiment)
• build the measures
• deploy (Agile Done definition)
• measure the results
• hypothesis is proven or not (Build-Measure-Learn Done definition)

It is only at the last stage (the validated hypothesis) that the experiment is complete. This is what Eric Ries calls ‘validated learning’.

If you only use Agile, shouldn’t you just use the old definition of done? I would say not.

Then what definition should be used?

I suggest the software is only done when: it is being actively accessed in production by real users.

It is only at that late stage, when the software is being used in anger, that it can be considered battle tested. Only at that point, and not before, is it appropriate to start building additional features on top of it and the software won’t need revisiting.

Let’s briefly recap the differences between Software is Deployed and Software is in Use:

Software is Deployed (typical Agile done)

• passes all tests
• signed off by Product Owner
• on the live system

However, the software:

• could be dark code.
• could be being tested only, and resultant data is not trusted.
• could be running in parallel with legacy code
• not (yet) in use by real users
• value has not (yet) been realised

Software is in Use (improved definition)

• passes all tests
• signed off by Product Owner
• on the live system
• has real users
• results are trusted
• not running in parallel with legacy versions of code
• value is realised

The second variant is a more robust version, guaranteeing that the software is ready to be built upon.

In practice, with Software is Deployed, it is possible that months of stories are deployed as dark code. Yes the tests pass, but if the project is cancelled, zero value will have been achieved. The stories fail the real definition of being done: that value has been achieved.

And a big last step will still be required to gain the value of all the stories: put real users on the new software.

To summarise: beware of stories that are ‘Done’ and not being used by real users. They probably have a hidden productionisation phase left before they are truly done.

Done should mean done.