Agile Is a Cargo Cult

After watching over 50 "Agile transformations" across three decades, I've seen the same pattern: according to research by Cross, Gardner & Crocker, 90% of companies struggle to successfully implement Agile at enterprise scale. They've built runways in the jungle, waiting for cargo that rarely comes.

I understand why organizations adopt Agile. The manifesto's values are genuinely wise: responding to change over following plans, working software over comprehensive documentation, collaboration over negotiation. These principles solve real problems that waterfall created. Smart people adopted Agile for good reasons: the alternative, waterfall, really was worse. Six-month planning cycles, requirements documents nobody read, testing as an afterthought. Agile addressed real dysfunction.

The problem isn't the principles. The problem is what happened to them.

In World War II, Pacific islanders watched American military bases receive supplies from aircraft. After the war ended and the bases closed, some islanders built replica runways with bamboo control towers. They hoped to attract more planes. They performed the rituals perfectly. The cargo never came.

This is what most organizations do with Agile. They rename project managers to "Scrum Masters." They hold daily standups. They call requirements "user stories." They have retrospectives and sprint planning and velocity charts. The rituals are perfect. The transformation never happens.

Are You in Cargo Cult Agile?

You're performing rituals instead of practicing agility if:

• Standups exist but decisions don't change afterward
• Velocity is measured but outcomes aren't
• Sprints happen but architecture stagnates
• Retrospectives list the same problems quarter after quarter
• Story points get converted back to hours for "real" planning

Recent research cataloged 36 distinct behaviors that qualify as "cargo cult" Agile. These imitate Agile practices without reflecting the underlying values. The academic term is "ASDM cargo cult behavior." The street term is more accurate: fake Agile.

Here's what the full pattern looks like:

• Waterfall in Agile clothing. The phases are still there—requirements, design, development, testing—they're just called "Sprint 1" through "Sprint 4"
• Standups that are status meetings. Fifteen minutes of people reporting to a manager instead of coordinating with teammates
• Story points as time estimates. Converting points back to hours defeats the entire purpose of relative estimation
• Sprints as deadlines. Fixed scope, fixed dates, "variable resources"—that's just project management with a vocabulary change
• Retrospectives without change. The same problems listed quarter after quarter because no one has authority to fix them

If you have hours of meetings, a three-month increment, and fixed deliverables committed months in advance, you're doing waterfall. Calling the requirements "user stories" doesn't change anything. Renaming meetings to "standups" doesn't either.

Cargo Cult vs. Actual Engineering

The difference isn't subtle once you know what to look for:

If your organization is on the left side of this table, no certification will fix it. The problems are cultural, not procedural.

How We Got Here

Dave Thomas, one of the original signatories of the Agile Manifesto, declared "Agile Is Dead" in 2014. His diagnosis: agility had degraded into a noun. A proper noun. Capital "A" Agile became a commodity that could be packaged and sold.

The original Manifesto was written by developers frustrated with heavyweight processes. It was a set of values, not a methodology. "Individuals and interactions over processes and tools" was a reaction against what Agile has become. A process-heavy, tool-dependent, certification-driven industry.

What happened was predictable: the Agile Industrial Complex. A Certified Scrum Master credential costs $1,000-$1,500 for a two-day class. SAFe certifications run $1,000-$2,000 per level, and there are multiple levels. Organizations spend $50,000-$500,000 on "transformation consultants." Jira and similar tools charge per-seat fees that scale into six figures for large enterprises. This creates a $10+ billion industry with powerful incentives to keep the complexity flowing—and zero incentive to admit that the rituals don't work.

The Core Misunderstanding

Most Agile coaches don't understand the principles. For them, Agile is a method to do things faster and cheaper. They imitate technical practices seen elsewhere. They never change the main things: mindset, leadership style, culture.

Real agility isn't about standups and sprints. It's about:

• Responding to change over following a plan. Not "we'll add it to the backlog for next quarter"
• Working software over comprehensive documentation. Not "we need the spec before we can start"
• Customer collaboration over contract negotiation. Not "submit a change request"
• Individuals and interactions over processes and tools. Not "update the Jira ticket"

These values are subversive. They threaten management hierarchies, project management offices, and control apparatus. So organizations adopt the rituals while rejecting the values. Often founder ego prevents real change. Admitting the process isn't working means admitting leadership chose poorly.

The Illusion of Agility

From a process perspective, cargo-cult teams seem to be doing everything right. They have all the roles. They hold all the events. They work with all the artifacts of Scrum. They can pass any audit. They can show any metric.

But the real benefits of agile aren't there. They ship just as slowly. They respond to change just as poorly. They're just as disconnected from customers. The only difference is more meetings.

The clearest sign of cargo cult Agile: everyone changed job titles but nothing else changed. The project manager is now a Scrum Master but still manages. The business analyst is now a Product Owner but still writes requirements documents. Developers still code in isolation and throw it over the wall.

What Organizations Actually Want

Here's the uncomfortable truth: most organizations don't want agility. They want predictability with agility's vocabulary.

Executives want to know exactly what will ship and when. That's fundamentally incompatible with responding to change. You can't promise fixed scope on fixed dates AND adapt to new information. The constraint triangle hasn't been repealed.

So organizations say "we're Agile" while demanding:

• Detailed roadmaps planned a year in advance
• Fixed release dates committed to customers
• Velocity targets that become quotas
• Sprint commitments that can't be changed

This isn't Agile. It's project management with more meetings. And often, fewer results.

The Certification Problem

You can become a Certified Scrum Master in two days. You can become a SAFe Program Consultant in four days. These certifications require no demonstrated ability to ship software, lead teams, or create value. A 2024 study by Engprax surveyed 600 engineers and found that projects self-identifying as "Agile" had significantly higher failure rates, but the methodology matters. "Agile" in most organizations means cargo-cult practices, not actual agility. It's the same problem with technical interviews: elaborate rituals measuring the wrong things.

Follow the money. The Scrum Alliance has issued over 1.5 million certifications. At $1,000+ each, that's over $1.5 billion just from certification fees—not counting recertification, training materials, or consulting engagements. Scaled Agile, Inc. charges $995 per person for a two-day SAFe Agilist course. Companies pay $200,000+ to become "SAFe Partners" with rights to sell more certifications. This creates an ecosystem where everyone profits from complexity (trainers, consultants, tool vendors, certification bodies) except the teams trying to ship software.

The certifications exist because organizations need proof of compliance. HR needs to check a box. Procurement needs to verify vendor qualifications. The certificates prove you attended a class and passed a test. They prove nothing about understanding or applying the principles. I've seen Certified Scrum Masters who never wrote code run teams of developers. They know the rituals perfectly. No idea why the rituals exist, what problems they solve, or when to deviate.

What Actually Works

