The release process is complex and beyond one person. Releasing is an intricate dance that we haven’t been sufficiently capturing. Knowledge siloed in heads needs to be committed to public, institutional memory. The upcoming 4.5 release is an opportunity to capture every step of the dance so that we can iterate process, automate away lingering drudgery, and improve our cognitive net for the stressful task of releasing to 25%. I like using checklists in this cognitive net. They relieve anxiety, make process transparent, and help teams flow during stress. We already have a couple release checklists. We can build on those while adopting a little checklist culture in a manner empathetic to developers and flow. Pitch:
Checklist cool tricks
Checklists…
- distribute power.
- push power of decision making to the periphery.
- provide a cognitive net.
- make the minimum necessary steps explicit.
- make sure simple steps are not missed.
- make sure people talk.
- capture and shape real flow.
- inspire flow in emergencies and sustain it through the quotidian.
- capture flow between teams.
- encourage a shared culture around flow.
- accessibly capture institutional memory in the context of flow.
Attributes of a good checklist
What makes a good checklist? Checklist shouldn’t be about just checking boxes. Instead of being a chore and an admonishing finger, checklists should fit and assist real flow. The Checklist Manifesto offers these suggestions. Ideally, checklists…
- are not lengthy.
- have clear, concise objectives.
- define a clear pause point at which the checklist is supposed to be used.
- have fewer than ten items per pause point.
- fit the flow of the work.
- continually update as living documents.
See this checklist for checklists and this example checklist for more.
Stuff to checklist
The major release checklist attempts to use pause points and follow the suggestions above. The major and minor release checklists are pretty rough and incomplete and overlap with each other. These and the things to keep in mind list need love and unification with help from developers who are in the release flow and handling controls on the release train.
about.php is…quite the process. It needs the oxygenating powers of a checklist.
Checklist Feature plugin merges.
Checklist bundled theme releases so stuff like this makes it into institutional memory.
Beta and RC releases.
Plenty of other stuff. 
Start by capturing. As we walk 4.5 release flows, capture.
Selected quotes from The Checklist Manifesto
Checklists supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.
In a complex environment, experts are up against two main difficulties. The first is the fallibility of human memory and attention, especially when it comes to mundane, routine matters that are easily overlooked under the strain of more pressing events.
Faulty memory and distraction are a particular danger in what engineers call all-or-none processes: whether running to the store to buy ingredients for a cake, preparing an airplane for takeoff, or evaluating a sick person in the hospital, if you miss just one key thing, you might as well not have made the effort at all.
Checklists seem to provide protection against such failures. They remind us of the minimum necessary steps and make them explicit. They not only offer the possibility of verification but also instill a kind of discipline of higher performance.
Checklists, he found, established a higher standard of baseline performance.
Four generations after the first aviation checklists went into use, a lesson is emerging: checklists seem able to defend anyone, even the experienced, against failure in many more tasks than we realized. They provide a kind of cognitive net. They catch mental flaws inherent in all of us—flaws of memory and attention and thoroughness. And because they do, they raise wide, unexpected possibilities.
All were amenable, as a result, to what engineers call “forcing functions”: relatively straightforward solutions that force the necessary behavior—solutions like checklists.
We are besieged by simple problems.
And the question of when to follow one’s judgment and when to follow protocol is central to doing the job well—or to doing anything else that is hard.
Pinned to the left-hand wall opposite the construction schedule was another butcher-block-size sheet almost identical in form, except this one, O’Sullivan said, was called a “submittal schedule.” It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another—on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction—who had to share (or “submit”) particular kinds of information before the next steps could proceed.
The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted. So the submittal schedule made them talk.
the major advance in the science of construction over the last few decades has been the perfection of tracking and communication.
They trust instead in one set of checklists to make sure that simple steps are not missed or skipped and in another set to make sure that everyone talks through and resolves all the hard and unexpected problems.
There is a particularly tantalizing aspect to the building industry’s strategy for getting things right in complex situations: it’s that it gives people power. In response to risk, most authorities tend to centralize power and decision making.
The philosophy is that you push the power of decision making out to the periphery and away from the center. You give people the room to adapt, based on their experience and expertise. All you ask is that they talk to one another and take responsibility. That is what works.
In other words, to handle this complex situation, they did not issue instructions. Conditions were too unpredictable and constantly changing. They worked on making sure people talked.
No, the real lesson is that under conditions of true complexity—where the knowledge required exceeds that of any individual and unpredictability reigns—efforts to dictate every step from the center will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either—that is anarchy. Instead, they require a seemingly contradictory mix of freedom and expectation—expectation to coordinate, for example, and also to measure progress toward common goals.
More remarkably, they had learned to codify that understanding into simple checklists. They had made the reliable management of complexity a routine. That routine requires balancing a number of virtues: freedom and discipline, craft and protocol, specialized ability and group collaboration. And for checklists to help achieve that balance, they have to take two almost opposing forms. They supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.
“David Lee Roth had a checklist!” I yelled at the radio.
“following the recipe is essential to making food of consistent quality over time.”
All the examples, I noticed, had a few attributes in common: They involved simple interventions—a vaccine, the removal of a pump handle. The effects were carefully measured. And the interventions proved to have widely transmissible benefits—what business types would term a large ROI (return on investment) or what Archimedes would have called, merely, leverage.
Plain soap was leverage.
The secret, he pointed out to me, was that the soap was more than soap. It was a behavior-change delivery vehicle.
“Global multinational corporations are really focused on having a good consumer experience, which sometimes public health people are not.”
bringing them a gift rather than wagging a finger.
Could a checklist be our soap for surgical care—simple, cheap, effective, and transmissible?
He also did something curious: he designed a little metal tent stenciled with the phrase Cleared for Takeoff and arranged for it to be placed in the surgical instrument kits. The metal tent was six inches long, just long enough to cover a scalpel, and the nurses were asked to set it over the scalpel when laying out the instruments before a case. This served as a reminder to run the checklist before making the incision. Just as important, it also made clear that the surgeon could not start the operation until the nurse gave the okay and removed the tent, a subtle cultural shift. Even a modest checklist had the effect of distributing power.
He explained that his hospital had completed a feasibility trial using a much broader, twenty-one-item surgical checklist. They had tried to design it, he said, to catch a whole span of potential errors in surgical care. Their checklist had staff verbally confirm with one another that antibiotics had been given, that blood was available if required, that critical scans and test results needed for the operation were on hand, that any special instruments required were ready, and so on.
The checklist also included what they called a “team briefing.” The team members were supposed to stop and take a moment simply to talk with one another before proceeding—about how long the surgeon expected the operation to take, how much blood loss everyone should be prepared for, whether the patient had any risks or concerns the team should know about.
But however embarrassing it may be for us to admit, researchers have observed that team members are commonly not all aware of a given patient’s risks, or the problems they need to be ready for, or why the surgeon is doing the operation. In one survey of three hundred staff members as they exited the operating room following a case, one out of eight reported that they were not even sure about where the incision would be until the operation started.
“That’s not my problem” is possibly the worst thing people can think, whether they are starting an operation, taxiing an airplane full of passengers down a runway, or building a thousand-foot-tall skyscraper. But in medicine, we see it all the time. I’ve seen it in my own operating room.
They can each be technical masters at what they do. That’s what we train them to be, and that alone can take years. But the evidence suggests we need them to see their job not just as performing their isolated set of tasks well but also as helping the group get the best possible results. This requires finding a way to ensure that the group lets nothing fall between the cracks and also adapts as a team to whatever problems might arise.
Their insistence that people talk to one another about each case, at least just for a minute before starting, was basically a strategy to foster teamwork—a kind of team huddle, as it were. So was another step that these checklists employed, one that was quite unusual in my experience: surgical staff members were expected to stop and make sure that everyone knew one another’s names.
The investigators at Johns Hopkins and elsewhere had also observed that when nurses were given a chance to say their names and mention concerns at the beginning of a case, they were more likely to note problems and offer solutions. The researchers called it an “activation phenomenon.” Giving people a chance to say something at the start seemed to activate their sense of participation and responsibility and their willingness to speak up.
You must define a clear pause point at which the checklist is supposed to be used (unless the moment is obvious, like when a warning light goes on or an engine fails). You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off—it’s more like a recipe. So for any new checklist created from scratch, you have to pick the type that makes the most sense for the situation.
The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory. Boorman didn’t think one had to be religious on this point.
However much thought we might put in, a checklist has to be tested in the real world, which is inevitably more complicated than expected. First drafts always fall apart, he said, and one needs to study how, make changes, and keep testing until the checklist works consistently.
It is common to misconceive how checklists function in complex lines of work. They are not comprehensive how-to guides, whether for building a skyscraper or getting a plane out of trouble. They are quick and simple tools aimed to buttress the skills of expert professionals.
In aviation, there is a reason the “pilot not flying” starts the checklist, someone pointed out. The “pilot flying” can be distracted by flight tasks and liable to skip a checklist. Moreover, dispersing the responsibility sends the message that everyone—not just the captain—is responsible for the overall well-being of the flight and should have the power to question the process.
An inherent tension exists between brevity and effectiveness.
We surmised that improved communication was the key. Spot surveys of random staff members coming out of surgery after the checklist was in effect did indeed report a significant increase in the level of communication. There was also a notable correlation between teamwork scores and results for patients—the greater the improvement in teamwork, the greater the drop in complications.
Even the most expert among us can gain from searching out the patterns of mistakes and failures and putting a few checks in place. But will we do it?
Just ticking boxes is not the ultimate goal here. Embracing a culture of teamwork and discipline is.
Yet we should also be ready to accept the virtues of regimentation.
“When surgeons make sure to wash their hands or to talk to everyone on the team”—he’d seen the surgery checklist—“they improve their outcomes with no increase in skill. That’s what we are doing when we use the checklist.”
The fear people have about the idea of adherence to protocol is rigidity. They imagine mindless automatons, heads down in a checklist, incapable of looking out their windshield and coping with the real world in front of them. But what you find, when a checklist is well made, is exactly the opposite. The checklist gets the dumb stuff out of the way, the routines your brain shouldn’t have to occupy itself with (Are the elevator controls set? Did the patient get her antibiotics on time? Did the managers sell all their shares? Is everyone on the same page here?), and lets it rise above to focus on the hard stuff (Where should we land?).
But step one on the list is the most fascinating. It is simply: FLY THE AIRPLANE. Because pilots sometimes become so desperate trying to restart their engine, so crushed by the cognitive overload of thinking through what could have gone wrong, they forget this most basic task. FLY THE AIRPLANE. This isn’t rigidity. This is making sure everyone has their best shot at survival.
All learned occupations have a definition of professionalism, a code of conduct. It is where they spell out their ideals and duties. The codes are sometimes stated, sometimes just understood. But they all have at least three common elements. First is an expectation of selflessness: that we who accept responsibility for others—whether we are doctors, lawyers, teachers, public authorities, soldiers, or pilots—will place the needs and concerns of those who depend on us above our own. Second is an expectation of skill: that we will aim for excellence in our knowledge and expertise. Third is an expectation of trustworthiness: that we will be responsible in our personal behavior toward our charges. Aviators, however, add a fourth expectation, discipline: discipline in following prudent procedure and in functioning with others. This is a concept almost entirely outside the lexicon of most professions, including my own. In medicine, we hold up “autonomy” as a professional lodestar, a principle that stands in direct opposition to discipline. But in a world in which success now requires large enterprises, teams of clinicians, high-risk technologies, and knowledge that outstrips any one person’s abilities, individual autonomy hardly seems the ideal we should aim for. It has the ring more of protectionism than of excellence. The closest our professional codes come to articulating the goal is an occasional plea for “collegiality.” What is needed, however, isn’t just that people working together be nice to each other. It is discipline.
Airline manufacturers put a publication date on all their checklists, and there is a reason why—they are expected to change with time.
One essential characteristic of modern life is that we all depend on systems—on assemblages of people or technologies or both—and among our most profound difficulties is making them work.
“Anyone who understands systems will know immediately that optimizing parts is not a good route to system excellence,”
When we look closely, we recognize the same balls being dropped over and over, even by those of great ability and determination. We know the patterns. We see the costs. It’s time to try something else. Try a checklist.
In the spring of 2007, as soon as our surgery checklist began taking form, I began using it in my own operations. I did so not because I thought it was needed but because I wanted to make sure it was really usable. Also, I did not want to be a hypocrite.
Just as powerful, though, was the effect that the routine of the checklist—the discipline—had on us. Of all the people in the room as we started that operation—the anesthesiologist, the nurse anesthetist, the surgery resident, the scrub nurse, the circulating nurse, the medical student—I had worked with only two before, and I knew only the resident well. But as we went around the room introducing ourselves—“Atul Gawande, surgeon.” “Rich Bafford, surgery resident.” “Sue Marchand, nurse”—you could feel the room snapping to attention.
WordPress Checklists
Checklist Resources
Release Process Checklists by Ryan Boren was originally posted at https://make.wordpress.org/core/2016/03/04/release-process-checklists/
.
. If you do however find any quirks related to this change, do not hesitate to leave a comment on this post or the relevant ticket: