Is Definition of Done No Longer Needed?

A while ago now, there was a discussion about “definition of done” (DoD) with critics and supporters alike commenting on how they saw DoD and the need or lack of it.

The critics seemed to fall into 2 categories: those that believe work isn’t done until its actually deployed to production and those that did not see a need for DoD at all, whereas the supporters generally reiterated the need for DoD and tried to explain its worth (which on twitter in 140 characters can be difficult), the most memorable tweet from these exchanges came from Hadi Hariri suggesting that DoD was akin to “agile mental masturbation”.

So are the critics right? Is definition done not needed?

A Definition of Done

Before we go any further, let me offer a definition for DoD:

“A definition of done is a checklist of “things” that need to have been completed before a item is considered finished.”

Each teams DoD is likely to differ from each other as they should have been created by the team to meet the requirements/constraints they have in their environment allowing them to be happy a piece of work is complete.

The key thing with DoD is that everybody involved in the story/feature understands exactly what it means to be done, so no “oh it's done but I just need to do <y> first” if you say you are done, then you need to have met DoD.

The Arguments Against

Its not done until it's deployed to production.

This is a very powerful statement and goes even further than XP idea of Done, Done where the code is not only written but everything has been completed that is needed to deploy the code, now you cannot say something is done until it is actually in the hands of the users.

I can see where this sentiment comes from but would humbly suggest that it is dependent on the environment you work in. If you have a web based application the complexity and overhead deploying the latest version should be low but not everybody is developing web applications. In one of my presentations on kanban, I was asked about this concept, the dev in question created software that still had to be distributed by CD so he wanted to know was his work only done once the CDs had shipped?

There isn’t a need for a definition of done.

This statement came from people who I know work in highly agile environments that are focused on delivering value to the users, one person said to me “I’ve never seen a definition of done here everybody knows when the work is done”. 

For an agilista, this sounds like nirvana, a team that lives agile to such a degree that they know when the work is done, no need for any checklists or wondering if Sue/Fred/thingy has remembered to do something.

I think this situation is great, but, what happens if change is introduced into the well known process? What happens when a new dev joins the team?

The Argument For

For me, DoD has 2 main benefits:

1. Transparency
2. Communication

If you have a DoD in place, it is completely transparent about what needs to be done for any story/feature before you can say “I’m done”, this is understood by developers, project managers and other stakeholders. It demonstrates the actual amount of work that is required to complete a piece of work and that it is not just writing the code.

The DoD should be on display in a prominent position, it is there for everybody to see. If somebody new joins the team/business, everybody can see what’s needed to mark a story/feature as done it is very visible for the team and it serves as a reminder of what is expected of them or to a business person what is involved in getting the work done.

The Verdict

To my mind, the need for a DoD is essential, it doesn’t matter if you are doing agile or waterfall, it is having the ability not only as a development team but as a business to understand everything that is required to complete a story/feature.

The argument that it's not done unless it's in production is a very powerful one and as I mentioned earlier, if you are in an environment where you are able to do that, I would suggest adding “deployed to production” as an item to your DoD. However, if the environment you work in doesn’t allow this, then I would suggest you should be including a deployment to staging/testing/UAT to ensure that you can deploy the software and does what you expect. For me, this argument doesn’t replace the need for a DoD but I strongly believe you should be thinking about the idea behind it to understand the need to deliver value to the user for the business.

I don’t believe the argument that there isn’t a need for a DoD holds any water, the only downside to having a DoD I can see is if it becomes so prescriptive that development becomes just one of a myriad number of tasks on the list, if that is the case, then perhaps the team has missed the point and needs to re-evaluate what their DoD is for.

So is DoD needed any more? Yes, and IMHO it's a key part of the development process that all teams, agile or otherwise, should be looking to use if they don’t already.

CodeProject