03 Do D's Value Why Are They Still Not Satisfied With Your Work

03 The Value of DoD: Why Are They Still Not Satisfied When You’ve Finished Your Work? #

Hello, I’m Zheng Ye.

Before we begin today’s discussion, let’s start with a little story. Xiao Li is a programmer. One day, Project Manager Lao Zhang approached him to discuss the progress of a feature:

Lao Zhang: There is a task that needs to be completed. Take a look. - Xiao Li: This isn’t difficult. I can finish it in two days, and it can be deployed after two days.

Two days later, Lao Zhang came to Xiao Li to review the work:

Lao Zhang: How is it? Is it done? Can it be deployed today? - Xiao Li: I’ve finished my part. - Lao Zhang: Has it been tested by the QA team? - Xiao Li: Not yet. - Lao Zhang: Can it be tested and completed today? - Xiao Li: I don’t know. - Lao Zhang: What? I promised the business team that it would be deployed today!

Clearly, Lao Zhang is somewhat angry, and Xiao Li is feeling a little aggrieved. So Lao Zhang, Xiao Li, and the QA team spent a sleepless night together.

After hearing this story, what are your thoughts? Don’t rush, let’s continue with the rest of the story.

A few more days passed, and Lao Zhang came to find Xiao Li again to assign a very simple feature. In Xiao Li’s opinion, it could be done in one day, and according to the schedule given by Lao Zhang, Xiao Li had two days to work on this feature. Xiao Li felt pleased in his heart: It looks like I can “steal a day of leisure” now.

Two days later, Lao Zhang came to check on the progress.

Lao Zhang: Is this feature developed? - Xiao Li: Yes, I’m done. Let me demonstrate it to you.

Xiao Li adeptly demonstrated this newly developed feature. This time, Lao Zhang was very satisfied:

Lao Zhang: Well done. Did you write unit tests? - Xiao Li: Huh? Do I need to write unit tests too? - Lao Zhang: Why else did I give you two days?

How could this happen? Xiao Li felt very aggrieved. He clearly completed the work well, so is Lao Zhang intentionally causing trouble for him?

Alright, the story is over. Do you feel a bit familiar? Why does Xiao Li work hard, but Lao Zhang always finds faults? Is Lao Zhang deliberately nitpicking? In fact, Lao Zhang is not that free, and Xiao Li’s grievances are mainly due to their different understandings of “completion.” In other words, there is a gap in understanding between them.

Bridging the Gap of Understanding #

In this module, our topic of discussion is “Starting with the End in Mind.” So our first question is, what does “end” actually mean? In the example we just mentioned, “end” means “completion.” However, Xiao Li believes that his work is done, while Lao Zhang believes it is not.

How did this happen? The root cause of the disagreement between the two lies in their different understandings of “completion.”

In the first story, as the project manager, Lao Zhang believes that “completion” should mean “going live,” while the programmer Xiao Li believes that “completion” means “finishing the code for the functionality.” The difference in understanding includes the testing work done by the tester and may also include the deployment work done by the operations team.

In the second story, Lao Zhang gave Xiao Li two days. Xiao Li believes that these two days are only for coding the functionality, while Lao Zhang thinks that Xiao Li should also write the unit tests, and possibly even the functionality tests. The difference here lies in the amount of work required for testing.

Because of the discrepancy in understanding between the two parties, no matter how hard Xiao Li tries, it is impossible for him to meet the requirements of project manager Lao Zhang. This is what’s called “going in the opposite direction.”

So what should they do? Xiao Li might say, “I’m not a mind reader, how can I reach an agreement with him?” The answer is simple. Since there is a difference in understanding between the two parties, bridge that gap, and then the following problems won’t be problems anymore.

There are many ways to bridge this gap, and there is one best practice called DoD (Definition of Done). From the name of this concept, it is not difficult to see that it was created to solve the common “completion” problem in software development.

Definition of Done #

The concept of DoD itself is not complicated. It tells us what it means to be done and aims to minimize various wastes caused by understanding deviations. So how do we do it? The team should define the DoD before starting work. Taking the previous scenario as an example, the team can define:

Feature development is considered complete when developers have gone through requirement clarification, function design, code writing, unit testing, passed acceptance tests by testers, ensured the code is in a deployable state, and completed related documentation.

Development is considered complete when developers have written the functional code, written unit test code, written integration test code, passed the tests, and ensured the code has passed code style checks and test coverage checks.

Everyone is smart, and once the DoD is defined, it is clear who should do what. At this point, if Xiao Li says, “I’m done with development” but has only written the functional code, don’t blame Lao Zhang for being ruthless.

Now that you know what DoD is, it is simple enough to be clear at a glance. I believe you will soon know how to use it in your work. However, we not only need to know how to use it, but also how to make the DoD work better.

  • DoD is a checklist composed of individual check items to check the completion of our work. DoD check items are a series of valuable activities required to develop a product, such as writing code, writing test code, and passing acceptance tests by testers. The understanding of what activities are valuable may vary among different teams. However, if your team believes that only functional code is valuable and nothing else, it may be a signal that your team, as a whole, lacks professionalism. Working in such a team does not have a promising future.

  • DoD check items should be verifiable in practice. You say the code is written, where is the code? You say the test coverage is up to standard, how can we see that? You say the function is done, demonstrate it.

  • DoD is a mechanism for team members to report to each other. Don’t overcomplicate the concept of “reporting.” The simplest form of reporting is saying, “This feature is done.” When we have DoD, there are only two states of work: “done” and “not done”. In team collaboration, we often hear someone say, “This task is 80% done.” Sorry, that means it’s not done at all. There is no such thing as 80% done.

In the previous discussion, we only discussed DoD from a personal level. At the team level, we can also define DoD.

  • DoD for a specific feature, for example: This feature is considered complete, has passed product owner acceptance, and is in a deployable state.
  • DoD for an iteration, for example: All planned features for this iteration have been completed.
  • DoD for a release, for example: The entire software is in a publishable state, and the deployment plan is clear.

Standing on the Shoulders of DoD #

So far, we have only discussed DoD from the perspective of internal collaboration within a software development team. However, in reality, DoD is not limited to internal team collaboration; if you open your mind, you will find that the thinking behind DoD is widely applicable in work. For example, when we need to collaborate with other teams to develop an interface, we all know that the first step is to define the interface.

So, what does it mean for the definition to be complete? Many teams believe that a literal definition is enough. But with the thinking behind DoD, when we define an interface, we will define specific, checkable criteria. So, what is “checkable” when it comes to defining an interface? We can evaluate it by referencing a runnable interface. Just check:

  • Whether the interface provided by the service provider is the same as the return value of this runnable interface;
  • Whether the caller can use this runnable interface effectively.

Whoever is wrong, makes the change. You might ask, which runnable interfaces should we reference? This is not difficult to solve; frameworks for simulating servers are everywhere. If you don’t mind, my Moco is an open-source project that you can take a look at.

Once we establish DoD in collaboration, we can even solidify it through processes, thus working more efficiently and with higher quality. Of course, in our work and life, there will inevitably be some temporary tasks that are not complex enough to require a process, but they can still be efficiently resolved using the thinking behind DoD. For example:

There are often people who come to me asking for help with something. Applying the thinking behind DoD, the first thing I would do is ask them for the specific tasks I need to do and clarify the details (which is equivalent to defining the “checkable criteria”). This way, I know to what extent I can help with this favor.

When I ask someone for help, I also clearly tell them what tasks I need them to do, minimizing unnecessary misunderstandings.

DoD is a mindset, a way to minimize uncertainty and achieve consensus. We approach our work with the mindset of “starting with the end goal,” and DoD allows us to clearly define the “end” right from the beginning.

In the collaboration between people, various problems often arise, and the fundamental reason is that there are too many misunderstandings caused by differences in understanding, which in turn wastes a lot of time. DoD is a way to implement ideas susceptible to ambiguity.

Summary #

Alright, let’s summarize what we have learned today. First, you should know that when people collaborate, there will always be different understandings. Before starting to collaborate, it’s best to synchronize our understandings to ensure that there won’t be any surprises due to inconsistent interpretations.

How can we address these understanding disparities? I introduced the concept of Definition of Done (DoD), which is a best practice in the industry that allows teams to align their understanding of “done.” A good DoD is a checklist that can be used to ensure that nothing is missed.

If you delve into the concept of DoD, you will realize that it can be flexibly applied to different collaborative scenarios. For example, it can be applied to individual work, team work, or even cross-team work. Of course, you can also apply it flexibly to various life scenarios to bridge the gap in understanding between people and facilitate better collaboration and communication.

If there is only one thing you can remember from today’s content, please remember this: define the standards of completion before doing anything.

Finally, I would like you to recall whether you have encountered any issues or unpleasantness due to misunderstanding in your work or life. After learning about the concept of DoD, do you have any new ideas? Feel free to leave your thoughts in the comments section.

Thank you for reading, and if you found this article helpful, please feel free to share it with your friends.