The Agile Manifesto is seventeen sentences long. Almost no one running an "Agile" team has read it. They've read Certified Scrum Master materials — a procedural overlay invented to monetize a movement against procedural overhead. Today's "Agile" would be unrecognizable to the original signatories, who would mostly hate it.

The value of Agile is in shorter feedback loops between writing code and learning what users do with it. Everything else — sprints, standups, points, velocity charts, burndowns, retros — is a means, not an end. When the means become the end, you have Cargo Cult Agile, which has dominated for fifteen years.

Here's what real Agile looks like, what theater looks like, and how to tell which one you're doing.

Real Agile: short feedback loops.

You ship code to production frequently — many times a day for mature teams, at least daily for most, at worst weekly. You watch user interactions on pre-defined metrics, learn from them, and adjust your next build accordingly. This loop should take days, not months.

The Agile Manifesto isn't about engineering process. It's about learning faster than competitors. Winning teams have tighter "did we just build something useful" loops. The mechanism varies — Scrum, Kanban, custom flows — but the loop's existence is crucial.

Theater Agile: a calendar of meetings.

Two-week sprints of fixed length. Daily standups reporting status to a manager. Sprint planning with story points whose meaning drifts. Retros with action items never followed up. Demos showing the same screens. Burndown charts tracked but not acted on. Velocity numbers measured but not improved. Backlog grooming that doesn't change priorities. A Jira board with 200 tickets, 60% of which will never be done.

This pattern dominates most "Agile" companies. Rituals exist, meetings happen, artifacts get produced. But the feedback loop — Agile's core — is broken or absent. Teams ship every two weeks. Product managers lack working metrics. Nobody measures feature usage post-launch. Sprint demos are performance, not learning.

How to tell the difference:

Ask your team: "What did we learn from the last release?" If the answer is "we shipped feature X and stakeholders are happy" or "we hit our sprint commitment," you have theater. If it's "feature Y is used differently than expected, and we're adjusting" or "conversion in flow Z went down, here's what's wrong," you have real Agile.

Ask: "How long from idea to user impact?" If the answer is months, you have theater. If it's days or hours, you have real Agile.

Ask: "What would change if we deleted the sprint structure?" If coordination collapses, you don't have a healthy team — just one reliant on sprints. If the team barely notices, you may not need sprints at all.

Specific practices that work or don't, based on extensive trials:

Daily standups: useful only at small scale. Five to eight engineers, ten to fifteen minutes, focused on blockers and yesterday/today, is valuable. Fifteen engineers, thirty minutes, reporting to a Scrum Master, is theater. If your standup exceeds ten people or fifteen minutes, you have an org problem a standup can't solve.

Sprint planning: usually too much ceremony. Most teams don't need to plan two weeks ahead. The plan will be wrong by Thursday. Better: a short weekly priorities meeting (thirty minutes), with engineers pulling from a prioritized queue. This Kanban model aligns with how senior engineers want to work and reduces waste.

Story points: a vanity metric. Originally to escape time-based estimates by abstracting to "complexity," teams convert points to time anyway, and management uses velocity as a productivity metric, incentivizing inflation. Some teams benefit from story points, but most could delete them without loss.

Sprint demos: best with users. Demos to internal stakeholders are theater. Demos to actual users — even five — generate feedback. If you can't get users, internal demos are rehearsals, not learning. Aim to include users.

Retros: useful only if action items happen. Valuable if they produce specific, time-bounded changes that get implemented. Theater if they repeat the same complaints (slow CI, messy design hand-off, poor documentation) without resolution. Track retro action items. If they're not closed, the retro is false productivity.

Velocity charts: at best meaningless, at worst harmful. Comparing velocity across teams is meaningless. Comparing within a team over time is weakly meaningful if estimation discipline is stable, which it rarely is. Using velocity as a performance metric encourages gaming. Most healthy orgs stop tracking velocity.

Cycle time is the metric that actually matters. From "we decided to build it" to "users are using it" — how long? This is the leading indicator of team health. Short cycle times mean faster learning, more shipping, better morale. Long cycle times reveal bottlenecks (code review, QA, deploy, approvals) that compound. Measure cycle time and chase the bottleneck. Few teams do this well, which is why most "Agile" implementations don't deliver promised acceleration.

What I'd recommend for a team starting fresh in 2026.

Continuous deployment from day one. Every merge to main goes to production. If you can't, fix what's preventing it (test reliability, deploy automation, feature flagging).

Trunk-based development. Short-lived feature branches (less than a day). PRs reviewed and merged within hours.

Aggressive feature flagging. New features ship dark, behind flags. You can ship code without releasing it. Release to 1% of users first. The deploy-release split is underrated.

Real product metrics, not engineering vanity metrics. Know within hours if the feature is used and effective. Without this, you lack a feedback loop and aren't doing Agile, regardless of sprint cadence.

A weekly priorities conversation between engineering, product, and someone close to the customer. Not a planning meeting. A conversation. Adjust priorities based on last week's learnings.

A monthly look at cycle time, not velocity. What slowed us down? What can we fix?

That's it. No sprints, no points, no Scrum Master, no daily standup if the team is healthy enough not to need it. The rituals aren't the work. The work is the work.

If your team is healthier with sprints, keep them. If after a year of sprints the team isn't shipping faster or learning more, sprints were never the answer.