Congratulations on Your Agile Transformation (You Haven’t Had One)

Renaming your project managers "Scrum Masters" while keeping annual roadmaps, top-down delivery mandates, and a governance structure that would make a Victorian railway company feel nimble is not an agile transformation. It is a rebrand. A fairly expensive one, usually involving a consultancy, some Post-it notes, and at least one away day with a facilitator who uses the word "co-create" without irony.

This pattern has a name in the industry: cargo cult agile. And it is, by some margin, the most common outcome of enterprise agile programmes. You get the vocabulary without the values, the ceremonies without the culture, and the job titles without any of the actual authority those roles are supposed to carry.

If you are reading this trying to work out whether your organisation has done it — or is about to — this article is for you.

What is "cargo cult agile" and why does it keep happening?

The term borrows from anthropology. After World War Two, some Pacific Island communities built mock airstrips and wooden aircraft, hoping to attract the cargo planes that had brought supplies during the war. They had the form. They didn't have the function.

Enterprise agile transformations do the same thing with remarkable consistency. Organisations adopt the visible artefacts of agile — the daily standups, the sprint ceremonies, the Jira boards, the Scrum Master job titles — without touching the underlying operating model that makes those things meaningful.

The result is a system under considerable strain. Teams are asked to work in two-week sprints while being held accountable to delivery commitments made twelve months ago. Scrum Masters are expected to protect team capacity while having no authority to push back on the senior stakeholder who just added three "urgent" requirements on a Tuesday afternoon.

It is, in fairness, quite an achievement. Most organisations manage to get the worst of both worlds.

Why do organisations do this to themselves?

Rarely out of malice. Usually out of a combination of genuine misunderstanding, organisational risk-aversion, and the very human desire to appear to have solved a problem without actually having to change very much.

Senior leaders often commission agile transformations because they have heard — correctly — that agile organisations are faster, more responsive, and better at delivering value. What they sometimes do not fully internalise is that this speed comes from distributed decision-making, which means giving up some of the control they currently hold.

That is a harder conversation than buying everyone a copy of the Scrum Guide.

What does a real Scrum Master actually do?

A Scrum Master is a servant-leader role defined in the Scrum framework (the most widely used agile framework in software development). Their job is to help a team understand and apply Scrum values, remove impediments to the team's progress, and protect the team from external interference.

That last part is worth sitting with. Protect the team from external interference.

In an organisation where the annual delivery schedule has been handed down from the executive layer and is essentially non-negotiable, a Scrum Master cannot do that job. They can facilitate a retrospective. They can run a sprint planning session. But they cannot protect a team from a governance model that treats their sprint backlog as a formality on the way to delivering what was already decided in Q4 last year.

What's the difference between a Scrum Master and a traditional project manager?

This is where the renaming problem becomes concrete. A traditional project manager is typically accountable for delivering a defined scope, on time and on budget, as agreed at the start of a project. They manage risk, track progress, and report upward.

A Scrum Master has no delivery accountability in that sense. They are not responsible for whether the product ships. They are responsible for the health of the process and the team.

These are genuinely different jobs. Renaming one as the other does not change what the person is being held accountable for when they sit in front of their line manager.

Dimension	Traditional Project Manager	Scrum Master (as intended)	Scrum Master (as commonly implemented)
Primary accountability	Deliver scope on time and budget	Team effectiveness and agile process health	Deliver scope on time and budget (but in sprints)
Relationship to scope	Defends agreed scope	Has no authority over scope; that's the Product Owner	Manages scope handed down from above
Relationship to stakeholders	Reports upward, manages expectations	Coaches stakeholders on agile; shields team from disruption	Reports upward, manages expectations (as before)
Authority to say no	Within change control process	Significant — protecting team capacity is the job	Minimal — usually overridden by senior stakeholders
Planning horizon	Months to years	Sprint-level, with quarterly planning at most	Annual (with sprint ceremonies bolted on top)
Success metric	On-time, on-budget delivery	Team velocity, quality, and continuous improvement	On-time delivery (now measured in sprints)

How do you spot a cargo cult agile transformation in the wild?

I have worked across enough digital transformation programmes to have developed what I think of as a fairly reliable diagnostic. None of these indicators on their own are definitive. Together, they paint a picture.

The warning signs worth watching for

