Defining Different

The Definition of Done is by far the most commonly omitted and poorly implemented part of Scrum.

The reason for this is clear. Nothing suggests a more radical departure from the way in which people in a traditional organisation work than the Definition of Done does.

Sceptical? Confused? Read on…

Done, not Do

First up, let’s look at the meaning of the language used.

It’s called the “Definition of Done“, not the “Definition of Do“.

In most Non Scrum Worlds, employees are used to being told what to do. And of course, if and when you rise up off the bottom of the corporate hierarchy, you might just start telling other people what to do. In either case, the focus here is on the activity. The effort.

So it shouldn’t really come as a surprise that people might quietly drop the “ne” from Done in their minds. Or simply interpret it as “Have you done this?”

Done Defines a Standard

But our definition of done, the Scrum Definition of Done, does not apply to people.

Instead, it applies to the work produced the output of the team. Not their actions.

And that, entirely changes its meaning. Your output cannot “do” anything until it is finished — and so either our work can be used (and is therefore Done) or it cannot, (and therefore is Not Done).

Disputes around this seemingly simple issue, that is, whether work is done or not, is a big driver behind why we bother Defining Done in the first place (where defining means both writing down and more importantly agreeing _to) _what we all mean by Done.

So we should probably define what is meant by “all”.

A standard defined by the recipients

As people progress towards a better understanding of Scrum, their first port of call is usually “what does it mean to work as a team?”.

The initial rung of this ladder is often to move away from the individually focussed “I am done”, towards the collective “we are done”. Note though that in both cases the emphasisis is still on the completion of tasks.

The focus is directed inwards, towards what we are doing.

And thus The Team might say “Ah yes, we have done the testing!! And because we are a good cross functional team, we forced one of the developers to test for an hour on Friday! Please give us a Scrum Cookie! For they are delicious!”1

To which their ScrumMaster may reply: “But when you did the testing, did you fix the bugs?”

“Ah no…” says The Team, “We did not. But we did ‘Raise a JIRA®’. And we got all our points. Cookie Please!”

The focus is on the people and their actions. Were you busy? Did you do all that was assigned to you?

For Scrum, this is not the correct focus at all.

We are interested in the work that is done not the people who are done with their work.

Many teams simply define what they mean for them to be done. Which is valid if they are building something for themselves, but most of the time that is not the case.

Instead, most, if not all, Scrum Teams are building solutions for other people. Other people who have needs and standards (beyond their “functional requirements”) — other people who live in an ecosystem which also, has needs and standards. Needs which must be met. Standards that must be adhered to.

It is these people, and these people alone, who truly know what it means for something to be done.

Done is a treaty

Done is fundamentally a treaty, an accord. Between the people who will do the work and those who will receive it. It is a matching of requirements (typically non functional) to capability.

It is the middle ground between “This is the standard we need” and “This is the level of quality that we can provide”

Of course, like with any good marriage, if the match is no good, then the ceremony should not proceed.2

Too many DoD’s are however created in isolation, supposedly collaboratively, by just the teams — where the greatest achievement seems to be discovering that each of member has a slightly different skill set, and only wants to “do” certain kinds of work.

This results in a DoD which is not so much agreed to, but rather inflicted on our customers. “This is what we are prepared to do, and no more. We say it’s done. So sayeth Scrum.”

It’s about this time that customers start hating Scrum. And not without reason.

If you’ve not actively involved the recipients of your work3 then you’ve not defined done at all.

Done drives non linearity

Once we accept that Done defines a standard rather than a list of activities. Then we begin to see that it drives non linearity.

For example, if we Define Done as “All changes Integrated and Regression Tests passed” (as opposed to merely performed).4 Then all of a sudden our team is responsible for fixing regressions bugs! In the middle of the Sprint!! Work to do that they had not planned for!!!

Now, in order to Get to Done, our developers have to stop working on what they were doing (lower priority functionality we can presume) and immediately onto regression bug fixing — this is hardly the orderly linear view that guideline driven burndown charts portray!

For once the bugs have been fixed the regression needs to be run again5 and we continue this cycle until the standard of what it means to be done has been met. Regardless of the consequences on our velocity.

Done requires Self Organisation and Close Collaboration

This is not something that can be easily or efficiently orchestrated by a single individual. This is something that best emerges from self organisation. In the close confines of a 14 to 30 day Sprint there is no time to raise documentation, there is only time to talk, scribble and gesticulate. Quickly, concisely and purposefully. Because most importantly, we need to act.

If you’re truly Defining Done, Self Organisation is not an optional nice to have, something your tree hugging LEGO® toting hippy coach promotes for no good reason. It’s essential for your survival. But only if you Defined what it means to be Done.

Done Defies Predictability

And here is where the rubber meets the road. Where the organisation rejects or corrupts the Definition of Done. 6

Done destroys predictability.

And that’s usually not acceptable.

If we are going however to be more precise here, it would perhaps be more accurate to say that Done reveals our current lack of predictability. Something that is often only truly revealed, once we take the entire project into consideration, rather than solely focussing on how our developers spend each minute of their waking hours.

So at first it will seem that this is a very bad idea.

How can we predictably deliver on what we “committed to” in a Sprint if we stop and fix bugs! Let alone mess around with refactoring, documentation and architecture!

Defining Done has simply shown us how true predictability is impossible if we continue to make quality a 2nd (or 3rd) class citizen.

After all, that’s why we’ve got so many bugs in the first place!

Done destroys the appearance of productivity. The illusion. It destroys the ever increasing precious velocity we’ve been desperately mining.7

What value is there in quality software? When you could have points!

Done might show us just what a mess we’re in. The damage that’s been done.8

Done can show us just how long things really take around here. From the End Users perspective. And why.

But only of course, if we’re prepared to listen, instead of casting blame and pointing fingers. Which is of course much easier.

Done is hard..

These days, it’s not really that technically difficult; at least not compared to how problematic all this might be politically and emotionally.

Defining Done makes us face our imperfections.

The gap between how we’d like to see ourselves, and how we really are.

It makes us face the visceral unfairness of inheriting a problem created by somebody else.9. And the fact that this in no way stops making it our problem now.

It shows us clearly that we are not an island, we can’t do it all by ourselves, and that we need other people if we’re ever going to get anything really done. And that makes us feel vulnerable. Out of control. Exposed.

Nothing changes the way in which people work more than the Definition of Done

Done changes everything.

Maybe we should call it The Definition of Different.

  1. Scrum Cookies, made from naturally sweet, pure velocity! The secret to hyper activity! Um, I mean productivity 
  2. And just like marriage, often does anyway. Even when everybody knows this is a bad idea. 
  3. Hopefully not because you don’t know, or care who they are. 
  4. Because nothing we have built is ready to use by our customers until this is true. 
  5. Which is typically less drama if you’ve automated it. 
  6. (If they’d not already done so at the crossroads of Self Organisation) 
  7. There has to be a LOTR reference here. Digging for velocity in the Scrum Mines of Moria. 
  8. Or not, I’m mostly referring to legacy code bases here. 
  9. Whether deliberately or not. Whilst it does happen, the majority of technical debt is not created by malice.