Don't Define Done

If you have been working at a company of any moderate size, you have probably found yourself involved in heated debates about the “Definition of Done.” This is a very serious symptom of a bigger underlying problem! The moment a topic like this emerges, you must act quickly with decisive action! Read further and I will tell you what must be done to avoid permanent productivity damage.

If you haven’t heard anything about the “Definition of Done”, consider yourself lucky. Definition of Done is part of SCRUM, which is a terrible abuse of Agile Software Development. The concept itself sounds rather harmless, but is an insidious and wasteful trojan horse. The definition of definition of done (heh!) is: The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint’s velocity.

The real issue is that the problem is not one of definitions. It’s a problem of the project being mis-managed. The only reason a discussion about the definition of done will ever come up is one of these reasons:

1. A stakeholder is unhappy with a deliverable
2. A creator is unhappy with moving goalposts
3. Someone with no stake in the project is making busy work

At its core “Done” is trivial. It’s always trivial. If the project requests a task such as “Create a product landscape report and deliver it by email on Friday”, then it’s trivial to determine whether the task is finished. Either a new report has been created and delivered by email, or it hasn’t. It’s that simple.

If there is a tension about a deliverable, there are two possible root causes: Either the requirements for the deliverable are underspecified (the stakeholder is to blame), or the delivery does not meet specification (the creator has not delivered).

1. Task Requirements Are Underspecified

People aren’t mind-readers. For a task specified by Person A to be satisfactorily completed by Person B, there must be clear communication about the work to be performed. Any good task definition should have no ambiguity of success criteria. If the task meets the criteria set forth upon assignment, then it should be accepted. A good stakeholder will use his current deliverables to inform his future task definitions, as needed by the creators he works with.

A good stakeholder knows that there is an enormous difference between “Buy Milk”, and “Buy 2 Gallons of Whole Milk”. A good stakeholder will also evolve standard documentation that expresses the common context which applies to all tasks (what payment methods will be used, which venders may be used for purchasing groceries, where groceries will be delivered, how reimbursement will happen…etc).

If a stakeholder is unhappy with a task deliverable, then he must provide better requirements for future tasks.

2. Delivery Does Not Meet Specification

If a deliverable does not meet specifications, there are very simple recourses:

• Train the creator
• Fire the creator
• Assign specific tasks to specific creators

If the creator is willing to improve quality and meet the criteria, then training is a good option. It requires some investment and nurturing, but can pay off dividends to a project’s success.

If the creator is acting in bad faith, and is more interested in cutting corners than delivering good work, don’t work with them anymore. There are lots of genuinely incredible creators out there, who would be happy to work on the project. Find ones who believe in craftsmanship.

If a creator is specialized at a certain type of work, then assign them to project tasks that match their niche. Don’t have artists writing complex software code. Don’t make your musicians do level design. Don’t force your algorithm experts to design user interfaces. A well-specified task won’t benefit you if you aren’t assigning them to the right creators.

If deliveries are not meeting specification, improve your creator pool through nurture, appropriate assignment, and selecting the right creators.

3. Someone Unrelated to the Project Wants a Document

If there is a complaint about a deliverable from someone who is not a stakeholder in the project, or who is only incidentally concerned about the project (like an analyst/consultant/reporter) and has no stake in its business value or success, the solution is trivial. Only people with skin in the game should be working on projects! The product owner cares about his project being delivered. The creators care to be paid for their project deliverables. Someone who is not a creator or a product owner is tangential to the process, and has their own separate agenda.

Purge the Parasites! Find the simplest and most business-effective way to get them off the project! Their interest is divorced from the project’s interest, and so they offer negative value to the project. The health of the project depends on its primary goals!

What To Do Instead of Defining Done?

If you need to define “Done”, your project is about to head down a wasteful rabbithole of bureaucracy, instead of delivering value. Don’t define it! Instead, you need to evolve your project process so that no definition is needed by doing one or more of the following:

1. Provide Better Requirements
2. Improve Your Creator Pool
3. Purge The Parasites

Maximize your value by becoming extremely good at all three of those skills, and your projects will be unstoppable! You will be delivering project after project while your competitors are stuck in meetings with fruitless discussions about trying to divine whether trivial tasks are done or not.