Organizations that succeed with Agile share traits that have nothing to do with certifications or frameworks. A Scrum Inc analysis found that projects with clear requirements documented before development were far more likely to succeed (which sounds obvious, but it contradicts the cargo-cult interpretation that "Agile means no documentation." The winning teams I've worked with share these traits:

• Small teams with direct customer contact
• Authority to ship without approval chains
• Tolerance for experimentation including failure
• Technical excellence as a prerequisite, not an afterthought
• Leadership that protects the team from organizational dysfunction

These things are hard. They require organizational change, not vocabulary change. They can't be bought or certified into existence. That's what the original Agile Manifesto was actually about.

The irony: the most agile teams I've worked with don't talk about being Agile. They ship software. They talk to customers. They iterate based on feedback. No framework needed.

The Cargo Cult Diagnostic

Score your team. One point for each behavior you recognize:

1. Story points are converted back to hours for "real" planning
2. The standup takes longer than 15 minutes
3. Retrospectives list the same problems quarter after quarter
4. Velocity is reported to executives as a productivity metric
5. Sprint scope changes are treated as failures, not adaptation
6. The Product Owner writes requirements documents, just calls them "user stories"
7. Developers can't deploy without manager approval
8. The team has never spoken directly to a customer
9. "We'll add it to the backlog" means "it rarely happens"
10. You have a "Scrum Master" who's never written code

Score: 0-2: You might actually be agile.
Score: 3-5: Cargo cult symptoms. Fixable with leadership buy-in.
Score: 6-10: You're doing waterfall with different vocabulary. Stop pretending.

The Minimum Viable Process

If you scored 3+, here's what to do Monday morning. Replace the rituals with engineering:

The goal isn't zero process. It's process that earns its cost in shipped software.

The Anti-Jira: A Radical Alternative

Want to actually ship? Here's a markdown-based project management system that fits in a single file. No per-seat fees. No velocity charts. No sprint planning theater. Just work that needs doing, organized by who's doing it and what's blocking them.

# PROJECT_STATUS.md
# Updated: 2026-02-03 (update this daily, async)

## 🔥 This Week's Focus
One sentence. What ships by Friday?
> Ship the payment retry logic. Nothing else matters.

## Active Work

### @alice
- [x] Payment retry: handle timeout errors ✅ merged
- [ ] Payment retry: add exponential backoff (TODAY)
- [ ] Payment retry: write integration test
- **Blocked:** Need access to Stripe sandbox (asked @bob)

### @bob
- [ ] Fix memory leak in worker process
- [ ] Review Alice's retry PR
- **Blocked:** Nothing

### @carol
- [ ] Customer dashboard: loading state
- **Blocked:** Waiting on design (ETA: tomorrow)

## Decisions Made
| Date | Decision | Why | Who |
|------|----------|-----|-----|
| 2/1 | Use Stripe webhooks, not polling | Polling adds 30s latency | alice, bob |
| 1/28 | Kill the admin portal rewrite | Not enough users to justify | team |

## Done This Week
- Payment service error logging (alice)
- Upgraded Postgres to 16 (bob)

## Parking Lot (not this quarter)
- Mobile app push notifications
- Multi-currency support
- That refactor everyone wants but nobody needs

How to use it:

• Update async. Each person updates their section at end of day. No standup needed.
• One focus per week. If you can't state it in one sentence, you don't have focus.
• Blocked = action required. If you're blocked, name the person who can unblock you.
• Decisions get recorded. Future-you will thank present-you.
• Done moves to "Done." Celebrate the wins. Delete after 2 weeks.

That's it. No sprint velocity. No story points. No burndown charts. Just humans coordinating work in a text file that lives in your repo, version-controlled alongside your code.

The Jira ticket that took 15 minutes to create? It's now a checkbox that took 5 seconds. The 2-hour sprint planning meeting? It's now a 5-minute async read. The "what's everyone working on?" standup? It's answered before anyone asks.

Copy this template. Put it in your repo. Delete Jira.

When Agile Works

I'm not saying Agile ceremonies are always theater. They work when the conditions are right:

• Small autonomous teams. 4-8 people who can make decisions without escalation. No dependencies on other teams for every release. Actual authority matches responsibility.
• Direct customer contact. The team talks to users, not to product managers who talk to users. Feedback loops measured in days, not quarters. Real problems, not requirements documents.
• Leadership that absorbs organizational dysfunction. Someone shields the team from roadmap theater, status meetings, and compliance rituals. The team focuses on shipping while management handles politics.

When these conditions exist, Agile ceremonies become useful coordination tools. Standups actually coordinate. Retros actually improve process. Sprints actually ship. But these conditions are rare, especially at scale. Most organizations have the ceremonies without the autonomy.

When My Criticism Is Wrong

My "cargo cult" framing misleads when:

• You're comparing to actual waterfall. If your alternative is six-month release cycles, requirements documents that nobody reads, and testing as an afterthought—even cargo-cult Agile is an improvement. I'm comparing to engineering excellence, not to dysfunction.
• The ceremonies create forcing functions. For junior teams or teams without strong engineering culture, standups force communication that wouldn't happen otherwise. Retros force reflection. Sprints force shipping. Structure helps before discipline exists.
• You're using it as a Trojan horse. Some teams adopt Agile ceremonies to get organizational permission for smaller batches, faster feedback, and customer contact. The ceremonies are theater; the underlying change is real. If it works, it works.
• Your organization genuinely changed. Some organizations do transform. Leadership absorbs dysfunction, teams gain autonomy, ceremonies become coordination instead of compliance. If the cargo came (if you're actually shipping faster and adapting better) ignore my skepticism.

The test isn't whether you use the word "Agile." It's whether you ship working software to users who give you feedback that changes what you build next. If that's happening, your process is working regardless of what you call it.

Why I Don't Use the Word Anymore

The word "Agile" has been so corrupted that using it invites misunderstanding. When I say "Agile," someone pictures Jira tickets. Someone else pictures SAFe trains. Another person pictures their failed transformation project.

Now I describe what I mean directly: ship frequently, talk to users, adapt to feedback, cut waste. These are good engineering principles that predate the Agile Manifesto and will outlast it. They don't need a proper noun or a certification.

The Agile Manifesto itself is still valuable. It's sixteen sentences that capture something true about software development. The problem isn't the manifesto—it's everything built on top of it. Like microservices, Agile solved a real problem and then became a cargo cult that created new ones.

"Here's the uncomfortable truth: most organizations don't want agility. They want predictability with agility's vocabulary."