Are You Done Yet?

Johanna Rothman recently wrote, commenting on Joshua Kerievsky’s proposed definition of done. Both posts are worth a read, if for no other reason than to better understand why we have such a difficult time defining what “done” is, and why defining “done” is one of the major challenges for teams  trying to adopt agile practices.

Thinking about both Joshua’s and Johanna’s points I wonder if the difference isn’t similar to a discussion of whether principles or practices are more important to be successful when adopting agile methods. On the one hand following  practices diligently allows you to develop good habits and even to get some good results early on. The challenge comes when it’s time to reflect and improve on your practices. Without a good understanding of practices it’s hard to optimize.

Similarly, defining done earlier in the process can cause problems if you are thinking about the meaning of “done” the wrong way.  If “done” means washing your hands of issues (“we met the spec…”),  evaluating done as late as possible makes sense, enforcing the idea that you are not done until the customer is happy is a useful driver.

If, on the other hand, you understand (and believe) that your goal as a developer is to deliver useful, quality software,  and if the customer understands that that they may not have understood the problem until they had a working system in hand, defining done for earlier steps means that you have more tools with which to evaluate your effectiveness, status, and progress.   Done closer to the developer means that you have more, rather than fewer, chances to evaluate, learn, and improve.  By embracing the principle that delivering a useful end product is the goal, you can benefit from having some local completion criteria.

Having the definition of done closer to the team (as Johanna recommends) allows you to measure progress and identify risk. You also need to be able to acknowledge that it is possible that completing all the stories may still mean that there is still work to do. Then you have to inspect, adjust, and adapt. Which is to say: be agile.