In the dialog about my recent blog entry about the Definition of Done, I was able to refine my mental model about “Done”. Here is a write-up of it.

First of all please notice that my initial write-up contains very vague terms:

• Done is Implemented using TDD, Tested via ATDD and Explored using Exploratory Testing
• Implemented using TDD is Red – Green – Refactor
• Tested via ATDD is Discuss – Develop – Deliver
• Explored using Exploratory Testing is Discover – Decide – Act

Therefore it’s not a definition. In general there is no such thing as an abstracted Definition of what “Done” means to every team on the planet. Today I had a conversation with Michael Bolton on this.

Michael Bolton
I saw your blog post from the other night.
You’ve done one thing very well: you’ve noted that “done” means different things to different people.
There is one way (and, I believe, ONLY one way generally) to answer that question.
That is to ask “WHAT, /IN THIS CONTEXT/ DO WE COLLECTIVELY THINK IT MEANS TO BE DONE, AND HAVE WE ACHIEVED THAT?”

First of all, if you haven’t noticed, “Done” is context-sensitive of course. My general definition of “Done” (If your customer or product owner is not willing to pay money for the user story implemented, it’s not “Done”.) holds here, still, and Kent Beck pointed out to me that he defines “Done” as

requires no further investment to get the return I anticipated

which is an abstraction of my simple definition formulated positively.

Michael Bolton
But there’s a worse problem lurking. “We’re done because we’re done X” is an inductive decision. “We’re done because all the acceptance tests pass” leaves out the question of “Should we have more acceptance tests?”

Markus Gärtner
I see a problem there. You may define “in this context it means that it means to be done, when we finished implementing crap-code, that is of no use at all, giving it to our customer untested and unchecked”. This is where the context is well-defined, but there is a problem with the audience and the purpose of the work you just did – and things go astray for the teams

In that case, I would argue that someone has incompletely considered the context–and maybe we have. /But that’s not an algorithmic decision./
There may be something closer for “are we presently happy with that?”, but it’s still a heuristic decision.
Read this: http://freakonomics.blogs.nytimes.com/2007/08/09/freakonomics-quorum-the-economics-of-street-charity/#more-1726. Look at Nassim Taleb’s answer.
People want to know what the future is going to be like. “How will we know when we’re done?” The point is that it’s foolish, in my view, to collect ideas about done-ness Right Now, and then freeze those ideas. It presumes that you won’t learn anything along the way, that you won’t identify new risks, that nothing will come along to change your mind. The decision to defer the decision until we have the information in hand seems harder, but it’s in fact much easier. At the time you need to make a decision, you’re not looking for a Yes answer to “Are we done?” You’re looking for a NO answer to the question, “Is there anything that leads us to believe that we’re NOT done?”

hmmm, my mind just made a transportation
do you remember the third big obstacle to innovation in becoming a technical leader?

No.
But please tell me! :)

Single-Solution belief: the number three obstacle
it’s the believe that modern psychology gives you answer to everything, while in fact it does not.

But, seriously, you’re /absolutely/ right about that.
Those people who want a single defintion of “done”, to me, are the /antithesis/ of Agile.

the believe that there is one and only one definition of done is of course wrong
there never will be, that is why there is the need for weaker definitions of it to guide an informed heuristic about what done could feel, so you know when you have reached it.

People who have a single definition of anything are the opposite of Agile, to me.
RIGHT!
The word “feel” is very important here.

hmmm, Tom Poppendieck’s picture of problem solving fits perfectly in there
it was a discussion on monday
you identify where you want to be, so, how it feels like being there
then you explore where you’re at
between these two is the problem you need to solve
you get there by walking a bit, exploring where you’re know, did it help, and informing your next step

Yes.

Therefore “Done” is more of a heuristic than a law. Considering that all heuristics are fallible, you will notice that this might mean, that your team has the wrong definition of “Done” and fail to succeed. It might also turn out that your team has a differing understanding of “Done” and you need to refine it. Bringing in the size/complexity dynamic Jerry Weinberg introduces in Quality Software Management Vol. 1 – Systems Thinking the definition of “Done” can be thought of as a single point in a multi-dimensional spanning space. The actual point of “Done” in this multi-dimensional space may differ from your current understanding of what “Done” means. This is why Agile teams decide to work in iterations, in order to refine their understanding of “Done” in the multi-dimensional space and compare it the actual position of what “Done” means to any stakeholder. If they differ, you got the problem to move from the position where you think you are to the position where you should be. This is problem-solving in the way Tom Poppendieck pointed out to me recently. If you leave too much time between the actual experience of “Done” and your current model, you might have a problem moving quick enough in the multi-dimensional spanning space to satisfy your stakeholder. This is when projects go awry, and this is why “Done” is a heuristic. Initially grasping all the dimensional axis in this space is unlikely to work out. The iterative refinement is actually learning by exploring the world around you, exploratory learning.

So rather than searching for the holy grail of the Definition of “Done”, we should continuously keep on asking: “Are we done, yet?”, and if we can answer this question with “Yes”, we might be actually done; if not, we still need to invest time (and money) to get there.