Agile Isn't Dead. Agile Compliance Is.

Note on examples: The scenarios below are anonymized composites. This isn’t “Agile bad.” It’s “Agile the brand is often used to justify systems that do the opposite of Agile’s intent.”

Why this matters

Agile isn’t a set of meetings. It’s a physics statement:

Shorter feedback loops reduce risk.

Most enterprises didn’t fail Agile. They replaced Agile with a bureaucracy that uses Agile vocabulary:

• “Sprint” becomes a reporting interval
• “Velocity” becomes a performance metric
• “Planning” becomes a negotiation
• “Definition of done” becomes a checklist
• “Agile transformation” becomes a multi-year program

The result is predictable:

• delivery slows
• quality degrades
• reliability suffers
• engineers burn out
• product expectations aren’t met
• leadership gets more dashboards and fewer outcomes

This post is a production-first teardown of Agile theater - and a replacement model that actually ships.

TL;DR

• Agile is about learning quickly, not predicting perfectly.
• Scrum is useful when it reduces uncertainty. It’s harmful when it becomes a compliance system.
• If you treat sprints as contracts, you’ll get scrumfall: waterfall dependencies with sprint-shaped reporting.
• Replace “Agile compliance” with:
• Flow (small batches, limit WIP)
• Continuous delivery (safe, frequent releases) [4]
• Evidence-based planning (measure outcomes; adjust quickly) [5]
• Use system metrics (DORA) to verify improvement: lead time, deploy frequency, change failure rate, MTTR. [6]
• Beware Goodhart’s Law: metrics used as targets will be gamed. [7]

Contents

• Agile the physics vs Agile the bureaucracy
• Pattern 1: Sprints as contracts
• Pattern 2: Velocity as a performance metric
• Pattern 3: Backlog bloat as a museum of anxiety
• Pattern 4: Ceremonies become the work
• Pattern 5: Dependencies turn Scrum into fiction
• Pattern 6: Definition of done without production
• Pattern 7: Product ownership by proxy
• What’s better: Flow + CD + evidence
• Transition plan: 30 days without a revolution
• Verification: how you know it’s working
• A practical checklist
• References

Agile the physics vs Agile the bureaucracy

The Agile Manifesto values working software over comprehensive documentation and emphasizes collaboration and responding to change. [1] One of its principles states that working software is the primary measure of progress. [2]

Those ideas are still correct.

What broke in enterprises is implementation:

• Agile became process instead of feedback
• agile artifacts became deliverables
• teams were optimized for predictability theater instead of throughput and learning

In short: Agile got turned into compliance.

Pattern 1: Sprints as contracts

What it looks like

• Sprint planning is treated as a commitment contract.
• Changing scope is seen as failure, even when reality changes.
• Teams avoid surfacing unknowns because unknowns disrupt “commitment.”

Why it happens

Leaders want predictability. Sprints feel like a way to buy it.

The hidden tax

When you turn sprints into contracts, teams adapt:

• reduce exploration
• defer integration
• accept low-quality shortcuts
• split work into artificial “done-looking” chunks

You don’t eliminate uncertainty. You hide it until the end.

The replacement pattern

Use cadence as a heartbeat, not as a contract:

• Plan in small chunks.
• Commit to outcomes and constraints, not a stack of tickets.
• Treat scope as a lever; treat time as a constraint.

Pattern 2: Velocity as a performance metric

What it looks like

• Story points become productivity.
• Velocity is compared across teams.
• Teams feel pressure to “go faster” by increasing points delivered.

Why it happens

Velocity is a number. Numbers are tempting.

The hidden tax

Story points are a local measure with no consistent meaning across teams. When you attach incentives, teams optimize for the metric:

• inflate estimates
• split work to maximize points
• avoid hard, high-leverage work
• ship low-value changes

This is a textbook Goodhart’s Law failure mode: when a measure becomes a target, it ceases to be a good measure. [7]

The replacement pattern

Measure the system, not the story:

• lead time
• cycle time
• deploy frequency
• change failure rate
• MTTR

Use metrics diagnostically, not as quarterly targets.

Pattern 3: Backlog bloat as a museum of anxiety

What it looks like

• Thousands of backlog items exist “for visibility.”
• Nothing gets deleted.
• Refinement happens continuously, but priorities change weekly.

Why it happens

Backlogs feel like control: “We haven’t forgotten.”

The hidden tax

A giant backlog increases planning cost and reduces focus. Teams stop trusting priorities and operate on side-channel requests.

My favorite framing:

If everything is in the backlog, nothing is prioritized. It’s just a museum of anxiety.

The replacement pattern

Adopt a tight horizon model:

• Now: what we’re building
• Next: what’s likely next
• Later: ideas (low-investment capture)

Refine Now/Next. Archive the rest.

Pattern 4: Ceremonies become the work

What it looks like

• Standups become status meetings for managers.
• Planning takes hours.
• Refinement is endless.
• Retrospectives generate action items that never get resourced.

Why it happens

Ceremonies are easy to schedule. Delivery capability is harder to build.

The hidden tax

Attention becomes fragmented. Engineers become “meeting responders.” Work gets multi-tasked across initiatives.

This is how you get:

• slow delivery
• low quality
• burnout

The replacement pattern

Keep only the meetings that reduce uncertainty:

• shorter planning
• true async refinement
• standup for coordination within the team (not reporting)
• retros with real ownership and budget

Then invest in the thing ceremonies can’t replace: engineering capability (tests, pipelines, observability, automation).

Pattern 5: Dependencies turn Scrum into fiction

What it looks like

• Every story depends on another team.
• “Blocked” is normal.
• Integration is deferred to later sprints.

Why it happens

Organizations are siloed. Systems mirror communication structures (Conway’s Law). [8]

The hidden tax

You get scrumfall: waterfall dependencies, sprint-shaped reporting.

A two-week sprint can’t save a three-month dependency queue.

The replacement pattern

Design for end-to-end ownership and flow:

• reduce handoffs
• remove or automate cross-team gates
• create platform paved roads so teams can self-serve [9]

When dependencies can’t be eliminated, make them explicit and manage them like risk, not like hope.

Pattern 6: Definition of done without production

What it looks like

• “Done” means “merged.”
• QA is a phase.
• Observability is optional.
• Releases happen “later.”

Why it happens

Shipping is painful. So teams avoid it.

The hidden tax

If “done” doesn’t include production, you accumulate:

• integration debt
• release debt
• incident debt

Reliability declines because feedback arrives late.

Continuous delivery’s core argument is that keeping software deployable and releasing frequently reduces risk and enables faster feedback. [4]

The replacement pattern

Upgrade your definition of done:

• deployed to a real environment
• observable (metrics/logs/traces)
• rollback path exists
• runbook exists for major failure modes

Pattern 7: Product ownership by proxy

What it looks like

• Engineers rarely talk to users/operators.
• “Product” is a chain of intermediaries.
• Requirements arrive as polished tickets without the “why.”

Why it happens

The organization tries to protect engineers from churn.

The hidden tax

This degrades the input signal. Engineers build the wrong thing efficiently - and then everyone is surprised it didn’t land.

The replacement pattern

Bring engineers closer to reality:

• listen to customer calls
• review usage telemetry
• participate in discovery
• keep the “why” attached to every build

No one should ship something they can’t explain.

What’s better: Flow + CD + evidence

If Agile compliance is the disease, what’s the cure?

It’s not “a different framework.” It’s an operating model:

1) Flow: small batches, limited WIP

Lean/Kanban concepts focus on limiting work in progress and optimizing for flow. [3]

• Finish work, don’t start work.
• Reduce batch size.
• Make queues visible.

2) Continuous Delivery: make change safe

Continuous delivery is a capability: keep changes small, deployable, and observable so you can release frequently with lower risk. [4]

This includes:

• CI
• automated testing
• progressive delivery (when needed)
• rollback/roll-forward discipline
• telemetry tied to releases

3) Evidence-based planning: bets, not contracts

Lean Startup’s build-measure-learn loop emphasizes validated learning - ship something real, measure, and adjust. [5]

For enterprises, the translation is simple:

• Plan in small bets
• Validate early
• Use evidence to re-plan, not politics

Transition plan: 30 days without a revolution

You don’t need to burn the framework down. You need to change what you reward and what you ship.

Week 1: Make work visible as flow

• Map the value stream from idea -> production.
• Count handoffs.
• Measure current lead time.

Week 2: Reduce batch size

• Pick one initiative.
• Cut it to a thin vertical slice that can ship.
• Define “done” as “in production, measurable.”

Week 3: Reduce WIP

• Stop starting new work.
• Finish the slice.
• Remove one blocking dependency with a paved path or automation.

Week 4: Close the feedback loop

• Ship.
• Measure.
• Run a retro focused on system constraints (not blame).
• Repeat.

If you do this and nothing improves, you learned something valuable: the constraint is elsewhere.

Verification: how you know it’s working

You should see movement in system outcomes:

DORA describes four key delivery performance metrics: lead time for changes, deployment frequency, change failure rate, and time to restore service. [6]

Signs of real improvement:

• lead time drops (less queueing and fewer handoffs)
• deploy frequency rises (smaller batches, calmer releases)
• change failure rate drops (better tests and safer rollouts)
• MTTR drops (better observability and operability)

And importantly: teams report less “deployment pain” and less burnout as delivery becomes calmer and more reliable. [10]

A practical checklist

If you’re stuck in Agile theater, try this:

Stop measuring activity

• Stop comparing velocity across teams.
• Stop treating story points as productivity.

Shrink feedback loops

• Ship a thin slice to production early (behind a flag if needed).
• Put engineers closer to users/operators.

Reduce handoffs and WIP

• Limit concurrent initiatives.
• Remove one handoff per quarter.

Invest in delivery capability

• CI, tests, deployment automation
• observability tied to releases
• safer rollouts and rollback paths

Use metrics as signals, not targets

• Track DORA metrics at the system level. [6]
• Avoid metric gaming (Goodhart). [7]

References

[1] Manifesto for Agile Software Development (values). https://agilemanifesto.org/ [2] Principles behind the Agile Manifesto (“Working software is the primary measure of progress”). https://agilemanifesto.org/principles.html [3] Kanban Guide (principles and practices oriented around flow and WIP). https://kanbanguides.org/english/ [4] Continuous Delivery (concepts; keep software deployable, release frequently). https://continuousdelivery.com/ [5] The Lean Startup - Principles (Build-Measure-Learn; validated learning). https://theleanstartup.com/principles [6] DORA - “DORA’s software delivery performance metrics (guide)”. https://dora.dev/guides/dora-metrics/ [7] CNA - “Goodhart’s Law” (when a measure becomes a target, it ceases to be a good measure). https://www.cna.org/analyses/2022/09/goodharts-law [8] Splunk - “Conway’s Law Explained” (systems mirror communication structures; includes original quote). https://www.splunk.com/en_us/blog/learn/conways-law.html [9] Microsoft Engineering Blog - “Building paved paths: the journey to platform engineering”. https://devblogs.microsoft.com/engineering-at-microsoft/building-paved-paths-the-journey-to-platform-engineering/ [10] DORA - “Capabilities: Well-being” (deployment pain and relationship to performance/culture). https://dora.dev/capabilities/well-being/