Recently, I finished the book “The Checklist Manifesto” by Atul Gawande. It is a great book about how good checklists work and how to create them. This article contains the most important thoughts from the book with examples on how to apply them in the field of software development.

Getting Rid of the Dumb Stuff

The main goal of checklists is to get the dumb stuff out of the way so that the brain can concentrate on the hard stuff.

Dumb stuff are easy but important steps that every professional knows well. However, exactly because of that mundane routine, they could be missed.

The hard stuff is what makes a professional a professional, i.e. knowing the most advanced topics of a trade and being able to perform skilled work. This needs another kind of thinking and a different level of concentration than dumb stuff, which can be executed routinely and without thinking much. Also, hard stuff tends to be more interesting for a skilled master than dump stuff. Hence, he will subconsciously avoid dumb stuff or get rid of it as fast as possible to get to the more interesting parts. This can lead to mistakes in the more mundane areas.

Another way of thinking about this is that in complex situations, professionals need room for adapting their actions to the specific problem. They have to think at a very high level and must not be distracted by dumb stuff.

In software development, there are numerous tasks that match the description “dumb stuff”. Even right at the beginning of implementing a feature, the developer has to remember to assign himself to the chosen task in the task management software and set the status to “in process”. I witnessed countless times that these two simple steps have been forgotten, resulting in two developers working on the same task. I’m guilty of forgetting about it myself. Another more serious situation presents itself when having finished all features and releasing them to production. Depending on the architecture of the project and the level of automation, there are often a number of important manual steps to perform. This could be to check the correctness of the version number and the targeted stage for deployment. In the tense situation at the end of a sprint, those simple things are sometimes overlooked.

Focus on the Big Killers

In surgery, checklists contain simple to follow countermeasures against the three “big killers” infection, bleeding and unsafe anesthesia. Sometimes, although having catastrophic consequences, the easy to implement countermeasures are simply forgotten by the medical personal. They already think about the operation and its unique challenges and don’t have the mundane but necessary steps in mind, if it weren’t for the checklist.

In software development, integrity of production data and availability of the production stage are the most sacred areas. If one is corrupted, the customer will get into problems, and with him the development team. Hence, the big killers when deploying an application could be the health status of the application and the result of executed database scripts.

Use Pause Points

Pause points are an important concept in aviation. Before continuing with the next steps, the pilot and copilot have to stop at predefined pause points to go through a checklist. One example is the preflight checklist. There is a nice video on the execution of checklists when a plane takes off here.

In software development, a pause point could be right before deploying a new version to production. The team could take the time to go through a checklist before changing the production environment. A team could also use a checklist before beginning a sprint to make sure that the backlog is filled, all tasks from the previous sprint have been cleared and other organizational issues are in order.

Use Either Do-Confirm or Read-Do Checklists

According to the book, there are two kinds of checklists.

The do-confirm checklist dictates that the whole procedure is executed without the checklist first. Hence, tasks can be done in parallel by multiple people. After the process is completed, everybody stops and reads the checklist. Every item is read and confirmed after all the items are done.

According to the read-do checklist, the tasks are executed as they are read off from the list. This is comparable to following a recipe.

In software development, do-confirm lists could be used when finishing a story. In fact, they often exist and are called “definition of done”. Read-do checklists could be used to execute delicate procedures in which the correct execution matters, for example when migrating a database from one stage to the other.

Context for Checklists

At the end of “The Checklist Manifesto”, there is a nice checklist for checklist. It includes many of the beforementioned aspects to create a useful checklist. One of them is about the items included in a checklist. For example, each item should represent “a critical safety step and [be] in in great danger of being missed” and should also be “not adequately checked by other mechanisms”.

Developing software consists of countless best practices, procedures and steps to follow. Although there is a huge number of possible checklists to derive from this context, only a fraction of them would benefit developers. Many of them are already implemented, like the definition of ready and definition of done. Additionally, so called runbooks provide a step by step guide for often-repeated procedures like deploying the application and performing a database backup. However, every system is different, and every team is unique. I see the greatest potential benefit for new checklists in the individual context of a specific development project. If the customer has strict rules to follow when accessing his systems and executing some change there, it’s good to have a checklist. If the development team consists mostly of young and inexperienced developers, a checklist for how to perform code reviews might also be useful.

Structure of a Good Checklist

Checklists need to be precise and to the point. The wording should be simple and exact, the familiar language of the profession should be used. Checklists don’t need to explain everything in detail, they only provide reminders of the most important steps. Good checklists only have five to nine items. However, this is highly dependent on the context. If the checklist is for an emergency where decisions have to be made quickly, a short checklist is paramount. If a checklist gets too long, it becomes a distraction from other things. That causes people to shortcut the items on the list. Hence, checklists should only include “killer items”, i.e. crucial but sometimes overlooked steps.

In software development, there isn’t usually a time constraint like when flying a plane with an engine on fire. Hence, the checklists for this environment can have more items.

Testing

According to the book, checklists have to be tested in the real world before entering service.

In software development, where the agile mindset took over most of the development projects, the iterative development of checklists is a good process that is already in place.

TL;DR

The book book “The Checklist Manifesto” by Atul Gawande provides useful insights into what makes a checklist useful and how a good checklist can be created. Include “big killers” in your checklist, create space for thinking about hard stuff by getting rid of dumb stuff and obey the rules of a good structured list.