Annual delivery commitments exist and are non-negotiable. If the organisation committed to a list of features twelve months ago and those features will be delivered regardless of what the team learns in the interim, you are doing waterfall in two-week increments. That is not agile.
Scrum Masters report to the same people projects used to report to. If the person now called a Scrum Master sits in a PMO (Project Management Office) and is performance-managed on delivery milestones, the job title has changed and nothing else has.
The Product Owner role is a committee. In Scrum, the Product Owner is a single accountable individual with the authority to prioritise the backlog. If that role is actually a steering group that meets monthly and makes decisions by consensus, you have not got a Product Owner. You have got a RAID log with voting rights.
Retrospectives produce the same actions every time. A healthy retrospective drives genuine change. If your team has identified "better stakeholder communication" as an action item in fifteen consecutive sprints, the process is happening but the learning is not.
The word "agile" is used as a noun. "We've done an agile." No. You have not.
Velocity is reported to the board. Velocity (the measure of how much work a team completes per sprint) is an internal calibration tool for the team. The moment it appears in an executive dashboard as a performance metric, someone has fundamentally misunderstood what it is for.

What does "top-down yearly delivery schedules" actually break?

The entire premise of iterative, agile delivery is that you do not know everything at the start. You learn as you build. You adjust based on user feedback, technical discovery, and changing priorities. That is not a weakness of agile — it is the mechanism by which it delivers better outcomes.

An annual delivery schedule assumes you know, in October, exactly what users will need the following December. In most organisations, in most domains, this is optimistic to the point of being fictional. The schedule does not reflect reality; reality is eventually bent to fit the schedule, usually at some cost to quality, team morale, or both.

According to the Standish Group's CHAOS Report, projects using agile methods are significantly more likely to succeed than those using traditional waterfall approaches — but that finding applies to genuine agile adoption, not to waterfall with a Jira board.

Why do middle managers get caught in the middle of this?

I want to be direct here, because I think the "rigid middle manager" framing, while sometimes accurate, is often unfair.

Middle managers in large organisations are frequently asked to absorb an enormous amount of institutional contradiction. They are told to embrace agile values — transparency, empiricism, self-organisation — while simultaneously being held accountable to the same performance frameworks, reporting lines, and delivery commitments that existed before the transformation began.

That is not a character failing. That is a structural problem dressed up as a cultural one.

When an organisation renames its project managers as Scrum Masters without changing what those people are measured on, it has not failed to transform its middle managers. It has failed to transform itself, and handed the consequences to the people least able to resolve them.

What should organisations actually change at the management level?

Accountability frameworks. If Scrum Masters are still being measured on milestone delivery, change the metrics. Measure team health, cycle time, and quality indicators instead.
Decision-making authority. Agile teams need to be able to make decisions at the team level without escalating everything. If every decision above a certain threshold requires three layers of approval, the team cannot be self-organising.
Planning cadence. Move from annual planning to quarterly or rolling planning. Accept that the plan will change. Build governance structures that accommodate change rather than punishing it.
The role of the manager. In an agile organisation, managers focus on growing people and removing systemic impediments, not on tracking tasks. This is a genuine shift in how management work is defined, and it requires investment in development, not just a job title change.

Is there any value in the partial adoption of agile practices?

Yes, actually. And this is where I want to resist the purist position, because I think it causes more harm than good in practice.

Not every organisation can, or should, go full agile overnight. Some operate in regulatory environments that require significant upfront planning. Some have contractual commitments that constrain flexibility. Some are simply not culturally ready for the level of distributed authority that genuine agile requires, and forcing it creates chaos rather than improvement.

Partial adoption of agile practices can deliver real value — if the organisation is honest about what it is doing. Running shorter planning cycles, improving team retrospectives, giving teams more visibility of the backlog, reducing the size of work items — all of these are genuinely useful, even in a hybrid model.

The problem is not partial adoption. The problem is calling partial adoption a complete transformation, and then measuring success by counting the number of people with "Agile" in their job titles.

What does honest hybrid working actually look like?

Acknowledge that you are operating a structured-agile hybrid, not pure Scrum or SAFe (Scaled Agile Framework).
Be transparent with teams about which constraints are fixed (regulatory, contractual) and which are genuinely open to agile iteration.
Invest in training that reflects the actual operating model, not the theoretical one. Training people in pure Scrum when they work in a hybrid environment sets them up to be frustrated rather than effective.
Measure what matters in your context — not velocity for its own sake, but outcomes for users and the organisation.

What does a genuine agile transformation actually require?

I have been involved in digital transformation programmes long enough to have a fairly clear view of what separates the ones that actually work from the ones that produce a lot of Post-it notes and a lingering sense of disappointment.

