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). There do seem to be some sectors where checklists and development go hand in hand, but why is this not a more general practice? When I 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.
Pilots 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.
The 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 again the bolding is my work).
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. A checklist to ensure proper use of checklists is probably a step too far). 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. 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.
Here’s a nice article about what makes a good checklist. The key point summary:
- make sure the people that are going to use the checklist help create the checklist
- limit the length of the checklist, cover only the critical items
- use the checklist as a tool to support, not replace, judgement and creativity
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 endeavours, 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.
I’m going to close out this article by stealing borrowing from an Aviation Week article that quotes Dr. Gawande.
“….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 I think the message still rings true.
I’d be interested in any feedback about instances where using a checklist has help improve and sustain software development quality.
As always, thanks for dropping by and having a read.
Regards
Paul
@Beaglesays 