Describe the Importance of Done Meaning Usable
I'm wanting to level up my coaching on the subject of the Definition of Done. I'm currently coaching a team that wants to expand Done to mean "In Production." The 2020 Scrum guide is less clear to me than the 2017 version which used the phrase "potentially releasable" to represent an increment.
Here's how I understand the arguments supporting the proposition: Done should mean potentially releasable and should NOT mean "in production" or "released for general use."
Flexibility is Valuable
Done should mean usable increment is technically releasable. This allows the business to decide when that increment would best be delivered to users. This is valuable due to the increased flexibility of loosely coupling technical completion and strategic release.
More Dependencies is More Worser
Concomitantly, tightly coupling Done to being released would introduce an external dependency into a Scrum team's backlog items i.e. dependency on the business to choose to release a given backlog item as part of a given increment. This of course may not occur or may not occur often yet would follow directly as a structural dependency.
Definition of Quality Measure Congruent with Common Usage
Another direct consequence of this tight coupling would seem to be expanding the definition of "quality measures" to include "being deployed" which doesn't seem to me to be a measure of quality. I cannot think of a product that is thought of as "high quality" because it has been released.
Your Turn
Is it important that Done mean "could be released to users" as opposed to "already released to users?" Why?
Once an Increment is Done, the imperative is to make it available for use, and to obtain empirical feedback. The business do not therefore "choose" to make a release. The Developers may reasonably make this decision, since they are accountable for determining whether or not an Increment is Done and in a usable state.
The Product Owner can stop a release from happening, if for some reason it is inappropriate to do so for business reasons.
"Release" does not necessarily mean putting an Increment into production, even though it must be of that quality, with no work remaining to reach that standard. The important thing is to put it into an environment which is empirically fit for purpose, and which thereby allows the validated learning loop to be closed.
Instead of a universal idea of what Done means, it's important to define it for your specific context. Even if you narrow down the scope of the conversation to software development, there's a wide range of what is possible for a team to achieve.
At one point, I was a software engineer working on embedded software for a complex electro-mechanical system that was used on aircraft. Components - mechanical pieces, electrical pieces, software - had to be designed, built, and tested. Then, the modified components had to be integrated onto a very expensive, very rare system. Then the updated system had to be tested in a lab setting, followed by flight testing. And only then could existing systems be modified to use that configuration or new units using that configuration be built and fielded. Even if we considered "released to users" to mean "released to the team that does lab testing", the fact that the final verification needed to be done on a real system meant that work wouldn't be done often. Instead, we considered "done" to mean passing as much testing as possible using simulators and emulators, and we invested a lot of time in software tests and building out ways to simulate hardware devices. The intention was that software defects found in the lab should be rare, and defects found in flight testing and in the field should be even more rare.
The idea of "done" meaning "released to users" may work very well in some lines of business software. But even careful consideration of who users are, and broadening consideration to some downstream stakeholder group, could make it very difficult to get work to a Done state. Getting the work to a state where it could be released to some downstream user and go through the next steps in the process may be the best that some teams can do. The important thing is to not only maintain, but enhance, the quality of your product by enhancing your Definition of Done and the tools used to assert it.