“Done” = “I am proud of it” 2
‘’Done means DONE” is the fundamental assumption of all agile software development methods. Agile does not address the need for re-work or repair orders, assuming it is close to 0.
I believe, Definition of Done (DoD) is one of the greatest challenges for agile teams and one of the most often reasons agile teams fail.
There are multiple checklists available for “Done”, for example here or here. Checklists are great as they formalize the requirements for the coding practices qualities. Yet, it still does not necessarily lead to avoidance of failure.
What we therefore assumed as DoD has been “Done means Shippable”. Well, it does not disambiguate the DoD much. Moreover, in my experience, it does not necessarily lead to the amazing products being developed either.
This said, I would like to change the DoD to “Done means I am Proud of It”.
I believe it would work great for both product owners, scrum masters and team members’ motivation as well as will bring much superior results than quality expectation of “done means shippable”.
We also would need to put a checklist together for coding practices, but it would need to develop this main theme.
What do you think?
There’s an interesting case about planning aspects of “done” items (e.g. user stories in scrum). Let’s have a look on following case:
* we consider item A done at the end of iteration X (as in “i’m proud of it – let’s ship it”),
* after the iteration X we calculate its velocity as a sum of done items’ estimates,
* during later stage we discover some defect about item A, so our opinion about item being done changes (”we aren’t proud anymore”),
* so we should adjust our plan to fix item A in current or further iteration.
The question is if we should change the status of the item A to “not done” and therefore decrease velocity of iteration X (”we thought we have done A, but in fact we haven’t”)? What if the bug is tiny in comparison to the whole amount of work, but it anyway prevents us from “being proud”?
‘Done’ is function of time.
What was ‘Done’ back in July 20, 1969 and was watched by 500 mln people, isn’t really considered persistent.
The same is true with “I’m proud of it”. And that’s ok.
DoD as I see is meant to minimize re-work on the forthcoming sprints, and Feel Proud would do better than Deliverable, in my experience.
Re-work has to be handled via velocity expectations. Provided that sprints are rolling, the velocity of previous sprint (where you have had re-work as well) should indicate what velocity should be planned for the next sprint. The model is self-adjustable.