June 19th, 2015 by Adam Sandman
agile software testing project management
A Dangerous Question
“Is it done?” A question with possibly dangerous answers, at least where cooking is concerned. An incorrect “Yes” could mean people are given undercooked meat, whereas “No” might leave people hungry and unhappy.
With software development an incorrect “Yes” could mean customers get low quality, buggy software, whereas “No” might leave managers hungry for staff reassignments or dismissals. Consider the following exchange:
“But surely the answer should be simple! After all, we’ve all been watching the Burndown charts and according to those, we’ve finished.”
“Not so fast. Did we point out that the Burndown chart only reflects the work of the actual development team? After that we give it to other teams so that they can internationalize the product, write release notes, produce an installer and carry out a number of other vital, but non-developmental tasks.”
Manipulating Velocity
It’s also possible that the development team might cheat a little along the way, with the best possible intentions of course. There may be excessive pressure to sustain the team’s velocity in order to maintain planned release dates. So, to finish an iteration on time, the team leaves a few loose ends, knowing that they can be taken care of later. This results in a misrepresentation of how long it will take to make a release, not only because of the outstanding loose ends but also because the measured velocity is wrong. There is even the risk that management may force a release anyway, based on the data showing ‘done’. Further, with multiple teams, if we use the definition of ‘done’ from each individual team, we may be forgetting integration work.
It is better to be honest about a slipping velocity and then try to improve the situation, than to instill a false sense of confidence only to finally miss a ship date. Managers and customers don’t like it when every milestone is hit, except the last one, when the date suddenly and unexpectedly slips 3 months. It smacks of deception, and quite rightly so.
Transparency
Creating transparency is the key. We promote Agile processes as being able to deliver high quality products on time. If customers or managers are told ‘done’ and then it turns out the software is not ready for release, our credibility and the benefits of Agile predictability are lost. Everyone must have a true and honest view of the development status. So, how can we make ‘done’ more meaningful?
One problem is that we are using a normal English word: ‘done’. Consequently everyone thinks they know what it means - no discussion required. We don’t sit and debate the word, ‘software’ so why should we debate ‘done’? But not doing so leads to difficulties, as we have seen. Fortunately, the problem is easily overcome; we’ll call it ‘DoD’ instead, standing for Definition of Done. Now it’s much more apparent that we need to discuss and agree DoD before we start.
The definition must be agreed across the development team and then communicated to management, stakeholders and customers so that expectations are the same across the board. I’m not going to advocate any particular criteria here, getting agreement and transparency are more important than the actual definitions used. But, don’t forget to include criteria to ensure those loose ends are tied up.
DoD Tips
Here are a few tips for creating a DoD:
Don’t spend too long on the definition; as we said: it is the agreement and transparency that are important, not the detail. The definition may not be perfect, but provided everybody still knows what the definition is, it won’t be a huge problem.
Don’t put too many targets into the DoD otherwise it can cripple the agility of the process with too many unnecessary required ‘completion’ activities.
Itemize the DoD so that each part can be more easily inspected and given a ‘pass’ or not.
Remember that ‘done’ may change from increment to increment if the increments have different goals.
Consider more than one ‘done’. For example, a story might have a DoD, as might an iteration or sprint, and the release might also have a DoD. This will reduce the possible ambiguity from just having a single generic DoD.
We have discusses DoD in an Agile context, but the question, “Are you done?” can apply to almost anything, so it’s not a bad idea to have a DoD on waterfall projects, reviews, studies, shopping trips, and almost every other situation in life including, of course, cooking meat.
You may also be interested in: