Pain has a way of localising a problem, which is why good clinicians start with the history before the scan. Apply that to hospital software and the history sounds like this: releases happen rarely and hurt every time; changes wait weeks in a queue; when something breaks, recovery takes hours and the room fills with people asking who approved it. Nobody enjoys the system, yet everyone believes it is just how hospital IT is. It is not. The pain has causes, the causes are diagnosable, and DevOps is the treatment plan with the strongest evidence behind it. This article walks the full pathway — symptoms, examination, imaging, treatment, rehab.
The symptoms you will recognise
- Release nights that require pizza, overtime and a quiet prayer, scheduled for weekends to limit the damage.
- A waiting list for changes that behaves exactly like every waiting list clinicians complain about — long, opaque, and measured by nobody.
- Hotfix Fridays: emergency patches stacked on top of an unstable base because the last big release shipped fourteen things at once.
- Incident meetings shaped like tribunals, after which people hide the next problem carefully.
- An audit season that stops the delivery team like a winter illness stops an outpatient clinic.
Why the pain persists untreated
Worth asking, because the symptoms have been described in vendor decks for a decade. The usual answer is that organisations treat the flare-ups — a faster server here, a “DevOps engineer” hire there — while leaving the four conditions alone. Chronic problems need the same thing chronic joint problems need: a correct diagnosis, a staged plan, and daily compliance. That is precisely what the rest of this pathway provides, and why it begins with imaging rather than with a purchase order.
The examination: four underlying conditions
Symptoms cluster, and so do causes. Nearly every aching delivery organisation shows some mix of four. Oversized batches: changes are bundled until a release becomes major surgery. Obstructed flow: work queues behind heavyweight approvals that the research links to worse outcomes, not better. Unrehearsed recovery: nobody has practised the rollback, so the first attempt is the performance — one documented case took 190 minutes unpractised against roughly twenty when rehearsed. Distorted measurement: either no measures at all, or worse, leaderboards that turn DORA figures into targets people game. Each condition feeds the others; a big batch fails, so approvals tighten, so batches grow bigger.
The imaging: confirming the DevOps diagnosis
Treatment without imaging is guesswork. Two pictures settle it. First, the value stream map: take one recent change, draw every step from request to production, and mark where it waited. In most hospital groups, waiting consumes the overwhelming majority of elapsed time, which tells you the problem is flow, not effort. Second, the baseline: measure how long changes take end to end, how often you ship, how quickly you recover, the share of changes that misfire, and how often finished work is redone — the five DORA measures, with rework rate arriving in 2024 and recovery counting only change-caused failures since the 2023 refinement. Then price the queue in cost of delay: twelve improvements worth 5,000 units a week, held three extra weeks, is 180,000 units of value a quarter that the hospital never receives. That single figure usually recruits the executive sponsor.
Treatment one: shrink the load
Stop bundling. Teams merge small changes into a shared trunk daily and let each travel independently to production. Risky features travel behind flags, invisible until switched on; a canary release gives them to a handful of users first, the way new physio exercises get trialled on a step before a staircase. The political part is decisive: whoever owns the release process must make small releases respectable, because in many hospital IT cultures a tiny deployment still feels like an admission of insincerity.
Treatment two: rebuild mobility
Next, automate the path so small changes can actually travel. One pipeline builds once and runs the same checks every time — any of GitHub Actions, GitLab CI, Jenkins or Tekton will serve; pick the one your people will maintain rather than the one generating conference buzz. Bring feedback — commit to trustworthy test result — in under ten minutes, because slower loops teach engineers to batch, and batching is the very condition we are treating. Make the database reversible with expand-and-contract steps, so a rollback never strands data. Then drill the recovery until it is boring: deployment identifier declared, owner named, rollback if reversible, flag off or fix forward if not. Boring is the goal; boring is what twenty minutes instead of 190 looks like.
Treatment three: correct the gait
Fix the walk, or the limp returns. Governance moves inside the pipeline: least-privilege access, credentials issued through OIDC that expire quickly, break-glass merge paths that alert the moment they are used, and quarterly audit sampling that traces ten or so random changes for evidence. Auditors accept — increasingly prefer — controls exercised continuously over signatures collected annually. After every incident, a blameless review publishes within five working days. And before the J-curve arrives — the dip that comes when automation raises testing standards — agree in writing how long it may last, because teams without that agreement abandon the work mid-rehab and call the treatment failed.
The rehab schedule for DevOps recovery
Ninety days, three phases, one value stream. The opening month — weeks one to four — is for seeing and stabilising: map, baseline, fix the ugliest manual step. The second month, weeks five to eight, automates the path as above. Weeks nine to twelve: govern and spread the practice to a second team with an enabling coach alongside. The reason coaching sits at the centre is arithmetic as much as philosophy: adoption studies put the coached pilot at 4.25, with 2.40 for toolchain-first programmes and 2.50 for mandates, on a 5-point scale. Recovery follows a familiar progression — siloed teams, automated islands, integrated delivery, continuous delivery, with a learning system crowning the ladder — and honest teams locate themselves on it before claiming the next rung. For the wider anatomy of modern operations, see our guides to DevOps transformation, training and support and to the unified XOps architecture.
Relapse warning signs
- A permanent “DevOps team” reappears and quietly becomes the new wall between builders and operators.
- Approvals multiply after each incident, batches grow to compensate, and the original pain returns on schedule.
- The five measures stop being published, or become a leaderboard, which amounts to the same distortion.
- Rollback drills lapse — the muscle memory fades faster than anyone expects.
One closing observation from the clinic floor: progress hides in unglamorous ledgers. The teams that stay fixed are the ones that keep a boring record — drill dates and timings, review publication dates, the quarterly sample results — because a habit nobody writes down is a habit waiting to lapse. Paper, in delivery as in physiotherapy, is part of the treatment.
None of this requires heroics. It requires the same qualities orthopaedics asks of patients: honest assessment, a staged plan, daily practice, and patience with the dip. Treat the causes rather than the symptoms and the release calendar stops being something the hospital braces for — it becomes, like a well-rehabbed knee, something nobody thinks about on the stairs. When you want the reference material behind this pathway, the Ops Atlas DevOps encyclopedia page covers every term the treatment plan uses.