It’s On My List – One Piece of the Quality Jigsaw

Checklists reduce the likelihood of you forgetting to do something important and so increase the chances of delivering quality that will delight your customer. That’s a bold opening statement, it sounds more like a conclusion, but read on, please. This begs the question, if my brief opening summary is reasonably correct, why does there seem to be a general lack of checklist use in software production? When I have raised the idea of checklists with colleagues none profess to using them (or using them in any consistent way for any length of time). I recently spoke about checklists at a test meetup, it was apparent that the audience had spent little, if any time, using checklists as a tool. Why is the use of checklists not a more general practice within software development? When I first tried to introduce them in to a test team some years back I could not get the idea to gain traction. I won’t deny that part of that could have me being a poor salesman rather than the idea being a poor one. Never the less none of the testers seemed to intrinsically see them as useful. Checklists make sense to me. There are very few days where I don’t plan what I need to cover in a day. You might call that a daily plan or a “To-Do” list but it is just as easily viewed as a checklist. Checklists provide a level of comfort that the things I should be doing are getting done. I don’t list everything, just the important things, the things that I do need to complete on the day. When I sit in an aircraft I’m really hoping the Captain and First Officer are calling through those checklists. Wheels down landings at appropriate speed really appeal to me (my full list of requirements in this space extend beyond a single aircraft configuration). It was really my interest in aviation that brought checklists to the front of my thinking

1Pilots have checklists for the following: “before start,” “after start,” “before takeoff,” “cruise,” “pre-descent,” “in-range” (about 10 minutes before landing), “after landing,” “parking” and, if the airplane is finished for the day, a “termination” checklist must be completed. Checklists are fundamental to the aviation industry, the most regulated industry I know, because they virtually eliminate mistakes and oversights. In addition to mechanical checklists mounted in the cockpit, we consult plasticized checklist sheets and electronic ones displayed on airplane computer screens, as well as reference checklists for such procedures as de-icing (courtesy of Air Canada, the bolding is mine).

The use of checklists extend beyond aviation. Medicine, in particular surgery and critical care, has also adopted checklists.

2The concept of using a checklist in surgical and anaesthetic practice was energized by publication of the WHO Surgical Safety Checklist in 2008. It was believed that by routinely checking common safety issues, and by better team communication and dynamics, perioperative morbidity and mortality could be improved. The magnitude of improvement demonstrated by the WHO pilot studies was surprising. These initial results have been confirmed by further detailed work demonstrating that surgical checklists, when properly implemented, can make a substantial difference to patient safety (British Journal of Anaesthesia the bolding is mine).

One of the things I really like about scrum is the Definition of Done (DoD). Why so? Because it is a checklist that the team must make each other accountable for. That checklist represents things that must be done in order to say we have value that can be delivered to our client. It removes the “hey did we complete the code reviews on that release?” scenario as the release flies out the door to client land. It covers off the “did we complete the testing we committed to?” panic question after release to a client (this does assume proper use of the DoD). The DoD is a powerful governance item. The team I work with has it’s own DoD defined in key areas of story card movement and each of those stages has key attributes we believe are vital to ensuring consistent quality. It represents things we shouldn’t even have to think about doing. The “dumb things” that you could never forget to do, but somehow, under pressure, or other distractions, you might. The DoD sits on each team members desk and a big copy of it sits blu-tacked to a window in our area. It’s as visible as we can make it to the team and external stakeholders. So what are the qualities of a good checklist? Or maybe a checklist is a checklist is a checklist? Just make something up and go for it. A checklist isn’t just any list of things, if you want it to be effective: · make sure the people that are going to use the checklist help create the checklist · limit the length of the checklist, four to six items, covering only the critical items · use the checklist as a tool to support, not replace, judgement and creativity You should also give some thought to how you want the checklist to be used. Are you expecting the actions to be acknowledged and physically ticked off? Or are you going to introduce this as a means of prompting thinking and action but not expect execution of the action to be checked? There is no right or wrong. The context in which you are using your checklists will guide how they need to be used. Understanding this is quite important. If you cannot engage people with using checklists, the best checklist in the world will not help you improve. A checklist that sits unused is a waste of effort. Spend time making the checklist as simple and useful as possible. As soon as you get a few checklist “wins”, point them out, discuss them and let the checklist “do its own talking”.

If you are interested in learning more about checklists you might like to grab a copy of The Checklist Manifesto: How to Get Things Right by Dr. Atul Gawande. The good Doctor saw value for checklists in a number of endeavors, including software development. There are a few extracts and overviews of this book on the web if you would a bit more detail before handing over a few dollars to a book retailer. To close I’d like to use the following from an Aviation Week article that quotes Dr. Gawande. 3

“….overcoming historic ignorance is less of a challenge in the field than ineptitude, the “instances the knowledge exists, yet we fail to apply it correctly.” While there is bountiful information available to medical professionals and most study for years to master their skills, the new challenge is to assure they “apply the knowledge . . . consistently and correctly. We have accumulated stupendous know-how. We have put it in the hands of some of the most highly trained, highly skilled and hardworking people in our society . . . . Nonetheless, that know-how is often unmanageable. Avoidable failures are common and persistent.” Disciplined use of checklists “provides protection against such failures.”

While the above specifically references medicine, change the reference to software development and the message still rings true.

Constructing a checklist that is useful takes time and thought. It needs to be open to feedback to get just the right “shape”. It needs to contain the right language (if you have a geographically distributed team the checklist that works well in one location may not be so good in another location). Persist with the effort and you’ll find yourself rewarded with a tool that can help you improve and maintain your quality levels.

1 When do pilots use checklists?

2Surgical safety checklists: do they improve outcomes?

3 Checklists and Callouts: Keep It Simple, Avoid Distraction, Prevent Ineptitude


3 thoughts on “It’s On My List – One Piece of the Quality Jigsaw

  1. Hi [I can’t seem to find you name]!

    I like your post, it is a nice reflection on the need to make sure everyone in a team is on the same page and shed light on the fact that there needs to be some sort of verification that everything that is supposed to be done is done. But I wonder, the way that you are describing checklists, to me it almost sounds like a process or a workflow. In my team we have a process for each ticket that arise. For instance, someone creates it, the product lead prioritizes it, and when it is its turn, the ticket is resolved and eventually tested and verified. To me this is what you describe as a checklist, and I think I may label it as a process.



    • Hi Maria,
      thanks for your feedback. Ultimately you can name something anything you want as long as it is clear to those you are working with. I’d tend to disagree with your interpretation but that’s just the way I see it. Part of the process might be to use a checklist, part of your overall workflow might involve points where a checklist is utilised. The checklist however, in my opinion, is neither process nor workflow. It is a means by which critical elements of either are called out to at least make sure they have been considered. In aviation terms I might think of the “workflow” as getting from gate at starting point to gate at destination (you could define this many ways in this context but this keeps it simple). Now, as a pilot, I need to follow a number of processes during that flight. I need to maintain level flight when required, watch the weather, watch out for other aircraft, monitor systems, fuel burn, performance anomalies, warning indicators,taking off and landing, etc. So we are getting near end of flight, I call through the checklist and it is completed, we are ready to land in a properly configured aircraft but landing, the process, has not completed. I have to physically get the aircraft on the ground. The checklist will help me to remember to set flaps at correct angle, get those wheels down, etc but it doesn’t complete the process.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s