A fear often associated with self-organizing teams is the potential loss of focus on quality. Indeed, how does an organization ensure it produces a satisfactory level of quality when that responsibility is distributed among teams rather than centralized? Many organizations solve this issue by crafting and abiding by a Definition Of Done, or DoD for short. A DoD is to product developers (analysts, designers, marketers, software programmers, testers, etc.) what the National Electrical Code (NEC) is to electricians. Unlike the NEC, however, there is usually not an independent association telling an organization what the DoD should contain. Each organization has to figure out craft its own DoD. In this article, we explore the mindset that should be adopted when crafting a DoD.
Before diving in, let’s remember that a Definition of Done is nothing more than a list of feedback loops a team deems necessary to address in its quest for quality. For example, teams that operate in a software product development context could get inspiration from this DoD starter kit.
Realistic or Idealistic?
It can be tricky to establish a Definition of Done while product development processes are still evolving. Should a team adopt a DoD that can be met today, even if it compromises on quality a little, or should it adopt a stricter, more thorough DoD that the current reality prevents it from meeting? I have a strong personal preference for the more stringent DoD, the one that aims for perfection.
Presuppositions
At this point, I must make a couple of assumptions explicit. First, I’m assuming that an organization embarking on a Lean Startup or Agile transformation is an organization motivated to change. Presumably, its leaders are dissatisfied with current results and have the willpower to plow through the inevitable obstacles (see Executive Support article for other willpower manifestations). I am thus assuming commitment. We will see in a minute why this is critical.
Second, the stakeholders must recognize that a cure for the current organizational ailments cannot be found in the mere mechanical adoption of an Agile method, be it Kanban, Scrum, XP, or any other. There must be a realization that the method’s chief promise, especially when it comes to quality, is to highlight the problems from which the organization already suffers. Only a change in mindset will allow the organization to solve those issues, not some Agile “pixie dust.” I am thus also assuming intellectual honesty.
Problem Solving
A committed and candid organization wants to be aware of its biggest issues as soon as possible so that it can get on with the arduous task of solving them. Through the prioritization and resolution of its most significant impediments, the organization knows it will get stronger and better able to meet its goals (see article on Agile transformation motivations). Such an organization would, therefore, craft a DoD based on what it needs, not what it can currently achieve. Put another way, theDoD will be measured against perfection, not benchmarked against current capabilities.
Pragmatism
Before going further, I must define what I meant by perfect quality. I am not talking about a blind aggregation of all techniques known to mankind that could possibly drive quality up no matter the cost. Here, perfection aligns with customer expectations and the organization’s economic context. If a given quality dimension isn’t important to customers, the DoD should relax or omit criteria along that dimension. Often, organizations will describe the quality context in a QA Vision or a Quality Management Strategy.
At first, a perfect DoD may be difficult to meet due to existing impediments. It’s even likely that some elements of the DoD cannot be met at all if frequent releases of valuable increments are to continue. That’s OK. Resolving those impediments is presumably valuable (otherwise they wouldn’t be impediments). That value should be estimated, perhaps with a tool like Cost of Delay, and the resolution of the impediments prioritized against other initiatives. In the interim, unmet “Done” criteria should be treated as explicit, temporary exceptions. It is important that the capability gaps remain visible. Team members have frequently surprised me with creative and elegantly simple solutions. Conversely, if a difficult-to-meet criterion is removed from the DoD, a team will soon forget that this problem remains to be solved. Out of sight, out of mind, and all that jazz
In summary, my recommendation for an organization establishing its Definition of Done is to ignore current impediments, however intractable they might seem, and write its ideal DoD. I believe this promotes a level of transparency and candor that cannot be attained when starting with a merely achievable DoD. In other words, I’m asking that teams channel famed American football coach Vince Lombardi who said: “Perfection is not attainable, but if we chase perfection we can catch excellence.”