How Agile Goes Wrong

Agile fails more often than it succeeds in the wild — not because the ideas are bad, but because organizations adopt the vocabulary and keep the old habits. The failure modes have names.

Cargo-cult agile

Doing the ceremonies — standups, sprints, retros, Jira boards — without the thinking behind them. The team holds a daily standup where everyone reports status to a manager. Sprints are just two-week deadlines. Retros produce action items nobody does. It looks like agile from a distance, which is exactly the problem: the resemblance replaces the substance.

Test: ask "what did we change because of our last retro?" If the answer is nothing, three retros running, you have cargo-cult agile.

Scrum-but

"We do Scrum, but we don't do retros / but the Product Owner is a committee / but sprints are really just deadlines." Every but removes a load-bearing wall. Some adaptations are legitimate; most are the old command structure reasserting itself in agile clothing.

Velocity as a performance metric

Management discovers velocity, then weaponizes it: "Team A does 40 points, why does Team B do 25?" Points inflate overnight. Estimation becomes negotiation theater. The number that was useful for forecasting becomes useless for everything, because Goodhart's law eats metrics for breakfast: when a measure becomes a target, it ceases to be a good measure.

Agile as micromanagement theater

The daily scrum becomes a daily status interrogation. The board becomes surveillance — "why has that ticket been in progress for two days?" Burndown charts become tools for asking why the line isn't steeper. All the transparency agile creates gets aimed downward at the team instead of outward at the work. Developers learn to game the visibility instead of doing the work.

The Agile Industrial Complex

Certifications, coaches, consultants, and frameworks sold as the thing itself. A two-day Certified ScrumMaster course does not make someone able to run a team, and an organization that buys SAFe hoping process will substitute for trust will get neither. Process can't fix a lack of trust or unclear authority — it can only make the dysfunction more legible.

"Agile" as an excuse for chaos

The opposite failure: "we're agile, so we don't plan, don't document, don't estimate." That's not agile; that's abdication. The manifesto values responding to change — which requires knowing what the plan was, so you can tell you've deviated from it.

The common root

Nearly every failure mode is the same story: the organization wanted the benefits of agile (faster delivery, happier customers) without the costs (giving teams real authority, accepting uncertainty in forecasts, managers becoming servant-leaders instead of directors). Agile requires trust to work, and you can't install trust with a framework.