The Agile Manifesto is seventeen sentences long. Almost no one who runs an "Agile" team has read it. They've read the certification materials for Certified Scrum Master, which is a different thing — a procedural overlay invented to monetize a movement that started as a reaction against procedural overhead. The "Agile" at most companies today would be unrecognizable to the original signatories, and they would mostly hate it.
The value of Agile is in shorter feedback loops between writing code and learning what users do with the code. Everything else — the sprints, the standups, the points, the velocity charts, the burndowns, the retros — is a means, not an end. When the means become the end, you have Cargo Cult Agile, which has been dominant for fifteen years.
Let me describe 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 what users do with the code, on metrics you've defined in advance. You learn from the watching. You change what you build next based on what you learned. This entire loop should take days, not months.
The Agile Manifesto is not specifically about engineering process. It's about learning faster than your competitors. The teams that win do this. They have a tighter "did we just build something useful" loop than the teams that lose. The mechanism by which they achieve that loop is variable — Scrum works for some, Kanban for others, a custom flow for many — and the mechanism is much less important than whether the loop actually exists.
Theater Agile: a calendar of meetings.
Two-week sprints with the same length regardless of what's being built. Daily standups that report status to a manager (which is not what standups are for). Sprint planning where everyone estimates in story points whose meaning has drifted over time. Sprint retros that produce action items that are never followed up on. Sprint demos that show internal stakeholders the same screens they saw last sprint. Burndown charts that are tracked but not acted on. Velocity numbers that are measured but not improved. Backlog grooming sessions that don't change what gets built. A Jira board with 200 tickets, 60% of which will never be done.
This is the dominant pattern at most companies that say they're Agile. The rituals exist, the meetings happen, the artifacts get produced. But the feedback loop — the actual thing Agile is about — is broken or absent. The team is shipping every two weeks. The product manager doesn't have working metrics. Nobody is measuring whether features get used after they ship. 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 the stakeholders are happy" or "we hit our sprint commitment," you have theater. If the answer is "we noticed that feature Y is being used differently than expected, and we're going to adjust" or "the conversion in flow Z went down, here's what we think is wrong," you have real Agile.
Ask: "how long from idea to user impact?" If the answer is months (a quarter, six weeks, eight weeks), you have theater. If the answer is days or hours, you have real Agile.
Ask: "what would change if we deleted the sprint structure?" If the team would lose all coordination, you don't have a healthy team — you have a team that's learned to use sprints as the only mechanism of coordination. If the team would barely notice, you may not need sprints at all.
A few specific things that consistently work or don't work, based on having tried many of them across a lot of teams.
Daily standups: useful only at small scale. A standup of five to eight engineers, ten to fifteen minutes, focused on blockers and yesterday/today, is genuinely valuable. A standup of fifteen engineers, thirty minutes, where everyone gives a status report to a Scrum Master, is theater. Solution: if your standup has gotten bigger than ten people or longer than fifteen minutes, you have an org problem the standup can't solve. Don't double down on the standup.
Sprint planning: usually too much ceremony. Most teams do not need to plan two weeks of work in advance. The plan will be wrong by Thursday. A better mode for most teams: a short weekly priorities meeting (thirty minutes), and engineers pull work from a prioritized queue as they finish things. This is the Kanban model. It's much closer to how senior engineers actually want to work, and it produces less waste.
Story points: a vanity metric. Story points were originally a tool to escape time-based estimates (which everyone knows are wrong) by abstracting to "complexity." In practice, teams just convert points to time anyway, badly, and then management uses velocity (points per sprint) as a productivity metric, which incentivizes inflation. The exercise is mostly waste. Some teams use story points well and benefit. Most teams could delete them and lose nothing.
Sprint demos: best when they include users. A demo to internal stakeholders is theater. A demo to actual users — even five of them — generates feedback. If you can't get users for a demo, demoing internally is fine, but recognize that you're rehearsing, not learning. Optimize for getting users in the room.
Retros: useful only if action items happen. A retro is valuable if it produces specific, time-bounded changes that get implemented. A retro is theater if it produces the same complaints every two weeks (CI is too slow, the design hand-off is messy, we need better documentation) without any of them being fixed. Track retro action items. If they're not being closed, the retro is making your team feel like work is being done while no work is being done.
Velocity charts: at best meaningless, at worst harmful. Comparing velocity across teams is meaningless because the unit doesn't translate. Comparing velocity within a team across time is weakly meaningful if estimation discipline is stable, which it almost never is. Using velocity as a performance metric incentivizes gaming. Most healthy engineering orgs eventually 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, validated empirically in the DORA program's Accelerate: The Science of Lean Software and DevOps (Forsgren, Humble, Kim, 2018) — short lead time correlates with better organizational performance across every cohort they've measured.
What I'd actually recommend for a team starting fresh in 2026.
Continuous deployment from day one. Every merge to main goes to production. If you can't do that, prioritize fixing the things that prevent it (test reliability, deploy automation, feature flagging).
Trunk-based development. Short-lived feature branches (less than a day). PRs reviewed and merged within hours, not days.
Aggressive feature flagging. New features ship dark, behind flags. You can ship code without releasing it. You can release to 1% of users first. The deploy-release split is one of the most underrated pieces of modern engineering practice.
Real product metrics, not engineering vanity metrics. You should know within hours of release whether the feature is being used and whether it's having the effect you wanted. If you don't, you don't have a feedback loop, and you're not actually doing Agile no matter what your sprint cadence says.
A weekly priorities conversation between engineering, product, and someone close to the customer. Not a planning meeting. A conversation. Adjust the priorities based on what was learned in the last week.
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 are not the work. The work is the work.
One last 2026 thing. The cost of writing code has fallen sharply with AI coding tools. This makes the learning part of Agile more important than ever and the building part less of a bottleneck. Teams that respond to this by adding more building rituals (longer sprints, bigger backlogs, more planning meetings) are missing the shift. The right response is to shorten the loop on the learning side — more user contact, faster metric review, more frequent prioritization — because the building is no longer what gates iteration speed.
If your team is healthier with sprints than without, keep them. If you've been doing sprints for a year and the team still isn't shipping faster or learning more, the sprints were never the answer.