Over the course of the Agile Testing Days I noticed that the definition of “Done” is troubling for Agile teams. It was not only raised in the Tutorial I took, but also on several key note speeches and there were several presentations that also dealt with it. Personally I was wondering why. During the last three days I thought “Done” simply means that you can make money with it. Sounds like an easy definition, isn’t it? If your customer or product owner is not willing to pay money for the user story implemented, it’s not “Done”. Period.
But today I came up with another, easier definition of “Done”, which was strikingly easy to realize in the end. For the definition let me put together several influences from Elisabeth Hendrickson, Adam Goucher, Kent Beck, and many more to a remarkably easy combination.
Elisabeth Hendrickson told me that “Done” simply means implemented, tested (or checked as Michael Bolton defined it) and explored. Very easy, isn’t it? But there’s more to it. Implemented means it is designed, and written in probably some programming language, right? Does this make sense? Considering my visit at the Software Craftsmanship Conference in February I noticed that it seems to be accepted – at least for the crafts people I met there – that implementation means to do it using Test-Driven Development. There was no discussion and arguing about this, it was simply taken as a fact and it was done in a TDD-style. But, remembering back Kent Beck TDD means Red – Green – Refactor, right? A three part meme, oh another one. Great.
The next term in Elisabeth Hendricksons definition of “Done” is tested (or checked). Considering current approaches to get the customer’s requirements using an Acceptance Test-Driven Development style, I would like to coin tested to mean, that we agreed on examples to implement and these examples serve as acceptance criteria in an executable manner. So, actually tested here means, that the code was able to pass the acceptance tests which were agreed upfront onto and were elaborated maybe by the testers on the project to also contain corner cases, which were missed. On Monday Elisabeth Hendrickson taught me, that ATDD can be thought of as Discuss – Develop – Deliver. Gojko Adzic corrected this over twitter to Describe – Demonstrate – Develop. But what do we have here? I claim that tested (or checked) here refers to ATDD style of development, which is itself again defineable as a tricolon itself. So, wrapping up, we have
- Done is Implemented using TDD, Tested via ATDD and Explored
- Implemented using TDD is Red – Green – Refactor
- Tested via ATDD is Discuss – Develop – Deliver
(Forgive me Gojko, but I find Elisabeth’s definition more intuitive to remember.)
Oh, I got one more. Explored clearly refers to Exploratory Testing. It actually might be a coincidence, but Adam Goucher came up with a definition of Exploratory Testing today in a tricolon manner, too: Discover, Decision, Action. Sounds reasonable to me. During Exploratory Testing we discover information about the product which we previously did not know. Based on the information we decide what to do about this. Michael Bolton uses to ask me here: “Problem or not a problem?” so that I can decide, what to do next. Inform the next test executed about what to do. After that we take the next reasonable action based on the information we just recently found out about our product. To make the terminology more cohesive here, I propose to coin explored to mean Discovery – Decide – Act.
So, to wrap it up, just like we have Practices, Principles and Values in Agile, we learn using a Shu – Ha – Ri fashion (thank you Declan Whelan for saving the Agile Testing Days for me by mentioning it), we can define “Done” in this same manner:
- 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
Hmmm.
How about the Satir Interaction Model?
– Intake
– Meaning
– Significance
– Response
Jerry Weinberg talks about it in terms of testing in Perfect Software and Other Illusions About Testing. I think it could easily apply in terms of deciding done-ness. To me, the most important thing to remember is that any decision about “done” is heuristic.
There’s another thing to look at too, from Sensemaking in Organizations. Sensemaking, says Weick, is based on seven things:
– It’s grounded in identity construction. That is, sensemaking is intertwined with who we are and who we want to be.
– It’s retrospective. That is, something has to have happened before we can try to make sense of it.
– It’s enactive of sensible environments. (Huh?) That is, part of sensemaking’s purpose is designed to create a world in which we can obtain information, and in which we can make sense of that information.
– It’s social. That is, it’s influenced by the ways other people are interacting and making sense themselves.
– It’s ongoing. That is, it doesn’t stop; sensemaking is a continuing, continuous process.
– It’s focused on and by extracted cues. (Huh?) That is, sensemaking is a process of trying to identify and sort out what to pay attention to.
– It’s based on plausibility, rather than accuracy. That is, sensemaking is heuristic.
Now, why all the gobbledegook about sensemaking? When I was a program manager, we wrestled with the question of when it would be okay to ship a product which was, at the time, among the best-selling pieces of software in the world. Our director of development (bright guy, dear friend) said that we were done when we had a reasonable belief that there were no more showstoppers, which he defined like this:
Showstopper (noun): Something that makes more sense to fix than to ship. (My italics.)
This meant that we were constantly trying to dispel uncertainty as much as we could, looking for things that would prevent shipment, and not shipping if we had reason to believe that there might be any. We sometimes argued, with the goal of making sense of an uncertain situation, but we didn’t mind that too much because it always guided us to confront the uncertainty and get rid of it. For us, this was a lot easier than saying “we’re don…no, wait!”
—Michael B.
Thanks for your feedback, Michael, and our great exchange yesterday. I have started to prepare a follow-up on this. Hoping to finish it today.
I have run over the Satir in several places, but wasn’t able to grasp it completely thus far. Weinberg pointed me out to QSM Vol. 3, which I still haven’t read, yet. Project Retrospectives from Kerth, Becoming a Technical Leader from Weinberg and Perfect Software from Weinberg couldn’t introduce it to me, yet.
Declan Whelan presented a nice session about Learning in Teams based on The Fifth Discipline from Peter Senge. The basis for this model is the separation into Personal Mastery, Systems Thinking, Mental Models, Shared Vision and Team Learning. He did a similar presentation at Agile 2009 and put up the slides on slideshare here: http://www.slideshare.net/dwhelan/agile-learning-from-agile-2009 The Definition of Done comes into play in the Shared Vision of teams. If Done is not well understood, it means, that the mental models differ and the team needs to learn how to get a common understanding of it. The remaining thoughts will go into the follow-up. :)