Agile’s “Definition of Done” can’t save you

I recently read this post, which alleges that rubbing more “Definition of Done” on agile will make the process look and feel years younger.

https://medium.com/@emilesilvis/definitions-of-done-should-be-as-visible-as-your-product-backlog-4d9d6c2b4b9c

And rather than bury my response in a reply, I’m going to give a discussion about my thoughts on this concept and why, unfortunately, it’s irredeemable in all but the simplest situations. I will discuss the semantically almost equivalent but very different “Acceptance Criteria”, and I will offer a replacement for the former that is at least more effective.

The good news first: all the things in your definition of done are habits that would appear with practice and reinforcement. Like anything else, an ethos that encourages and has time for code red-teaming (this is the only useful kind of code review) will produce more tests. Actually rejecting features that otherwise seem to work, but technically violate the definition of done will properly incent everyone to do the right thing.

Atlassian helpfully notes: “The difficulty often lies in having the development team actually respect the contract”. Are they the only ones not respecting the contract?

The bad news: It might be apparent, but I’m somehow not going to end this with a platitude like “work smarter not harder”. Organizations broadly do not want, know what to do with, care about, often even tolerate adherence to “Definition of Done”. Since it’s a post-value item (you already put 1% of users on this last week right?), the organization is just as happy, probably happier without some whining babies talking about “architecture” and “code smell”. Product owners say “the board wants this ASAP” or “joebob told the reporter we’d have this up at press time”. Of course “Definition of Done” isn’t respected. The rigid agile process to which it belongs isn’t being adhered to either. Nothing will make people add mundane tasks under pressure if they have strong incentives not to do them.

About “Acceptance Criteria”: “Acceptance Criteria” specify what visible changes happen when the change is released. Specified in user-visible terms, they have a better chance of being the actual thing organizations use to evaluate whether software is done, since it’s a bit of a rubber meets the road moment in theory. Most organizations write something specific down on the card, but use “nobody called to complain” as their actual acceptance criteria. This isn’t the worst acceptance criteria except that it strikes after the software is released. In most organizations, this is the internal “Definition of Done” and “Acceptance Criteria” that everyone is actually working toward.

Substituting “Definition of Done” and some tooling might allow Product Owners to fully specify a “Acceptance Critiera” that serve the role of “Definition of Done” and that gives end users a relatively bug-free experience. Incentives to do acceptance criteria might exist if the counter incentives to do everything faster weren’t inevitably stronger, but Product Owners are also usually drowning in meetings. This problem is transitive with “Definition of Done”; delegating it back to the team can’t have an effect without moving one other part.

A Hobbesian approach to “Definition of Done”:

Since the forces at work to disrupt definition of done are primarily team-external in my view, only incentives can act upon them. Only the executives in the company or business unit where improvement is desired can firmly set the rules without being overruled. The change to have a more consistent process rather than one that bends more easily to demands, can only come from the top.

I believe that the correct incentive paints the executive and the team as frenemies. They need to work together, but they are adversaries in this game. The adversarial nature of this relationship means that the executive has something to lose by pushing for a faster outcome. This is kind of only tongue in cheek, but it demonstrates the incentives at work at the organizational level, and perhaps why this problem can’t only be solved at the level of “Agile (TM)”.

Rule 0: A product team that has 0 or fewer dollars collapses and everyone is fired.
Rule 1: A product team may deliver anything it likes at any time it likes when a request is on the table. All requests come with a definite expiration date.
Rule 2: Payments are literally transferred from the executive to the custody of the product team when they or their team find that the “Acceptance Criteria” have been met, which can include an inspection of the team’s “Definition of Done” checks, and their outcome.
Rule 3: If the executive’s team finds a unique bug, they may claw back some percentage of the original payment, even if that would leave a deficit after completing the project.
Rule 4: If the product team reveals a bug, they receive a bonus as some percentage of the original payment, even if that would go far beyond the original price.
Rule 5: The executive may use or disband any team it wants. It may provide incentives to its own team using any criteria.

So if the board wants a feature tomorrow, a team can work with that 😈. If the company is willing to wait, how much “Done” do we do? As much as is profitable in real dollars, so we can be confident the executive won’t claw back easily.

I’ll conclude by saying that the incentives in most organizations are totally wrong for any kind of “Definition of Done” to succeed, because the desire to get software faster is always much higher, and held by people farther up the food chain. Don’t blame your engineers for cutting corners if you’re always asking “do we really need this corner?” Sometimes, more rarely than most people think, there is value in delivering crap. Most often, the incentives don’t even require people to ask the question.