… after a team comes together, but before it begins development in earnest, it must establish standards to which it will work. In particular, team members must agree on the Definition of Done. As with any procedural element, the agreeing is the easy part. Doing it continually is the hard part.

During development, after a few sprints, the pressure begins to increase. At this time, natural tendencies become more dominant, working against team process agreements.

✥       ✥       ✥ 

There is a natural tendency to be sloppy with the Definition of Done. It is all too easy to take work that does not quite meet the Definition of Done criteria and mark it done and ship it, with a promise to finish the last little bits later.

Several forces combine to make it easy to fall into this trap:

• There is always pressure to show progress, and this pressure can encourage individuals and teams to bend the Done rules on occasion.
•  In the heat of the development battle, people may neglect the little final things to complete their work.
• On the other hand, the consensus Definition of Done means that the team recognizes its value.
• Adherence to the Definition of Done requires discipline. Nearly everything that requires discipline are not done unless someone enforces it. Developers are typically (naturally) unwilling to enforce it on themselves. And the Product Owner is not in a good position to enforce it, because it requires a more detailed view and more direct intervention than the Product Owner can provide.
• But when a team begins to slacken its adherence to Done, everyone likely recognizes it, but everyone is afraid to be the one to speak of the elephant in the room. A Wise Fool (Coplien and Harrison) may do it, but not every team has a Wise Fool. This is rooted in the fact that where everyone owns something (in this case the Definition of Done), nobody owns it.

The consequences of not strictly adhering to the Definition of Done can be dire. Whenever work is accepted that does not meet the Definition of Done criteria, it comes with a promise to make it up later. This adds to the technical debt of the product. Soon the project falls into the big lie: saying (and even believing) that you are Done when you really aren't. After several sprints, you can't release without a lot of pain to make up the technical debt you have accumulated. Maybe you can't release at all.

Therefore:

The ScrumMaster ensures that the team follows its Definition of Done by requiring that each member of the team take responsibility for ensuring that their developments meet it.

✥       ✥       ✥ 

There are two aspects to this. The first is that the Definition of Done must be sufficiently concrete that it is clear that it has been reached or not. As the team defines Done, the ScrumMaster makes sure that the definition is concrete, objective, and testable. The ScrumMaster can ask questions such as, “How do we know whether a work item has met this definition?” The ScrumMaster may wish to get the help of experts to help clarify it. In particular, this is an ideal time to Engage Quality Assurance (Coplien and Harrison).

The second aspect is to make sure that development adheres to the Definition of Done. This is the main part of this pattern. Consider the following:

• The ScrumMaster might appeal to the team’s commitment to quality and its Team Pride as ways to encourage the team to meet its own standards.
• Be on the lookout for equivocal answers to status questions that might indicate that a person is following the definition of “Almost Done.” Then probe more deeply.
• Post the Definition of Done prominently on the Scrum board where nobody can miss it. Some ScrumMasters have also printed the Definition of Done on small cards and given them to each team member.
• With the prior agreement of the team, the ScrumMaster can enforce the Definition of Done by requiring that every PBI demonstrate compliance before it can be marked complete. For example, a developer might be required to show all the acceptance tests that have been written (and would have to show sufficient coverage), and demonstrate that the code passes all the tests. 

In rare cases, it’s possible that the team just doesn’t meet its done standards any more, and the ScrumMaster has to proclaim a crisis. In this situation, the likely goal is to recommit the team to adhere to the Definition of Done — see Recommitment Meeting (Coplien and Harrison). This should be done soon, so as to avoid the accumulation of technical debt.

The DoneMaster takes an active role in the initial creation of the Definition of Done. Of course, the DoneMaster does not define Done for the team. The first act of the DoneMaster is likely to ensure that the team does define Done. 

Enforcing the Definition of Done is an activity that is done within the team, but is most effectively done by someone who stands very slightly apart from the team. Thus the ScrumMaster is the ideal role for this responsibility.

In some sense the ScrumMaster is playing the role of the team’s collective conscience.

In disciplined teams, there may be little need for the DoneMaster to be active, as all team members follow the Definition of Done. But the DoneMaster is like a parachute: it's really important to have it, even if you prefer not to have to use it.

Good Housekeeping is a complementary pattern. Both patterns focus on preventing technical debt from entering into the product. While DoneMaster primarily focuses on new development, the DoneMaster may also help the team remember to always have Good Housekeeping.

Related Patterns (summary):

• Definition of Done is used to establish the Done standard
• This pattern is similar to Sheepdog, and is almost an important special case of it.
• Good Housekeeping
• Organizational patterns: Engage Quality Assurance, Wise Fool, Recommitment Meeting

Picture from: United Kingdom Government, https://commons.wikimedia.org/wiki/File:Tasting_the_Christmas_pudding_aboard_HMS_COCHRANE,_November_1940._A1988.jpg (picture in public domain)