Even done is never done

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile.
 
So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.
 
The team achieving their “done” definition successfully is one of the critical elements to success in any Agile project – this is just as central to a successful project as the product owner’s activities in selecting the right features to build. Defining “done” for a project is often missed, corrupted or completely inadequate on many Agile projects. We have seen teams get it wrong (such as viewing “done” for a role in the team, rather than the product) and the impact is usually obvious in the quality of the product, Even when you get a “done” statement right, it won’t stay relevant forever.
 
The ability to change and improve is part of why it’s such an effective tool in Agile projects. Going back to some of the points from the Agile manifesto and the “pillars of lean”:
 

  • Individuals and interactions over processes and tools
  • Responding to change over following a plan
  • Respect for people
  • Continuous improvement

 
The end of iteration retrospective helps to reinforce these behaviours and from this we often adjust what we do, or keep doing (and reinforce) the good stuff. Often refinements to “done” get missed from this which can lead to “done” becoming another process and tool that we use to follow a plan, rather than and opportunity to change and improve our product development.
 
The key here is for teams to see their “done” statement as best practice for today only. if best practice isn’t improved at every opportunity it becomes a tradition and the team falls into a checkbox delivery pattern.
 
 

Mike Lowery
No Comments

Post a Comment