Sequencing An Agile Transformation

Transformations rarely fail because someone chose the wrong framework. They fail because the interventions were applied in an order that guaranteed each one would be undermined by the conditions that had not yet been addressed. Teams are trained in a way of working that their funding model forbids. Ceremonies are installed on top of team boundaries that make the ceremonies incoherent. Scaling machinery is bolted onto an engineering capability that cannot integrate more than once a quarter. Each individual decision is defensible. The sequence is what kills it.

The reason sequencing gets so little attention is that it is invisible in the business case. A transformation plan is written as a list of workstreams — training, coaching, tooling, ways of working, scaling framework, metrics — and workstreams in a plan look parallel. In reality there are hard dependencies between them, and running a downstream workstream before its precondition exists does not merely waste the effort. It actively damages the programme's credibility, because the people involved experience an intervention that visibly does not work and reasonably conclude that the whole thing is theatre.

What follows is an order of operations. It is not a schedule, because the durations vary enormously by context, and it is not a maturity model, because those encourage organisations to progress through stages for their own sake. It is a dependency graph: things that must be true before the next thing has any chance of working.

Diagnose before you intervene

The first mistake is starting with a solution. An organisation decides it is going to "do agile" or "adopt SAFe" or "move to product operating model" and begins implementing before anyone has established what is actually slowing delivery down. This is the equivalent of prescribing before examining, and it produces the characteristic symptom of a transformation that is busy but not converging: lots of activity, no movement in any delivery measure.

A diagnosis worth the name takes weeks, not months, and answers a small number of questions with evidence rather than opinion.

Where does the time go? Take real items delivered in the last two quarters and map elapsed time against touch time. You are looking for the queues: approval gates, environment waits, cross-team dependencies, release windows, handoffs between analysis, build, test and operations. The distribution of waiting is the map of where the constraint lives.

What does it cost to release? How long from a developer finishing a change to a customer being able to use it, how much manual work is involved, and how often does it go wrong. This one number predicts more about what your transformation can achieve than any assessment of team-level practice.

How is the work funded and allocated? Are teams persistent or assembled per project? Who decides what a team works on, how often does that change, and is capacity matrixed across several initiatives?

Where are the dependencies? A census of which teams waited on which others, by type. See the-dependency-mathematics-of-scaling.

What is the information culture? Westrum's typology is a reasonable frame: does bad news travel, are messengers shot, are novel situations welcomed or deflected? This determines what change is possible at all, and cannot be fixed by process.

The output is not a maturity score. It is a ranked list of constraints with an argument for why each matters. A radar chart with eight dimensions scored one to five is an assessment rather than a diagnosis, and it will not tell you what to do first.

Structure before ceremony

The second mistake is installing practices onto team boundaries that cannot support them. A team that does not own a coherent slice of value cannot have a meaningful backlog, cannot have a Product Owner with real decision rights, and cannot make a sprint commitment it controls. Running Scrum ceremonies over that structure produces the form without the function — planning meetings where the team estimates work it cannot finish alone, and retrospectives about problems the team has no authority to fix.

So the structural work comes first: who owns what, who decides what, and whether a team can take a piece of work from request to production without another team's queue in the middle. Concretely this means establishing stream-aligned teams around bounded contexts or value streams, giving each a clear mission and a single prioritising voice, and making the ownership explicit enough that it survives a reorganisation.

This is uncomfortable because it touches reporting lines and budgets, which is exactly why transformations start with ceremonies instead. Ceremonies are cheap, visible and politically safe. They are also downstream of everything that matters.

A practical test: before installing any cadence, ask of each team whether it could deliver something a customer would notice without asking another team for anything. If the answer is no for most teams, fix that first. If it is no and cannot be fixed this year for architectural reasons, your transformation is a multi-year architectural programme wearing a process costume, and you should say so before someone commits to a twelve-month benefits case.

Engineering practice before scaling

The third mistake, and the most expensive, is scaling before the engineering base can support it. Scaling frameworks coordinate teams that integrate; if integration is manual, infrequent and risky, the coordination layer has nothing to coordinate except promises.

The engineering preconditions are unglamorous and well understood. Short-lived branches or trunk-based development. A build that runs on every change and is trusted enough that a red build stops work. Automated tests at a level of coverage where the team genuinely believes a green build means the change is safe. Deployment that is automated and repeatable. Environments obtainable without a ticket. The ability to release a small change independently of other changes.

Where these exist, almost any coordination approach works tolerably. Where they do not, none of them do, and the failure will be misattributed to the framework. This is the single most reliable predictor of transformation outcome that we encounter, and it is consistently the workstream that gets deferred because it produces no visible ceremony and its benefits accrue six months later. See trunk-based-development-and-why-it-matters and test-strategy-for-teams-that-ship-daily.

There is a corollary about measurement. Start reporting deployment frequency, lead time for changes, change failure rate and time to restore before you change anything else. You will need the baseline, and the act of measuring these four tends to redirect attention towards the constraint on its own. See dora-metrics-without-the-gaming.

One real value stream before a wave plan

The fourth mistake is planning the whole programme before proving anything. A transformation designed in full at the outset encodes every assumption the designers held before they had evidence, and those assumptions are then defended for the life of the programme because the plan has been committed to a board.

The alternative is to take one genuinely end-to-end value stream — from customer request through to production and support, including whatever governance it must pass — and change everything about it that needs changing. Not a pilot team. A pilot stream, including the funding, the governance, the architecture work and the engineering practice, because the point is to test the whole intervention rather than the easy part of it.

Choose the stream on three criteria. It must matter commercially, so the results are taken seriously. It must be representative enough that "that only worked because they are special" is hard to sustain. And it must have a leader who wants to do it, because volunteered energy beats mandated compliance at this stage.

Run it long enough to produce before-and-after numbers on lead time, deployment frequency and predictability. Expect to be surprised by at least one constraint you had not diagnosed — usually in governance, procurement or data. That surprise is the highest-value output of the exercise, because it is what would otherwise have derailed the wave plan you were about to publish.

Why "train everyone first" fails

The most common opening move is a mass training programme: every person through a two-day course, certifications counted, a dashboard of coverage.

It is easy to see why. It is fast, it is fair, it produces a number that rises, and it feels like a prerequisite — how can people work differently if they have not been taught? But it fails reliably, for three reasons.

Knowledge decays without application. Training delivered more than a few weeks before someone uses it is substantially lost, and training everyone at once guarantees that most of it is.

It creates expectation without capability. People leave the course understanding how it is supposed to work, return to a system that makes it impossible, and learn the most damaging lesson available: that the new way is aspirational and the old way is real. Every subsequent intervention has to overcome that prior.

It measures the wrong thing. Trained headcount is a coverage metric, and because it is easy to move it crowds out the harder measures. A transformation whose headline number is people trained has selected an indicator that can reach one hundred percent while delivery is unchanged.

Train just-in-time instead, close to the point of application, with the people about to do the work. Broad awareness sessions have a place — people need to know what is happening and why — but do not confuse awareness with capability building, or let the awareness programme consume the budget for the coaching that changes behaviour.

Wave design with entry and exit criteria

Once a stream has been through end-to-end and the approach has been corrected by contact with reality, expansion by waves is reasonable. The discipline that makes waves work is explicit criteria at both ends.

Entry criteria protect the programme from starting where it cannot succeed. A reasonable set: a named accountable leader in the receiving area who has asked to go, a defined value stream with identifiable customers, a baseline measurement taken, the engineering prerequisites either in place or funded with a date, and no competing reorganisation scheduled during the wave.

Exit criteria prevent waves from accumulating indefinitely. A wave is done when the teams operate without embedded support, when the delivery measures have moved and held for a stated period, and when the area can run its own improvement cycle. Without them, coaches stay forever and the organisation never develops the capability, because the capability keeps being supplied from outside.

	Without criteria	With criteria
Wave start	Determined by plan date	Determined by readiness
Failure mode	Starting in an area that cannot succeed	Slower start, higher hit rate
Wave end	Coaches drift to the next thing	Defined handover, measured
Capability	Stays with the programme	Transfers to the line
Programme end	Never arrives	Scheduled from the outset

Resist compressing waves to hit an annual narrative. Two areas done properly beat six done nominally: the two become the internal proof, the six become the internal counter-argument.

Build the internal cadre, and define the exit before you begin

An external coaching population is a temporary capability by definition. If the transformation's expertise resides entirely in contractors, then the organisation's improvement capacity ends when the contract does, and the predictable outcome is regression within a year.

Start identifying internal people in the first wave, not the last. You are looking for practitioners with credibility in the line — people whose opinion already carries weight because they have shipped things — rather than for people available because they are between assignments. Pair them with external coaches on real work, give them their own teams within a wave or two, and create a community that outlives the programme.

Two things make this work. The role must be a genuine career step rather than a siding; if the best engineers see coaching as a route off the technical ladder, you will get the wrong applicants. And internal coaches need explicit air cover, because their organisational position makes them far more vulnerable than an external who can be ignored politely. See the-scrum-master-value-problem.

The final sequencing point is the one most often skipped, and it belongs here because it is the other half of the same problem: agree, at the outset, what the transformation is for, how you will know it has worked, and when it stops.

That means three artefacts, written before the first intervention. A statement of the business outcome sought, in terms a sceptical finance director would accept — time to market, predictability, cost of change, quality in production. A small set of measures with baselines taken, drawn from flow and DORA rather than from framework compliance. And a handover definition: which functions in the line organisation take over which responsibilities, and by when.

The practical effect is to convert the transformation from an identity into something with a scope. That is uncomfortable for everyone involved, including the consultancy, and it is the strongest guarantee that the organisation ends up owning its improvement rather than renting it.

What to do on Monday

Take your current transformation plan and mark, against each workstream, its hard preconditions. Training presupposes application within weeks. Ceremonies presuppose teams that own a slice of value. Scaling presupposes teams that can integrate continuously. Product ownership presupposes funding that persists.

Any workstream currently scheduled ahead of its precondition should be moved or stopped. Expect this exercise to invalidate a meaningful part of the plan; that is the point, and it is far cheaper to discover now than in month nine.

Then pick the one value stream, agree the baseline measures this week, and write the exit criteria and handover date before anyone starts. If the sponsor will not agree to an end date, you have learned something important about what the programme is actually for, and it is better to know that in week one.