Monday, June 27, 2022

Why I Don't Use a Definition of Done Anymore


Each business and client is different.  When you join them to help with their business agility, they will have unique pathologies and dysfunctions which interfere with their ability to help their customers.  As a scrum master and agile coach, it is up to you to guide these clients through their journey toward satisfying, sustainable, and sane business outcomes.  This week I want to take some time to discuss how I approach the completion of work in an agile enterprise.  

When agile and scrum were in their infancy, one of the early concepts was called the "definition of done." Often developers and business people say work is complete when it wasn't.  It would lead to conversations like the following: 

Project Manager: Is the defect for the surfer account fixed?

Developer #1: It works on my machine and database, so it is done, but I still have to check it in and deploy it. 

PM: So it is not done.

D1: Well, it is done, but it is not done, done. 

Conversations like the above have caused me no shortage of gray hair and triggered numerous binges on pizza.  So when agile and scrum created the concept of the definition of done, I was an eager convert.  A developer had a checklist to follow.  It was a significant improvement. 

Over time I noticed that the definition of done was necessary for quality development, but it was not sufficient for quality work.  Something was missing: a sense of ownership and craft in work.  For instance, some errors were changes not made to configuration files.  A definition of done does not cover that when it is not in the same environment.  A checklist does not apply in that case.  My experiences showed me the rules do not always apply.  Agile people use the Japanese phrase Shu Ha Ri to describe this.  

At a training session, I heard the phrase from the medical field used to describe how developers should approach work, and it was called "standard of care." Standard of care means that patients can expect certain things when they receive treatment.  Instead of a checklist, it is a form of preventative actions and ideas which guide work.  Doctors, dentists, and physical therapists use this approach.  For instance, all medical professionals take an oath where they promise to "do no harm." It means that a patient cannot be more injured by the care or get sicker.  In other words, you cannot bask someone on the head with a mallet so that the swelling stops the bleeding from a cut.  The expectations can be as simple as clean sheets on the beds and nurses and doctors washing their hands to more severe concerns like making sure they receive the correct medication and blood type if they receive a transfusion.  

From a development perspective, it means using source control for all development, putting together unit tests, and ensuring that everything works in a different environment than the developer's local machine.  It is a conscious decision that when you touch a system, it does not become a problem for someone else.  The implication of this is that you communicate changes to others and make sure you do not do any harm to the overall system.  It is a small step that will help build trust in an organization.  

Now discussions at the office can resemble something like this:

Scrum Master: Did that defect get fixed?

Developer #1 Yeah, and it meets the standard of care.  I even reminded DevOps that a configuration file needs to change.

SM: Thanks.

The goal of a standard of care in development is to improve the quality of the product.  Instead of using a checklist for development, instill values of quality and consideration for others on your team.  We all have work to do; by following a standard of care, we guarantee the work is done correctly and with maximum value to our customers. 

Until next time. 



No comments:

Post a Comment