You have been asked to roll agile out across twelve teams. How would you approach it, and why do most transformations disappoint?

Refuse the framework question until there is a problem

The first move is to find out what the sponsor is unhappy about. "We want to be agile" is not a problem statement; "our releases take five months and we cannot respond when a competitor ships" is. The two lead to different work, and only the second gives you a way to know whether you succeeded. Ask what would have to be true in a year for this to have been worth the money, and write the answer down where the sponsor can see it.

Then go and find where time is actually spent. Take a handful of recently delivered items and trace each one from the moment somebody asked for it to the moment a user had it, marking every interval where it was waiting rather than being worked on. In most organisations the waiting dominates by a wide margin — sitting in an intake committee, in an architecture review, in a queue for a test environment, in a change-approval board, in a release window that comes round monthly. If eighty per cent of elapsed time is queue time outside the team, then every practice change inside the team is competing for the remaining twenty.

That measurement is also your best political instrument. It converts the conversation from a belief argument about agile into an evidence argument about specific queues, and queues have owners who can be asked to change something.

Change the system, not just the ceremonies

The recurring reason these programmes disappoint is that the visible layer is cheap and the expensive layer is left alone. Standups, boards and Sprint names are adopted in a fortnight. The structures that created the delay survive untouched, and then the delay survives too.

Symptom on the ground	The system that produces it
Teams re-formed every quarter, no ownership	Funding allocated to projects rather than to durable teams
Nothing ships until a quarterly release	Change-approval and release windows outside the team
Sprints planned but scope fixed for a year	Annual budget approved against a full scope and date
Endless carryover, nothing ever done	A separate QA or ops group with its own queue
Nobody available to help finish work	Individual utilisation targets and people split across three teams
Retrospective actions never happen	No slack in the plan, and no manager accountable for removing impediments

Pick one or two of the right-hand column and make them the actual programme. Moving from project funding to product funding, or letting one team deploy on its own cadence behind a feature flag, changes more than a year of coaching on estimation technique.

Leadership behaviour is in scope, and it is where you will be resisted

Ask the executive sponsors what they will do differently, and be specific: reviewing outcomes rather than milestone percentage complete, going to a Sprint Review instead of a separate status meeting, dropping the request for a twelve-month feature-by-quarter roadmap, holding one funding decision open until the first release. If the answer is that leadership will carry on as before while the teams change, you can predict the result now, and it is worth predicting out loud in the interview.

The related failure is treating certification as transformation. Training every team for two days and renaming the project managers Scrum Masters produces the vocabulary and none of the capability, and it is attractive precisely because it is legible, schedulable and finishes on time. Coaching capacity spent with managers, and engineering investment in test automation and deployment pipelines, both look slower on a plan and are what actually moves the lead time.

How to sequence twelve teams

Do not do all twelve at once. Take one or two teams with a willing sponsor and a real product, give them the structural exceptions they need — own their backlog, deploy themselves, keep the team together — and let them produce a result that other people want. Invitation beats mandate here for a straightforward reason: a mandated rollout gets compliance, and compliance produces the ceremonies without the intent, which is exactly the outcome you were hired to avoid. The trade-off is honest to state: invitation is slower, and some teams will decline, so you need the sponsor to accept an uneven map for a year.

Two things to be plain about. Scaling frameworks such as SAFe or LeSS are answers to a coordination problem, and adopting one before you know whether coordination is your constraint means buying process for a problem you have not diagnosed. And some transformations that are called failures did precisely what was asked: if the real objective was headcount visibility or a cost reduction, the programme will deliver reporting and reorganisation and no improvement in delivery, and it will do so on schedule. Naming that possibility with the sponsor at the start is the most useful thing you can do in the first week.