Definition of Done — or why it’s not enough to make a list
Tom Dingman is Dean of Freshmen at the Harvard University and in 2011 he had the plan to formulate a set of principles and values that every freshman had to sign. This so-called kindness pledge was then hung up for everyone to see in the university’s floors. This commitment was supposed to encourage the students to vouch for certain values and as a result represent a valuable part of the student body. After all, they avowed to this pledge with their signature and even more important, everybody was able to see that he or she did — one might think this should be enough motivation and encouragement.
A few days later and after heavy protests from all sides the letters were removed — but would they have been successful in the first place? Experiments conducted by Peter Gollwitzer of New York University have shown, that quite the opposite is the case. A public commitment to certain values and the supposed pressure from the outside don’t actually encourage sticking to those values. In fact, publicly committing to something significantly reduces the actual commitment. The explanation is quite straightforward: By signing the pledge, the freshman has already shown he intends to adhere to certain principles and values. There is less need to actually live up to it and no success of an increased morale has been achieved.
Therefore, an intrinsic motivation is obviously more promising, i.e. possible values and principles have to be accepted, lived, and internalized for them to manifest in the daily (work) life. Another success factor is for authorities and respected colleagues to live the values and be a role model for others to follow. This leads to a certain culture and as we all know, culture eats strategy for breakfast, as Peter Drucker once said.
What is the impact on Agile projects? The essential part of the Scrum framework is its values and principles that are described in the Scrum Guide. All artifacts that are created and all activities that are performed by the team are a consequence of those values. A Definition of Done (or short, DoD) is such an artifact leading to an increased transparency — one of the core values of Scrum. A DoD states what is important to the development team and what needs to be done so that a task can actually be marked as completed. A DoD leads to a better understanding among all project participants when a change, such as a feature or a bug fix is done and ready for a delivery to the customer. This means that there can only be open or closed tasks and nothing in between. A DoD also leads to an increased internal product quality by enforcing certain non-functional requirements regarding the software itself or the overall software development process.
So, how come that a Definition of Done is often there but never lived up to? After all, the development team drafted this document by their own standards and is constantly adjusted to their own needs. It contains requirements for the development process, which when combined, form a set of principles and values to deliver a high-quality product increment. I encountered two reasons for that:
Product Owners are partially to blame when they only care for new features and lack the understanding to deliver a sustainable development. They frequently don’t realize the meaning and importance of a DoD and the importance of internal product quality in an Agile environment. They urge the development team to increase the number of features without caring much about the delivered quality. Most of the times it’s not even their fault but the result of project management failures they can’t influence. Ultimately, when those teams do not even have a Scrum Master to make Product Owners and stakeholders aware of the DoD’s importance, it is seen as a necessary evil and not lived up to at all.
The other reason might in fact be the above-mentioned commitment to a set of principles and values. The developers have not actually internalized what they wrote down. They merely thought of things that might be useful to have or might have copied the DoD from other teams or other companies without actually understanding them. In the end, they can always say: “But we have written it down that we test and document our software, it’s right there!” and have thus fulfilled their alleged duty.
Implementing a Definition of Done is therefore only useful when it is lived and the importance of the document as a whole and its parts is understood by all project participants. Sometimes it might be even better to not have a Definition of Done at all — to only increase the team quality without external pressure of a signed document. The DoD would then simply be a summary of the already established culture.
Therefore, I suggest formulating a Definition of Done solely based on the current process and to only extend it in small steps so that new principles can manifest before tackling a new challenge. When the DoD initially consists of too many items, it can often be overwhelming which leads to ignorance. Let’s say the team would like to add acceptance tests to their current development workflow to increase external product quality. Before writing it down, they talk with their Product Owner so that they get the time to include this in the process. After some time, this becomes a new routine and can then be added to the DoD as a part of the development culture. I call this model a Reactive DoD and it might be the solution causing a DoD that is actually valued and not ignored.
German version originally published here: https://agile.cassini.de/blog/detail/definition-of-done-oder-warum-es-nicht-reicht-eine-liste-zu-machen-1.html
