It’s (not) over.
Accomplishments feel good. Ticking something off a to-do list and seeing it
struck out is a feeling of progress. In the huge heap of things that need to be done, seeing one of them disappear may just provide the momentum to tackle the next one. At times you encounter a situation where you badly want to tick something off that list and you’ve completed maybe 80% of it, or even less. Yet that doesn’t prevent you from checking it off for whatever reason - maybe the next item is more exciting, maybe the remaining 20% is someone else’s job. All you need is that thing to get out of your way.
That behaviour has slowly crept into our team Kanban boards. We all have some sort of a “Definition of Done” which is too often created less as a shared understanding of completion, but more a boundary where another person/group/entity takes over to complete the remaining work. These DoDs stop far short of what “done” truly means, which is production. And even then you’re in the stage of the story where you’re getting customer feedback and aren’t quite done until you get that, and even then you might iterate on that feedback to do more. But for the sake of finite state machines, let’s call a half-decent DoD one that takes the ticket/story/whatever to at least production. Anything else is DoFD - Definition of Fake Done.
On the surface the DoFD appears harmless and even a good idea - after all, if deployment is a pain let’s just put the feature in a “UAT environment”, call it done, and move onto the next one while we sort out how to make deployments easier by batching features. This is by far the most common interpretation of a DoD that I’ve seen, and it drives some behaviours that are very detrimental to team and software health.
First, it takes work off the board. A ticket not on the board is work that is not visualized and thus hidden. It is easy to lose sight of all the in-progress work that is marked as complete, which immediately takes developer attention away from the release activities that need to be performed and instead focuses them more on feature work. This separation of concern drives a vicious downward spiral where the more developers aren’t concerned about releasing, the less they care about it. Eventually, it results in the creation of a release process which is separate from the development process, even though sometimes the two activities are performed by the same people, just that the former is done in larger batch sizes that cause inevitable grief.
Second, it takes accountability away and promotes the “my part is done” attitude which is culturally toxic. It defers the often truly difficult part of software development (releasing) to a group other than the people who wrote the software. Rather than the team being invested in figuring out how to release the software to production, they become accustomed to an external entity taking care of this part. This specialization between development and release creates separate accountabilities and is antithetic to the DevOps movement where you’re responsible for what you wrote. In plain sight we have taken a hard step backwards to the days of dedicated release management teams which operate on separate cadences than on which the software is written, resulting in increased lead times, higher defect rates, and longer feedback loops.
Third, it increases cycle/lead time. Getting it working on a non-production environment and calling it done results in new work being pulled in while release activities are in progress simultaneously, resulting in higher WIP which kills cycle time. The root cause of why we pull in more work is usually because of one of two things, or both: utilization and specialization. Specialization introduces a gate as work needs to be done by the next person in the chain while the previous one remains unutilized. Instead of pushing the incomplete work forward, we pull new work which fits the specialization of the unutilized person thus increasing utilization, thus giving us a feeling of productivity. In reality, now we have more WIP and thus higher cycle time. The obsession with utilization is a much larger topic and it may be the singular reason why teams struggle to deliver fast.
Finally, it encourages success theater. Partially done work is one of the biggest wastes in software development and celebrating it creates a system where we talk about activities and outputs, rather than outcomes. Outcomes can only be measured if our work in in the hands of our customers and
FakeDone inherently and silently promotes the idea of delaying that measurement.
Even if there is complexity in release and distribution activities it is invaluable to have those activities mapped out and for work to remain visible in those states without it being marked as complete. It provides information on which to inspect and adapt on, which is the only way we can continuously improve our delivery pipelines. So, in short, if it ain’t in production, it stays on the board.