Cargo cult Scrum: copying the form without the purpose

A company hears that a competitor released twice as fast after adopting Scrum. It buys the training, installs the tool, renames the project managers and schedules a stand-up at nine. Six months later, releases are no faster. The company concludes that Scrum does not work. What it actually tried was a copy of Scrum's outward form, and the form was never what produced the results.

The metaphor

The term cargo cult is used in many fields for the imitation of the visible features of a successful system in the hope of obtaining its benefits, without understanding the causes. The original examples were movements in the Pacific in which islanders, after seeing supplies delivered by outsiders during wartime, built imitations of the outsiders' runways and equipment to attract the same deliveries. The same pattern has been named in programming, where people copy code or structures they do not understand, and in science, where the outward forms of the scientific method are followed without its substance.

In Scrum the version is familiar. A team copies what a successful team does: the same meeting names, the same board, the same charts, even the same jargon. It expects the same results. It does not ask what each element is for.

How it differs from related patterns

They overlap. A cargo cult team is often also a zombie one. But the cause differs, and so does the cure: for a cargo cult, it is understanding, and not more discipline.

The Agile Manifesto as a test

The Manifesto offers a useful measure. It values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. Its principles ask for early and continuous delivery of valuable software, a team that reflects at regular intervals and adjusts its behaviour, and projects built around motivated individuals who are trusted.

A cargo cult team shows the opposite pattern. The process and the tools are the focus. The artifacts, the charts and the reports are the product. Customers are discussed, not met. The plan is followed because it was approved. Reflection is a ritual with no effect on behaviour. See Scrum and the Agile Manifesto.

How to spot it

• Elements exist because "that is what Scrum says". Nobody can say what the Daily Scrum is for in their own words.
• The vocabulary is perfect and the behaviour is old. People say "backlog" and "sprint" for what used to be a project plan and a phase.
• Charts are produced and not used. The burndown is drawn for a manager, and no decision depends on it.
• Practices are copied from another team's context. Story points because another team has them, with no use for them.
• Roles are renamed. The project manager is now the Scrum Master, doing the same job.
• Success is measured by compliance. "We held all the events" is a result.
• A template is applied everywhere. Every team has the same board and the same two-week cycle regardless of its work.
• Nobody has changed anything. There are no experiments.

A direct question exposes it: "What would happen if we stopped doing this?" If the answer is "I don't know" or "we'd be doing it wrong", the practice is probably cargo.

A worked example

This is an illustrative company. It adopted Scrum across forty teams after a consultant's workshop. Every team has a two-week Sprint, planning on Monday, a stand-up at 9:15 and a velocity chart reported weekly to a director. Each team has a person titled Scrum Master who was previously a project manager.

Releases are still quarterly, because a separate group controls the release process. Product Owners are business analysts who write requirements for the next quarter. Retrospectives are held, and no action ever involves the release process, since the team cannot change it. The velocity chart is rising everywhere, because teams know it is watched.

A new head of engineering asks a Scrum Master, "What does the Daily Scrum tell you that you cannot see on the board?" The Scrum Master has no answer. She asks a Product Owner, "What did you change in the plan last Sprint because of what you saw at the Review?" Nothing. She asks a Developer, "When did a user last use something you built?" Eight months ago.

She does not announce that the company is doing it wrong. She picks three teams and for six weeks asks three questions at the end of each Sprint: what did we learn, what will we do differently and what did a user see? The three teams begin to adapt. One negotiates a monthly release with the release group. One starts inviting customers to the Review. The others see and ask.

The cure was not more Scrum. It was the purpose of each part, one team at a time.

Rebuilding from purpose

1. For each element, write what it is for. One sentence. Use the Guide's own statements: the Daily Scrum inspects progress toward the Sprint Goal and adapts the plan; the Review inspects the outcome and decides what to do next; the Retrospective plans improvement.
2. Check that it does that. What information did it produce last time? What decision followed?
3. Drop what does not serve a purpose, or fix it. Drop only things that are additions around Scrum. Fix the core.
4. Replace imitation with experiments. Choose a practice, say why you expect it to help, try it for a few Sprints and review the evidence.
5. Connect with outcomes. Ask what changed for users because of the work.
6. Teach the why. Training that shows the reasons produces fewer rituals.
7. Beware of templates. Adopt practices because the team needs them.

The Guide's own wording supports the approach. It says Scrum is purposefully incomplete, only defining the parts required to implement Scrum theory, and is built upon by the collective intelligence of the people using it. A framework used that way cannot be copied. It can only be understood.

A note on AI-generated process

A new variation has appeared: documents, tickets and reports generated by tools with the right words in the right shape. The danger is the same as before, a convincing form with no thought behind it. A team that produces a perfectly formatted Sprint Goal without discussing it has gained nothing. The test stays constant: did it change what anyone did?

How to practise it

For each Scrum event on your calendar, write what it is for and one decision it changed last month. Any blank is a ritual to rebuild. In the simulator you make the decisions that each step is designed to produce, so you see what the form is meant to carry.