Musings on project management: Done, as in Agile DONE

Friday, January 23, 2015

Done, as in Agile DONE

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... definition of done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my DoD as it were has been these three questions:

Is it done when the money or schedule runs out?
Is it done when the sponsor or product manager says it's done?
Is it done when Best Value* has been delivered?
* The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical DoD would be something similar to:

The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
The code was either pair programmed or peer reviewed.
The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
The feature the code implements has been documented in any end-user documentation such as manuals or help systems.

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. In other words his theory is tested in the crucible of a trying to make money or fulfill a mission by writing software. How swell for us who read Cohn!