Let’s revisit the definition of done

Just when you think something is such a simple and basic principle, you realize that the basics are often the first to go and the first to be questioned. Let’s revisit the definition of done and dissect this…

If there is a corporate definition of done or it’s at the individual team level, one of the first things I have teams do is go through it point by point. They should be asking themselves, can we meet this criteria? Can we meet it for every work item? Can we meet it within a sprint? Where could there be exceptions?

Usually the answers are yes, but…it’s hard. It’s uncomfortable. It sucks to check every box, for every story, for every sprint. And then come the what-ifs:

“What if QA isn’t totally done?” – Then the story isn’t done.
“What if it’s not deployed off my local machine?” – Not done.
“What if I didn’t unit test it?” – Nope.
“What if it’s not code reviewed?” – No.
“What if it doesn’t meet all the acceptance criteria?” – Too bad.
“What if it will be done the day after the sprint is done?” – Oh HELL no!

So the above probably seem pretty stupid, but they are real questions I have been asked. I’ve also been challenged on how Definition of Done relates to quality. My question back is, “How doesn’t it?” If any of the above items are not DONE (or “Done diddy done DONE”) and our story is marked done and deployed to production, that directly impacts our quality.

One of the biggest hurdles teams seem to face is getting things to “DONE” before a freeze. “Well, we can develop until the last day before freeze and then we will test after the freeze.” And then fix bugs. Sounds like it’s not DONE. “But that’s what freeze is for…” Is it?

Why do we freeze code? To stabilize and improve quality by catching the last things that could be wrong. If stories were done before freeze, we should have caught the initial defects in a test environment and freeze could be about those darn integration and regression ones (yes, that should be part of our DoD, but let’s be real, environments can often prevent this as well as our pseudo-waterfall development). If we plan on fixing easily found bugs from first round testing during the freeze, why freeze in the first place? If we’re planning for exceptions, what’s the point of the freeze? We aren’t stabilizing anything. I’ve seen it go poorly too many times to fix a small defect we break 5 other things when we’re supposed to be frozen. And the cycle perpetuates itself. Tell me again how DoD doesn’t relate to quality?

I did hear an interesting podcast the other day (ok, part of it). It was on Agile for Humans and the GROWS method (added to personal backlog for further investigation). From the small bit I heard, it discussed starting first with environmental and technical practices (e.g. continuous deployment infrastructure, mirrored environments, automated tests). When trying to be agile, these are usually things we aspire toward, but what if we started with them. What would that do to our quality? Personally I aspire toward releases being a non-issue and this has something to do with it – think small batch sizes.

The podcast mentioned that we assume a lot of things when implementing practices and basing them on principles, one being that we have the technical know-how and frameworks already in place. But usually, we don’t. As a [non-technical] coach I can talk to the importance of the technical pieces, but I don’t know how to do it. The org needs to do that. And don’t get me started on how it can take an org years to get environments mirrored and fixed or set up a basic devops agreement. So yes, we advocate for these things, and we tout them, but we aspire toward them instead of breaking those obstacles FIRST. I’m by no means an expert on it, but it’s an interesting concept and I’m going to try to learn more.

For now though, let’s continue to focus on principles and the practices to help enable them, starting with quality. Because if we don’t have quality, what do we have? It starts with an S and end with a “HIT”. And you can bet that will hit our bottom line when our customers get fed up and leave. I don’t care how cool your product/site is, if it’s shit, people will leave and find something else. If it’s not working, everyone will know (think Black Friday outages). It’s not acceptable anymore.