There are 10 ways to get ‘Out’ in cricket:
- Leg Before Wicket
- Run Out
- Hit Wicket
- Timed Out
- Hitting the Ball Twice
- Obstructing the Field
- Handling the Ball
- (and some would say Retired, but it’s not on the official list)
I just tried to remember that list from memory and I failed. I got to seven, then managed to remember the one about hitting the ball twice, then resorted to Google. Ah well, that’s not quite what I was going to talk about, but is an excuse to publish this picture of me and some lifeboat colleagues playing cricket last week. We lost, but we had better shirts.
In my last post I talked about the use of checklists within the complex domain. Read the post to fill in the gap, but in a nutshell I talk through how a good checklist can help offload some of the cognitive burden of complex situations by identifying some elements of good practice or repeating action leaving more head-space for the tough parts.
What I didn’t do in that post was to link my thoughts with the lean/agile world of software development. The most popular checklist I see within engineering communities is the ‘Definition of Done’ (DoD), closely followed by its siblings ‘Definition of Ready’ and ‘Definition of Accepted’ (DoR and DoA, fairly obviously). But I suspect most teams are not getting as much value from them as they could. So, after a quick reminder about what they are, here are some guidelines for you to check your own lists against:
Revision: What is a Do[D,R,A]
Let’s see where we go with this, but I’m going to assume that what I write here will work for all 3 lists…
A DoD is a list of criteria that the item under scrutiny should comply with to allow it to move to the next state in its lifecycle.
I think the concept began as a Scrum thing, where the DoD was the team’s way of making sure that a story being classed as ‘Done’ meant the same to everyone. Basically it’s meant to stop the conversation that goes like “When you say ‘Done’, do you mean ‘Done’ or ‘Done, done?'”.
Kanban board fans often use lists like these as mechanisms to control what items can be pulled into the next column. Entry & Exit criteria, if you will. It’s simple yet powerful, creating a window onto an area that is often rife with assumption and through that window all of the team sees the same landscape. So when items transit from one state to another, there really is a common understanding or exactly what state it is in.
Some Guidelines then, finally.
- How long is your list? Good checklists are precise and concise. The aim of a list like a DOD is to highlight the points that are subject to assumption or are often overlooked, not to spell out every Git command needed to check the code in.
- What’s your pause point? When is the list applied? This may be obvious (when you think you’ve completed a story, for example :)) but I wouldn’t like to assume that’s the case for other lists. Generally speaking there are lists that you read and then do and there are lists where you do and then confirm. I’ll let you guess what Atul Gawande calls them in his first-class book ‘The Checklist Manifesto‘. Our typical DoD is of the former type – it is referred to when we think we’re done and used as confirmation.
- When was it last reviewed? It’s reasonable to expect that what the team need from its DoD will evolve, so it should be reviewed regularly. Perhaps a subject for your next retrospective? Or maybe a review is triggered by a story delivery that goes wrong in some way?
- If I asked a member of your team what’s in it, would they know? The acid test of use.
- Where is it? Transparency is important, so having your team’s artefacts available to all, not just within the team, is a great test.
- How often is it violated? What a -ve word! How often are there exceptions? Is the policy for dealing with exceptions explicit? Do exceptions sometimes result in the item moving state anyway? Maybe that’s a good rigger for a review too
That’ll do for now. I wouldn’t want to make the list too long.