ReleaseOps on the Ward: A Cancer Network’s Story

Cancer Care

I joined the digital team at a cancer network on a Monday, and by Thursday I had heard the phrase “big bang release” said the way sailors say a storm’s name. The team of nine looked after Pathway, a planner that helped patients prepare for treatment — appointments, pre-scan instructions, a checklist of questions to bring. The clinicians loved the idea. The patients never saw it arrive calmly. Every few months the whole thing changed overnight for everybody, and the support inbox paid for it for a week. This is the story of how that team adopted ReleaseOps and learned to ship the way the hospital’s own wards do: in rounds, with observations written down, and nobody afraid to say “not today”. The practice we eventually borrowed had a name, ReleaseOps, and it came to us the way most good ideas reach hospital IT — sideways, through someone who had worked elsewhere.

The Planner Nobody Opened Twice

Pathway’s trouble was not craftsmanship. The code was tidy, the tests were green, the design had won something. The trouble was that installation and introduction were the same moment. When version four went out one March night, every patient in the network woke to a different screen, a different structure, a different set of words. Onboarding a newly diagnosed person is delicate work — there is a whole craft to the questions worth asking after a diagnosis, and our relaunch had just moved every answer. Calls flooded the helpline. Some older patients simply stopped opening the app; a tool built to settle anxious people had agitated them, and half of them never gave it a second chance.

The retrospective was long and honest. Priya, our product lead, wrote one sentence on the whiteboard that survived every reorganisation since: “We installed. We never released.”

ReleaseOps Enters Through the Case Conference

Meera, the clinical liaison, had spent fifteen years attending multidisciplinary team meetings — the case conferences where surgeons, oncologists, radiologists and nurses review each new patient together before anything happens. Her cousin, an SRE at a logistics firm, had shown her the Atlas entry on ReleaseOps over a family dinner, and she arrived at our planning session with a printout and a question that rearranged the quarter: “Why does your software get less deliberation than a biopsy result?”

The printout’s central split became our founding document. Putting a build onto servers is one move; letting patients meet its behaviour is a second. Between them sits a set of decisions — who sees it first, what we watch for, when we widen, when we step back. Two dials, her cousin’s notes said: the first sets where the build runs, the second sets who encounters it. We had been welding them shut for years and calling it shipping.

Rings That Behaved Like Ward Rounds

We rebuilt the next feature’s launch as circles. Twenty hospital volunteers — the tech-comfortable ones who enjoy breaking things politely — saw the new medication-reminder screen first. A week of watching. Then one pilot ward. Another week. Then two regions, then the network. Each circle had a stated question attached, the way a ward round has an observation plan: are patients finding the confirmation button, are reminder times landing sensibly, is anybody calling the help desk confused. If the answer to any of those turned sour, the circle shrank back the same afternoon, because the feature lived behind a flag — exposure we could close in seconds without redeploying anything.

It was Meera who pointed out that we had reinvented her case conference: a group of specialists, a sequence of small observations, a decision to proceed only when the evidence said so. Clinicians had run staged rollouts on humans for a century; the software industry just kept forgetting. There is a good piece on how care teams construct personalised treatment plans on this very site, and the shape of that process — assess, dose gently, observe, adjust — is the shape of every launch we have run since.

The Flag That Refused to Die

Not everything went smoothly, and the smoothest-looking part was the sneakiest. Our first-generation flags were meant to expire. One did not. A dark-launched scheduling tweak from the previous autumn stayed wired into the codebase through two redesigns, and by the time anyone tried to remove it, nobody could say what still depended on it. The flag had become load-bearing scaffolding on a building that had changed floors. The Atlas has a name for this — flag debt — and a rule that stuck with Tomas, our SRE: a release flag belongs to a span of weeks and never to a season. We built a small registry with an owner and an expiry date on every flag, and Tomas reads the overdue list at each fortnightly review the way a pharmacist reads a slow-moving shelf. Nothing is allowed to become furniture.

The Week We Froze Everything on Purpose

Last winter taught the quietest lesson. During a demanding treatment season, our error budget — the small allowance of failure we spend before we owe the system care — ran dry three weeks before the holiday peak. Instead of heroics, we froze. Not a total embargo: the Atlas describes Google’s version of this, a freeze that halts everything except the most urgent fixes and security work, and ours worked the same way. Routine features waited. The team spent the quiet days on the backlog of small reliability repairs nobody had been able to justify, and we entered January calmer than we had entered any month since I joined. A freeze, we learned, is not fear. Spent deliberately, it is the system collecting the rest it is owed.

What ReleaseOps Sounded Like by Spring

The vocabulary of the practice settled into our standups without ceremony. Someone asks what our exposure is on the current change, and the answer is a number of patients, not a percentage of servers. Someone else asks whether the back-out path for the new visit-summary screen has been rehearsed this month; the Atlas is blunt that an unrehearsed rollback is a hope, not a plan, and we have stopped pretending otherwise. The fortnightly review reads three figures aloud: how often defects were caught while exposure was still small, how many patient-minutes a bad change touched, and how long the platform took to reach a safe state the last time something went wrong.

Nobody on the team uses the phrase “big bang” any more, except about the old days. The planner still changes, often and usefully, but it arrives the way good medicine does — in measured doses, with observations between them, and always with someone holding the authority to say stop. If your team builds anything that worried people depend on, the wards figured this out long before we did. We just finally listened. For the engineering context around all of this, the site’s walkthrough of how modern delivery teams run their craft picks up where our story leaves off.

Leave a Reply