The Power of Checklists

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?