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. 

The Pragmatic Way is Agile.

Lewis Carol said, “Between the idea and the reality lies the shadow.”  It was a wise observation from the author of “Alice in Wonderland,” particularly for people in the technology business.  Each day developers are taking ideas from others half-formed and transforming them into web pages, mobile applications, and complex data systems which keep the economic world spinning.  The theoretical becomes a reality in my line of work.  

I am working on a professional credential for my profession, and something has occurred to me.  To be a good scrum master or agile coach, you must balance the academic skills of the trade with the real-world challenges of working with people and business.  Not only must a scrum master know things, but they must be able to put those things into practice when the knowledge counts.  It means agile must embrace pragmatism.  

I have written about pragmatism before on this blog.  It is a uniquely American type of philosophy which more concerned about outcomes than deep philosophical processes.  It is also concerned with what people accomplish than how they get to the accomplishments.  For example, when I was between jobs, I substitute taught computer s science at my local high school.  To my surprise, the high school has a daycare center.  I was a little flustered and asked why a high school would have a daycare.  An understanding woman who was dean of students, Flora Betts, explained that it was for teen mothers so their children could receive care while they finished their diplomas.  My apprehension turned into admiration as the school found a way to prevent women from dropping out.  Instead of forcing young mothers to drop out, the school allowed them to complete their education while their children were in a safe and healthy environment.  If a high school can find a way to address a problem like teen motherhood, then the business world can deal with its myriad of complex issues.  

Part of many of the problems I see in business come from people slavishly following processes and ignoring what those processes are supposed to accomplish.  The customer must fill out forms correctly or obtain approval before receiving a product.  It may be the correct approach for accounting, but in the world of customer service, it undermines relationships and sales.  It is why I am a big supporter of pragmatism at work.  For instance, retrospectives should fall on the last day of a sprint, but what if the last day of the sprint falls on a national holiday? 

Many people would move the retrospective forward a day.  Often it is scheduled after the holiday because the entire office wants to get out early before the holiday.  In my coaching practice, I ask the team when it is time to have a retrospective.  We are still having a retrospective, but the pragmatic approach is to let the team decide when to have it.  The team is empowered, and the bent rules are not broken.  The agile world uses a fancy Japanese phrase for this approach, and it is called Shu Ha Ri.  

Development teams should learn the basics of agile, the Shu stage.  Next, they know which rules can be bent or broken in the Ha phase.  Finally, the team comes up with their own more relevant regulations for work, and this is the Ri phase.  After all the learning and growth, they begin the process again.  Mastery never happens because everyone is learning and growing.  It seems like a powerful, pragmatic way to improve an organization.  

So as I continue to study very formal and prescriptive ways to do my job, I am aware that work gets done in the shadow of the idea and the reality.  I need to understand the rules before I know which ones to bend or before I can create new ones.  Remember it the next time someone quotes practices or processes to avoid doing work.  Being pragmatic gets the job done and leads to change in organizations.  

A good Juneteenth and until next time.  

Microsoft Practices the Agile it Preaches.

A successful business leader should spend time reading and understanding the news.  Sadly, the information over the last six years has featured a dour parade of narcissism, neglect, and missed opportunities for progress.  The language coined a term for this phenomenon and it is called "doomscrolling." It is upsetting and discouraging.  The terrible news is endless, and we can not help but gaze into the nihilist sinkhole via our phones and televisions.  It affects me more than I care to admit.  Confronted with the choice of wallowing in despair or attempting to be a positive force for change, I dug up a positive example of people using agile to improve the world.  Today, I want to highlight some good news from the technology world. 

According to the Microsoft support site, three features are being removed from its spreadsheet program excel.  I had never heard of these features until I read the following article from Simon Batt.  It seems like they were equally obscure to other Microsoft users.  The change to our favorite spreadsheet program highlight how much Microsoft has changed over the last twelve years.  When this blog began Microsoft, under CEO Steve Ballmer, had a reputation for being the evil empire of the technology world.  

The Microsoft organization mocked ideas like open-source software, object-oriented development, and cloud services.  Developers who used the company's product felt alienated because our technologies were stuffy and limited compared to other software development tools.  

When Ballmer left Microsoft and Satya Nadella took over, there was a notable shift in the organization.  One of these first duties was to have everyone in the organization use Microsoft Team Foundation server as its source control system.  In a keynote speech, I remember him saying, "I am not going to sell a product to a corporate client that we are unwilling to use ourselves."  Engineers call this "dogfooding" because you are metaphorically consuming the dog food you sell to others.  The quality of the Team Foundation Server software shot through the roof and soon integrated tools like git into its system because it was what developers requested.  The software transformed into a cloud-based system known as Azure DevOps.  Anything like this would have been impossible if Ballmer was still in charge.  

Nadella's leadership engineering style embraces the principles of agile and Lean-SAFe, so Microsoft removing the feature from Excel makes perfect sense.  According to the agile manifesto principles, "Simplicity – the art of maximizing the amount of work not done – is essential."  An engineering team and organization understand that creating tools with endless features is wasteful and prone to defects.  The product team for Excel looked at the software and decided to drop three components.  Thus, the software can concentrate on things desk workers worldwide need.  In lean-agile, they say, "Organize around value." Since these features did not drive value to customers or Microsoft dropped them. 

It is refreshing to read news about business decisions based on agile principles.  As software continues to eat the world, it is nice to see that software companies are practicing what they preach.  The improvement process requires subtraction and simplicity, so it is nice to see companies using it for everyone's advantage.  It is a small sample of good news in a world dominated by doomscrolling.  

Until next time.