Transformation programmes fail at step zero: nobody agrees what the steps are. What follows is the sequence the evidence supports for rolling out DevOps across a charter airline’s digital team — the people running booking engines, quote calculators and crew-scheduling tools. Five steps, ninety days, with the reasoning attached so your team can audit the logic as well as the result.
Step one: map the value stream before changing anything
Gather the people who touch a change — developer, tester, approver, deployer — and reconstruct the journey of one real alteration to the booking flow, from idea to live. Put hours on every stage, especially the waits. Teams doing this for the first time routinely find that code spends most of its life parked: a merge window here, a test-environment queue there, a sign-off sitting in someone’s inbox over a weekend. The map is not decorative. It decides where the next three months of effort go, and it produces the first honest number most teams have ever had: how long a change really takes, end to end. Value stream mapping is the oldest tool in the lean kit precisely because it keeps working.
Step two: baseline the DevOps metrics you will be judged on
Five numbers, no more. Lead time for a change. How often you ship. How fast you recover. The failure share of changes — counted, per the 2023 redefinition, only when the change itself caused them. And rework rate, added by the same research programme in 2024 to capture capacity burned on redoing work. Baseline them for the mapped value stream only, publish them to the team, and refuse the temptation to benchmark against other departments yet. The baseline exists to make progress visible, not to furnish a leaderboard; metrics promoted into targets teach engineers to ship trivia and call it throughput.
Step three: automate the path and drill the recovery
This step has three parts, and order matters. First, collapse branching: trunk-based development with short-lived branches, so integration stops being a quarterly negotiation. Second, build once — a single artifact produced by the pipeline (GitHub Actions, GitLab CI, Jenkins, Tekton; any will do, none is magic) and promoted unchanged toward production. Third, drive feedback on any commit to roughly ten minutes, which is the working benchmark across high performers.
Then rehearse failure. The documented case is worth memorising: deployment d06 pushed payment errors up four percent; since the rollback had never been practised, recovery consumed about 190 minutes. The same failure, drilled in advance, closes in roughly twenty. The runbook is four lines — name the deployment and its owner; restore the previous artifact if no irreversible migration has run; otherwise pull the plug via a feature flag, or fix forward if no flag exists; and run the blameless review inside five working days. Canary releases and feature flags belong in this step too, because they make “toggle off” a realistic option rather than a slide in a deck.
Step four: replace approvals with controls an auditor can read
Aviation software lives under scrutiny, so make the scrutiny cheap. Least-privilege access, with standing production keys retired in favour of short-lived OIDC credentials. Expand-and-contract schema migrations — add the new structure, migrate the reads, retire the old — so that rolling back never strands data. Quarterly audits that sample about ten random changes rather than reviewing all of them, which improves evidence quality per auditor-hour. A break-glass merge path for genuine emergencies, logged on every use. One finding deserves emphasis in the steering meeting: heavyweight change approval boards are associated in the research with worse delivery performance, not better outcomes. Compliance and DevOps are compatible; ceremony and speed are not. If the risk team wants a single document, the Ops Atlas DevOps reference page assembles the regulated-industry evidence, the CALMS framework and the maturity ladder in one place.
Step five: spread the DevOps practice, not the mandate
The adoption evidence is unusually decisive here. A pilot value stream run under an enabling coach finished at 4.25 of 5. A centrally imposed toolchain managed 2.40, and a top-down mandate 2.50. The gap is not subtle, and the reason is organisational: habits transfer through demonstration, not decree. Conway’s law — software mirrors communication structures — means each team you convert changes the system around it, and Team Topologies formalises the idea by treating team boundaries as an engineering decision. Westrum’s culture work adds the social half: information flows toward problems in generative organisations and away from them in fearful ones, which is why blameless reviews outperform blame assignments in every dataset examined.
Choosing the pilot: three selection rules
The pilot decides the programme’s reputation, so select it deliberately. Pick a value stream with real revenue attached — the quote-and-book flow, not an internal wiki — because sceptics must be able to see the difference. Pick one with a manageable blast radius, so an early failure is survivable. And pick a team whose lead wants to do it; a volunteered team with a coach outranks an assigned team with a budget, every time the comparison has been run.
Roles that keep the rollout honest
Three roles, none of them new headcount. A sponsor who clears organisational obstacles and asks for evidence, not status updates. An enabling coach who has run the sequence before and knows where the queues hide. A value-stream owner who can change the process without asking three committees. Missing any of the three, the work still proceeds — it just proceeds at the speed of the argument you will eventually have to have.
What the ninety days should produce
- A value stream map with measured waits, and one queue permanently removed.
- Baselines for all five delivery metrics, plus a ninety-day delta.
- A trunk-based workflow with commit feedback under ten minutes.
- One drilled rollback, with its recovery time recorded beside the baseline.
- Auditor-approved controls replacing at least one manual approval gate.
- The J-curve survived: agree upfront that a performance dip is acceptable while testing standards rise, and put the acceptable duration in writing.
Passengers never see any of this, which is the point. They see outcomes, and outcomes are the only audit that matters to the people buying the seats. They see a quote page that prices correctly, a schedule change that appears within hours of being approved, and an outage that ends in minutes. For the travel side of the operation, booking mistakes first-time charter travellers should avoid and hidden costs to check before booking cover the customer experience your pipeline ultimately serves, while aircraft choice questions is a reminder that picking the right vehicle — software or aeroplane — is half the job.