The honest answer is that real agile transformation is an organisational change programme, not a technology or methodology programme. The technology is often the easy part.

The non-negotiable foundations

Executive sponsorship that means something. Not a sponsor who signs off the budget and appears at the launch event. A sponsor who actively changes governance structures, protects teams from organisational interference, and models the behaviours they are asking of others.
Genuine Product Ownership. Someone with real authority over the backlog, real access to users, and real accountability for outcomes — not features delivered.
A tolerance for uncertainty at the top. Boards and executives need to be comfortable with planning horizons that are shorter than they are used to, and with the idea that the plan will change. This is a cultural shift, and it starts at the top.
Investment in psychological safety. Teams cannot be transparent about problems, impediments, or failures if the organisational culture punishes honesty. Google's Project Aristotle identified psychological safety as the single most important factor in team effectiveness. Agile ceremonies surface problems — but only if people feel safe enough to name them.
Patience. The McKinsey research on agile transformations consistently finds that organisations take two to three years to see meaningful cultural and performance shifts from agile adoption. Expecting a return in six months is how you end up measuring the wrong things and declaring victory too early.

A note on the people who get left behind

There is something that does not get said often enough in conversations about agile transformation, and I think it is worth saying plainly.

When organisations rename roles without changing the work, they create a cohort of people who are now carrying the cognitive dissonance of the transformation on their behalf. The Scrum Master who knows they are actually a project manager. The Product Owner who has no real authority over the backlog. The team that goes through sprint ceremonies while everyone knows the real decisions are made somewhere else entirely.

These people are not failing to "get" agile. They are being asked to perform a role that the organisation has not actually created the conditions for. That is a leadership failure, not a workforce failure.

I have sat in enough retrospectives where this frustration surfaces — carefully, diplomatically, in the language of "process improvement" — to know that the people closest to the work usually have a very clear view of the gap between the stated model and the actual one. They are just rarely asked, in a way that feels safe enough to answer honestly.

Frequently Asked Questions

Is renaming project managers as Scrum Masters ever acceptable?

It can be a transitional step, but only if it is genuinely transitional — meaning the organisation has a credible plan to evolve the role, the accountability framework, and the authority structure over time. Renaming as a permanent destination, with no accompanying change to how the role is measured or empowered, is not a step toward transformation. It is a substitute for one.

What's the difference between agile and Scrum?

Agile is a set of values and principles, articulated in the Agile Manifesto (2001). Scrum is a specific framework for implementing those principles, with defined roles (Scrum Master, Product Owner, Development Team), ceremonies (sprint planning, daily standup, sprint review, retrospective), and artefacts (product backlog, sprint backlog, increment). Scrum is one way of being agile. It is not the only way, and agile is not the same thing as Scrum.

Can agile work in large organisations with complex governance requirements?

Yes, but it requires frameworks designed for that context — such as SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum), or Disciplined Agile. These frameworks attempt to reconcile agile principles with the realities of enterprise governance, portfolio management, and regulatory compliance. They work best when adopted with genuine intent to change operating models, not as a way to relabel existing structures.

How do you measure whether an agile transformation is actually working?

Look at outcome metrics rather than output metrics. Are users getting value more frequently? Is the time from idea to production shortening? Is team retention and engagement improving? Is the organisation learning and adapting based on real data? These are harder to measure than velocity or sprint completion rates, but they are the actual point. If the only things improving are the metrics on the agile dashboard, the transformation may be optimising the wrong things.

What should I do if I'm a Scrum Master in an organisation that hasn't actually transformed?

First: you are not alone, and the situation is not your fault. Second: be honest in retrospectives about systemic impediments, even when it is uncomfortable. Third: find allies — other Scrum Masters, sympathetic Product Owners, leaders who genuinely want change — and work with them to surface the gap between the stated model and the actual one. Fourth: recognise that some organisations are not ready to change, and that staying in a role where you are set up to fail is a choice you get to make.

Is there a quick way to tell if an agile transformation is genuine or performative?

Ask one question: "Can the team change what they are working on mid-year based on user feedback, without going through a formal change control process?" If the answer is yes, in practice and not just in theory, there is something real happening. If the answer involves a steering committee, a business case, and a twelve-week approval cycle, you have your answer.

Nicholas Hodder is a digital transformation and technology leader with over 20 years of experience working across public sector, charity, and commercial organisations. He has led agile programmes, sat through enough transformation kick-off events to have opinions, and speaks regularly on the gap between technology strategy and the reality of delivery. He occasionally finds this funny.