1. Developer regression testing, better yet TDD.
2. Active stakeholder participation.
3. Regular delivery of working software.
4. Self-organization.

I had special interest Scott’s criteria because I’d just posted my own attempt to the CITCON mailing list the week before. I wasn’t trying to put together a magic recipe but rather to come up with a list of practices without which — or their equivalents — you will fail. My list was:

• Iterations
• Planning game
• TDD
• Automated acceptance tests
• Continuous integration
• Retrospectives

I think these two lists are pretty compatible, but there are two outliers: self-organization and retrospectives. I was surprised that Scott didn’t have retrospectives on his list. I’m naturally a lumper not a splitter, so I’m tempted to say that retrospectives are a vehicle for self-organization and call it a day. But I don’t think that’s honoring what Scott had in mind. By self-organization Scott meant the team should be organizing the work, deciding who does what. But is that really needed to be Agile? I can imagine using all the practices listed but having a manager assign the work for each story. I can imagine it… but it isn’t something I’ve ever done. I don’t remember having the need, though this may be selective memory on my part. Certainly the majority of the time who should do what is obvious to everyone, and when there are multiple people who could do the work then it is divided easily enough. So I’m not sure that self-organization is a requirement but I clearly believe it is better. Better to have people sign-up themselves and have feel a greater ownership in the project.

So is this it, do we have our list? If you’re not doing these you’re in trouble?

Even better, at least for general inspiration, Kaner’s slides included a reference on using checklists in intensive care units, described in this New Yorker article The Checklist. This is a fantastic article and you should go read it now. Go ahead, I’ll wait.

Back? Excellent, wasn’t it?

Ok, for the cheaters who didn’t read the article here’s one example:

In December, 2006, the Keystone Initiative published its findings in a landmark article 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.

(More in the fine article, which really is worth reading.)

What I found so exciting about that article is it is such a strong evidence that simple simple change in practice can yield wildly improved results, and in an area that is every bit as complex and demanding as creating software.

To me this is insight of a piece with what I felt this summer when I read The Mundanity of Excellence, an article by Daniel Chambliss. Chambliss studied the difference in performance among swimmers to explain why some excelled and others did not. He found that it didn’t come down to any of the things you might expect: unusual personalities, qualitative differences (doing the same things but faster) or talent. Instead “excellence requires qualitative differentiation“, of doing things different things. But not exceptionally different things, just habitually different:

… there is no secret; there is only the doing of all those little things, each one done correctly, time and again, until excellence in every detail becomes a firmly ingrained habit, an ordinary part of one’s everyday life.

I love this message! It doesn’t take magic, it doesn’t take a miracle. It takes decision and discipline and will and learning something new and putting it into practice. This is why I love agile coaching, and teaching engineers TDD and refactoring, and product managers how to use cases and personas, and all those other simple practices that are now considered part of the agile/lean toolkit.

And why it is thrilling to come across an article like this one in the New Yorker that offer a new analogy: the B-17 phase.

Substantially more complex than previous aircraft, the new plane required the pilot to attend to the four engines, a retractable landing gear, new wing flaps, electric trim tabs that needed adjustment to maintain control at different airspeeds, and constant-speed propellers whose pitch had to be regulated with hydraulic controls, among other features. … The Boeing model was deemed, as a newspaper put it, “too much airplane for one man to fly.” … Medicine today has entered its B-17 phase. … I.C.U. life support has become too much medicine for one person to fly.

Airplanes haven’t become more complex since them. Instead the belief of what is needed to pilot them has moved beyond the heroic “Right Stuff” to a sort routine mundane excellence. ICUs are doing the same. I’m ready to join them.