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? http://enroute.aircanada.com/en/articles/when-do-pilots-use-checklists
2Surgical safety checklists: do they improve outcomes? http://bja.oxfordjournals.org/content/early/2012/05/30/bja.aes175.full
3 Checklists and Callouts: Keep It Simple, Avoid Distraction, Prevent Ineptitude http://aviationweek.com/business-aviation/checklists-and-callouts-keep-it-simple-avoid-distraction-preventineptitude
Recent Comments