Agile Without the Nonsense

Shawn West
May 20, 2025
9 min read

Updated: Aug 7

Agile started as four values on one page. Somewhere between the manifesto and your calendar, those values became a compliance regime. Here is why that decay is predictable — and how to tell whether your ceremonies still buy you anything.

The standup where nobody was actually stuck

Picture the fourth daily standup of the week. Nine people stand in a semicircle. Each recites the same three lines — what I did yesterday, what I'll do today, any blockers — while looking at the delivery manager, not at each other. Nobody says they're stuck, because "stuck" reads as slow, and velocity is on the board behind them. The meeting ends in eleven minutes. Everyone agrees it was efficient. Two days later a developer quietly admits she's been blocked since Tuesday on a dependency nobody surfaced — because raising it in the standup would have meant admitting the sprint commitment was already dead.

That team is "doing Agile." They have the ceremonies, the board, the certified scrum master, the two-week cadence. What they don't have is the thing the ceremonies were supposed to produce: fast, honest coordination and working software delivered in small, low-risk increments. The ritual is intact. Its point has quietly evaporated.

This is not a story about one bad team. It is the predictable end state of a specific, common failure — and understanding the mechanism matters more than adding or cutting any single meeting.

Why "run the ceremonies properly" is the wrong diagnosis

When delivery stalls, the reflexive fix is more discipline: tighten the standup, enforce the retro, get everyone certified, buy the better tool. That answer is attractive because it is legible. A ceremony calendar is something a manager can see, schedule, and audit. "Are we agile?" collapses into "did we hold the meetings?" — a question with a yes/no answer and a dashboard.

The trouble is that the meetings were never the deliverable. Go back to what the seventeen authors of the 2001 Agile Manifesto actually wrote — four value statements, each in the same shape:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Read the structure, not just the words. Each line says we value A more than B — not B is worthless. Documentation, planning, and process all keep their place; the claim is only about what wins when the two sides conflict. There are no sprints here. No story points, no standups, no burndown charts, no velocity. Those were implementation details invented afterward to serve the values.

So "run the ceremonies properly" answers the wrong question. The ceremonies are a proxy for the values. Optimizing the proxy is exactly how a team ends up with a flawlessly executed standup in which nobody tells the truth.

The mechanism: how a value decays into a ceremony

The decay isn't bad luck or bad people. It follows a chain you can watch happen:

Value → Proxy → Target → Gamed proxy → Dead value.

A value is hard to measure. "Are we responding well to change?" has no clean number. "Are we collaborating?" doesn't either.
A proxy gets attached to it. Story points estimate relative complexity. Velocity counts points per sprint. A standup surfaces blockers. Each proxy is a reasonable, rough instrument for something real.
The proxy becomes a target. A manager needs to report progress upward, so velocity becomes the productivity number. A commitment becomes the promise the team is held to. Attendance becomes evidence of "being agile."
People optimize the target. This is the popular formulation of Goodhart's Law — "when a measure becomes a target, it ceases to be a good measure" (Marilyn Strathern, 1997, generalizing economist Charles Goodhart's 1975 observation). Estimates inflate so velocity trends up. Work is split into more tickets so the count rises. Blockers go unspoken because raising them threatens the commitment. Retros produce agreeable non-actions because sharp ones create conflict.
The value is gone — and, worse, actively harmed, because energy now flows into the number instead of the software.

The incentive is the engine. Nobody in the standup story decided to hide blockers; the scoreboard decided it for them. Once "looks productive" and "is productive" diverge and only the first is measured, a rational team drifts toward the first. This is also why certification-and-more-process is such a sticky answer: a market of trainers, tools, and coaches — some excellent, some with no software-delivery experience at all — has every reason to sell you more proxy. Process is what a process expert can see and bill for; culture and working software are not, and keeping that distinction straight is most of the job.

But notice where the failure actually starts. The standup didn't cause it — it exposed it. The team committed to a sprint scope built on a dependency nobody had validated during planning. That is a discovery gap: work was accepted as "ready" before anyone confirmed it could be done. The ceremony then became the place to hide the gap rather than the place to surface it. Most "Agile isn't working" stories are discovery failures wearing a process costume.

(Fact: the manifesto lists four values and twelve principles — and zero ceremonies. Interpretation: the standups, sprints, and points most teams equate with Agile are later add-ons that can serve the values or subvert them. The recommendation follows below.)

A developed example

(Composite scenario)

Context. A 30-person product team at a mid-size SaaS company had "gone Agile" eighteen months earlier. Six squads, two-week sprints, full ceremony set, a coach on retainer, velocity tracked per squad on a shared dashboard the VP reviewed every Friday.

The decision that went wrong. Leadership, wanting to compare squads, started treating velocity as a productivity metric — the highest-velocity squad got public praise, the lowest got "coaching." No one announced this as policy; it emerged from three Friday reviews.

What the team reasoned. Each squad concluded, correctly, that the safe move was to make velocity go up. Two ways to do that without shipping more: estimate the same work higher, and slice stories into more tickets. Both are invisible on a dashboard. Within a quarter, average story-point "velocity" across the org had risen by roughly half while the release calendar hadn't moved at all.

The result. Cycle time — the honest measure, days from starting a work item to shipping it to users — was flat or slightly worse, because more, smaller tickets added coordination overhead. Sprint reviews looked triumphant. Customers noticed nothing had sped up. A senior engineer put it plainly in a skip-level: "We're not building faster, we're counting louder."

The lesson. The failure wasn't the sprint length or the tooling. It was attaching a consequence to a proxy. The fix that worked was not a better ceremony — it was retiring velocity as a cross-team performance metric, replacing it on the VP's dashboard with cycle time and escaped-defect rate (both observable, both hard to game by splitting tickets), and moving estimation back to a private planning aid the squad used for itself. Ceremonies barely changed. Incentives did.

How to tell whether your ceremonies still buy you anything

You don't diagnose this by counting meetings. You diagnose it by asking, of each ritual, what real thing is this supposed to produce, and is it producing it? Observable checks:

Standup: In a normal week, does at least one real blocker get surfaced and picked up by someone? If standups are pure status recitation aimed at a manager, the coordination value is already dead.
Retrospective: Do the last three retros each yield one or two specific changes that actually happened? "We'll post a summary in Slack after every client call" is a change; "we should communicate better" is a complaint. Track the ratio of specific-and-done to vague-and-forgotten.
Estimation / velocity: Is any velocity number used to compare people or teams, or to set expectations upward? If yes, assume it is being gamed and stop trusting it as a measure.
Sprint: Is the two weeks a genuine build-learn-adapt loop, or a mini-waterfall — plan Monday, build midweek, test Friday, ship or slip? A sprint that never changes course based on what was learned is just a short deadline.
Outcome numbers: Track two things ceremonies can't fake — cycle time (item started → shipped to a real user) and escaped-defect rate (bugs found in production per release). If these are flat while your ceremony discipline is high, the rituals are theater.

The tell across all five: a healthy practice surfaces bad news earlier; a decayed one buries it.

When the ceremonies are worth keeping

None of this argues for abolishing structure. The full ceremony set earns its overhead in some contexts and wastes it in others, and the honest answer is a tradeoff, not a slogan.

| Practice | Worth the overhead when… | Not worth it when… | Warning sign you've crossed the line | | --- | --- | --- | --- | | Fixed sprints & commitments | New team, unclear priorities, or stakeholders who need a predictable cadence to plan around | Mature team with a healthy flow of small releases and stable trust | "Commitment" is used to pressure the team, and blockers go unspoken to protect it | | Story points & velocity | The team uses them privately to sanity-check whether work fits and to plan its own capacity | The number leaves the team and becomes a cross-team or performance comparison | Estimates inflate over time; ticket counts rise but releases don't | | Daily standup | The team is genuinely interdependent and blockers need same-day surfacing | Work is largely independent, or an async channel already surfaces blockers well | It's a performance for a manager; nobody addresses anybody else | | Full certified-Scrum apparatus | Regulated or safety-critical delivery needing auditable, uniform process across many teams | Small co-located team that can inspect and adapt on its own | Process compliance is measured; shipped outcomes aren't |

The exceptions are as real as the rule. A brand-new team with no shared habits often needs the scaffolding of fixed ceremonies precisely because it hasn't yet developed the judgment those ceremonies encode — the same way a novice cook follows the recipe exactly before learning to improvise. A regulated environment may require an audit trail a lightweight process won't produce. Decision type matters here: dropping a standup is trivially reversible; ripping out a process framework a compliance auditor relies on is not, so the cost of being wrong should set the rigor.

A method: the quarterly ceremony audit

Once a quarter, run each recurring ritual through the same short review. It takes about an hour with the team, and it replaces "are we doing Agile right?" with "is each of these still paying for itself?"

List every recurring ceremony and standing metric. Standups, planning, review, retro, backlog refinement, story points, velocity, burndown — whatever you actually run.
For each, write the one real outcome it exists to produce. Coordination, shared learning, risk reduction, capacity planning. If you can't name one, that's your answer.
Score it against the observable checks above. Is the outcome actually happening? Bring evidence — the last three retros' action items, the cycle-time trend, a show of hands on whether standup ever unblocks anyone.
Check the incentive. Is any output of this ceremony used to compare or rank people or teams? If so, flag it — that's where Goodhart bites.
Decide: keep, change, or cut. Keep what pays for itself. Change the ones producing the wrong behavior (usually by moving a metric back inside the team). Cut the ones that produce nothing but attendance.
Record the decision and the number you'll watch. Name the person who owns the change and the metric (cycle time, escaped defects) that will tell you next quarter whether it helped.

The output is a short written record: which rituals survived, which changed, which died, and the single honest number each change is meant to move. That record is the artifact — not a certificate, not a framework badge.

Implementation reality: this is a management change, not a team change

The hardest part isn't the audit; it's that the decay is usually driven from above the team. Velocity became a target because a manager needed a number to report upward — so the fix has to reach that manager, because the reporting line is where the real strategy actually lives. If the VP keeps ranking squads by velocity, no amount of team-level clarity will stop the gaming; the incentive outranks the intention every time.

Practically: whoever owns the reporting has to agree to change what gets reported (cycle time and escaped defects instead of velocity), and whoever owns the team has to make the private-tool ceremonies safe again by removing the consequences attached to their outputs. Expect resistance from anyone whose role is defined by the proxy, and expect a quarter or two before the honest numbers stabilize — teams that learned to game will wait to see if the change is real before they trust it.

What to do next

Before your next planning session, pull one number: the cycle time on your last ten shipped items — the actual days from "someone started it" to "a user could use it." Don't announce a transformation. Just put that number next to your velocity chart in the next review and ask the room a single question: which of these two tells us whether we're getting better at our jobs? That conversation, not a framework, is where the recovery starts.

Final takeaway

Agile's ceremonies are instruments, and every instrument can be optimized until it no longer measures the thing it was built to measure. The teams that stay fast aren't the ones with the most disciplined rituals or the most certifications — they're the ones who periodically check whether each ritual still surfaces bad news early, and who kill the ones that have quietly started to hide it.

Sources

Goodhart, C. A. E. (1975). Monetary Relationships: A View from Threadneedle Street. Papers in Monetary Economics, Reserve Bank of Australia — origin of the observation later named Goodhart's Law.
Strathern, M. (1997). "'Improving ratings': audit in the British University system." European Review, 5(3), 305–321 — source of the popular phrasing, "when a measure becomes a target, it ceases to be a good measure."