InfoQ

News

The Power of Checklists

Posted by Kurt Christensen on Dec 22, 2007 02:02 AM

Community
Agile
Topics
Agile Techniques
Tags
Best Practices,
Process Adoption,
Checklists and Guides
In a recent article in the New Yorker, Atul Gawande describes how Dr. Peter Pronovost is decreasing infection rates in hospital intensive care units around the world with a decidedly low-tech device: the checklist. Dr. Pronovost identified those procedures which were most likely to introduce infections, and defined simple checklists for each procedure that, when followed, dramatically reduce the incidence of infection caused by those procedures:
He didn’t attempt to make the checklist cover everything; he designed it to tackle just one problem... Pronovost asked the nurses in his I.C.U. to observe the doctors for a month as they put lines into patients, and record how often they completed each step. In more than a third of patients, they skipped at least one.

The next month, he and his team persuaded the hospital administration to authorize nurses to stop doctors if they saw them skipping a step on the checklist; nurses were also to ask them each day whether any lines ought to be removed, so as not to leave them in longer than necessary. This was revolutionary... if doctors didn’t follow every step on the checklist, the nurses would have backup from the administration to intervene.

Pronovost and his colleagues monitored what happened for a year afterward. The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs.

Seeing success, the I.C.U. teams began to self-organize:

The researchers found that simply having the doctors and nurses in the I.C.U. make their own checklists for what they thought should be done each day improved the consistency of care to the point that, within a few weeks, the average length of patient stay in intensive care dropped by half.

But nurses and doctors are highly trained professionals. So why did simple little checklists make such a difference?

The checklists provided two main benefits, Pronovost observed. First, they helped with memory recall, especially with mundane matters that are easily overlooked in patients undergoing more drastic events... A second effect was to make explicit the minimum, expected steps in complex processes. Pronovost was surprised to discover how often even experienced personnel failed to grasp the importance of certain precautions.
Skeptical readers may note that this was just one hospital. Perhaps there were special circumstances at work? Pronovost tried his checklists at I.C.U.s in hospitals across the state of Michigan, including some of the worst hospitals in Detroit. The results were published as a study in the New England Journal of Medicine:
Within the first three months of the project, the infection rate in Michigan’s I.C.U.s decreased by sixty-six per cent. The typical I.C.U.—including the ones at Sinai-Grace Hospital—cut its quarterly infection rate to zero. Michigan’s infection rates fell so low that its average I.C.U. outperformed ninety per cent of I.C.U.s nationwide. In the Keystone Initiative’s first eighteen months, the hospitals saved an estimated hundred and seventy-five million dollars in costs and more than fifteen hundred lives. The successes have been sustained for almost four years—all because of a stupid little checklist.

But what does any of this have to do with software development? Agile development teams attempt to use just enough process in just enough places to enable the predictable delivery of quality software. And so the question then is whether or not simple checklists like Dr. Pronovost's can be identified and applied to the software development process.

Kent Beck's original twelve practices of Extreme Programming are something of a checklist, but not quite. The idea is to identify short, simple checklists that can be applied to those parts of the process that tend to slip, introducing problems into the team and into the system. For example, when asked what sorts of checklists he uses in his everyday work, Kent had this to say:
I use "stupid little checklists" for refactorings that aren't directly supported by my IDE. For example, to move a field to a component:
  1. modify all code setting the field to also set the field in the component
  2. modify all code accessing the field to access the field from the component
  3. remove the declaration of the field
  4. do whatever further simplification this makes possible
Certainly, simple checklists won't fix the tough organizational problems faced by agile practitioners trying to effect meaningful change. But perhaps the agile community would benefit from an effort to identify and share those checklists which have been shown to add the most value with the least amount of overhead. What "stupid little checklists" do you use in your everyday work?

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

3 comments

Reply

Ooooh, scary! by Deborah Hartmann Posted Dec 22, 2007 8:45 AM
Relevance by Greg Akins Posted Dec 22, 2007 9:06 AM
Re: Relevance by berkay NiQuiL Posted Jun 30, 2008 3:22 PM
  1. Back to top

    Ooooh, scary!

    Dec 22, 2007 8:45 AM by Deborah Hartmann

    > perhaps the agile community would benefit from an effort > to identify and share those checklists which have been > shown to add the most value with the least amount of > overhead Hmmm, at first glance this looks like "prescriptive process" to me. But then, when I heard rumour of a set of "Scrum Checklists," I felt the same way ... until I had a look. It turned out that I liked them enough to publish them on InfoQ :-) I guess, like everything else we do, the key is just enough of a checklist. All of the following instructions look simple enough, yet inexpertly applied could undermine or negate the intent of the list:

    Pronovost's "wash your hands with soap",
    - Having lived through the SARS epidemic, I know that this has a specific meaning in a hospital, different from what I do in the kitchen,

    Beck's "modify all code accessing the field to access the field from the component"
    - Implicit is the assumption that there is an adequate regression testbase to catch an error that would harm the application, and

    The Scrum Checklists' "The Product Owner explains the story behind the Backlog Item
    - There's enough jargon here to suggest this requires some training, not to mention the domain knowledge required to 'explain' adequately. Given human nature, it seems important to leave the expert instructions out of the list - in order to avoid the temptation to offer it to the unitiated, and the potentially disastrous results. The Scrum Checklists include the admonition: "As an experienced Scrum Master, use the Checklists as backup" and the New Yorker author says "Expertise is the mantra of modern medicine." A checklist will never replace expertise (witness the fat methodology binders we've seen discarded in the past decade), but in the hands of a skilled practitioner, I think a checklist can be a really useful tool. But just a tool, not a teacher!








  2. Back to top

    Relevance

    Dec 22, 2007 9:06 AM by Greg Akins

    I see the relevance of the original article applying to some areas besides simply using checklists. First, checklists are helpful because they reduce the likelihood of human error. Take a step beyond checklists and apply automation to practices that are repeatable. The nurses apparently didn't feel comfortable stopping the doctors, until the administration enforced the rule. Ego-less programming and continual review/inspection in necessary. Creating and implementing checklists was a pefect example of inspect and improve in an environment where "obvious" benefits weren't being considered.

  3. Back to top

    Re: Relevance

    Jun 30, 2008 3:22 PM by berkay NiQuiL

Exclusive Content

Rationalizing the Presentation Tier

Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.