The dangers of pretty much done

Shipping products at scale is complicated. Work items frequently change hands often across different teams and levels of an organization. Status updates travel up and down the chain of management via a classic game of telephone presenting a lot of opportunities for miscommunication and misalignment. One particular area of misalignment I see frequently is in communicating just how done a particular work item is.

"Hey our stakeholder was asking about this new feature, is it done yet?"
"I managed to get a lot of work done on it yesterday. It's pretty much done."

There can be a lot of ambiguity hidden just under the surface of even benign conversations. What exactly is the ask here? Is the expectation that the work item be available in a test environment for use? Has the feature been deployed into production? By pretty much done, the engineer implies that the work is not quite complete, but how complete is it? Has it been merged and tested? None of that is made immediately clear.

"Wow, that's impressive," says Rebecca. "We figured it would take at least a day, probably two. Can I look at it now?"

"Well, not quite," says Liz. "I haven't integrated the new code yet."

...

"I don't understand," Rebecca says irritably. "I thought you said you were done!"
"I am," insists Liz. "I finished coding just as you walked in. Here, I'll show you."
"No, no, I don't need to see the code," Rebecca says. "I need to be able to show this to our customers. I need it to be finished. Really finished." ^[1]

Digging deeper into the details reveals the actual state of what is actually in the desired state of completion and what isn't. When this doesn't match everyone else expected state what follows are difficult conversations that involve managing unfulfilled commitments and poorly managed expectations.

I like to walk teams through this concept using a very simple prompt - "What do you mean when you say work is done?".

Often within minutes the room reveals just how different everyone's understanding of what done actually is. This is a result of the different perspectives and lived experiences individuals have on the team.

This is frequently addressed by introducing a Definition of Done (DoD).

When a Product Backlog item or an Increment is described as “Done”, one must understand what ‘Done’ means. Although this may vary significantly for every Scrum Team, members must have a shared understanding of what it means for work to be completed and to ensure transparency. This is the definition of ‘Done’ for the Scrum Team and it is used to assess when work is complete on the product Increment ^[2]

When implemented well it acts as a checklist detailing what needs to be completed in order to move work across a defined finish line. While, it's a great way to introduce some shared understanding, it does have some limitations. For example, new feature work being done may not necessarily carry the same set of completion requirements as a refactoring effort.

When is a technical improvement or refactoring “done”? We certainly don’t want to email our customers about it, and we probably don’t want to add it to the changelog.^[3]

DoD also tends to be scoped to teams and sometimes organizations. This makes cross organization communication an additional challenge especially with teams in a different domain. There's no one-size-fits-all when it comes to describing done.

Done, much like life itself, is a matter of perspective.

- At the individual level, "Done" is when I passed my deliverable to someone else.
- At the team level, "Done" is when the team completes their work and passes their package to the Ops team, or (hopefully deployed automatically).
- At the product level, "Done" is when we get feedback from the customer that finds the product/feature/bug fix valuable.
- And even then, a few months later, what was Done may be completely overturned.^[4]

Recognizing these inherent gaps in communicating just how done something is the first step toward addressing them.

In practice, I've found that having done (and by extension pretty much done) as part of the team's lexicon to be the root of the problem. I consider it the communication equivalent of a code smell. It should always invite more scrutiny and invite more questions than it answers. I've found that even with a well defined DoD, it's something that teams have to address as part of their culture by encouraging more specificity when describing the status of work items.

"Hey our stakeholder was asking about this new feature, is it done yet?"
"I managed to get a lot of work done on it yesterday. It's in code review."

I think it's worth spending a bit of time with your teams to go over what done means to them and establish a DoD process if you don't have one already as well as examine how your team communicates to build some shared understanding of how to communicate some of these ideas accurately and effectively.

1. www.jamesshore.com. (n.d.). James Shore: The Art of Agile Development: “Done Done.” [online] Available at: https://www.jamesshore.com/v2/books/aoad1/done_done [Accessed 28 Mar. 2022].
2. Scrum.org. (n.d.). DONE Understanding Of The Definition Of “Done.” [online] Available at: https://www.scrum.org/resources/blog/done-understanding-definition-done.
3. ‌Smith, D. (2018). The Definition of Done: What does “done” actually mean? [online] Medium. Available at: https://medium.com/@dannysmith/the-definition-of-done-what-does-done-actually-mean-ef1e5520e153 [Accessed 28 Mar. 2022].
4. ‌dzone.com. (n.d.). The Definition of Done, Done-Done and Really Done - DZone Agile. [online] Available at: https://dzone.com/articles/the-definition-of-done-done-done-and-really-done [Accessed 28 Mar. 2022].