Common agile and Scrum anti-patterns — a field reference

A team runs sprints, standups, and retros — genuine Scrum mechanics — but the actual planning still happens as a big upfront phase months in advance, and releases still only happen at the end of a long, separately-planned release cycle, regardless of what any individual sprint produced. The sprint cadence is real, but it's wrapped inside a waterfall-shaped planning and release process on both ends, so the actual benefit Scrum is meant to provide — short feedback loops that let the plan change based on what's learned — never materializes. The team is agile in name and ceremony, waterfall in the decisions that actually matter.

The fix: covered in this domain's first lesson — Scrum's mechanics only produce value in service of the manifesto's actual values (responding to change, working software over rigid plans). If sprints exist but nothing about the plan or release timeline is actually allowed to respond to what a sprint reveals, the ceremonies are decorative.

A manager starts comparing teams' or individuals' velocity numbers, or sets a target velocity a team is expected to hit. Every team subjected to this, entirely predictably, starts inflating story-point estimates — not out of dishonesty exactly, but because the metric now has consequences attached to it, and people rationally protect themselves against metrics with consequences. Six months later, "velocity" has doubled with no actual change in what's shipping, and the number has become completely useless for its original purpose: honest sprint forecasting.

The fix: covered in this domain's estimation lesson — velocity is a team's own internal forecasting tool, never a cross-team or individual performance metric. The moment it's used as the latter, it silently stops being usable as the former.

A Scrum Master or manager stands at the front of the daily standup, and each developer reports their progress to that person, one at a time, while the rest of the team is largely disengaged, waiting their own turn. It has the schedule and duration of a standup and none of its actual function — peer-to-peer coordination and blocker-surfacing between the people actually doing the work.

The fix: covered in this domain's standups lesson — redirect the meeting toward the team talking to each other about the Sprint Goal, not reporting upward. If removing the "reporting to a person" framing feels uncomfortable to whoever's used to receiving those reports, that discomfort is diagnostic, not a reason to keep the old pattern.

A Scrum Master runs every ceremony exactly on schedule — Planning, Daily Scrum, Review, Retro, all present, all on time — but never actually intervenes on anything: impediments raised in standup go unaddressed sprint after sprint, retrospective action items are recorded and then never followed up on, dysfunction the team names out loud repeats unchanged for months. The calendar events are real; the actual job (making the team measurably more effective over time) isn't happening.

The fix: covered in this domain's retrospective lesson — the check that separates real reflection from theater is whether last retro's action items were actually revisited at the start of this one. A Scrum Master's value is in what changes as a result of the ceremonies, not in the ceremonies occurring on schedule.

A team adopts a visual board — To Do / In Progress / Done columns — and calls it Kanban, but sets no actual WIP limits, or sets ones so generous they're never actually hit. Everyone has 6–8 things "in progress" simultaneously, constantly context-switching, and the board faithfully visualizes this chaos without doing anything to prevent it, because visualizing overload was never the mechanism that was supposed to fix overload in the first place.

The fix: covered in this domain's Kanban lesson — a WIP limit that's never actually constraining isn't a WIP limit, it's decoration. The discomfort of hitting a real limit (having to help finish something instead of starting something new) is the entire mechanism, not an unfortunate side effect to be tuned away.

An organization adopts "the Spotify model" (or SAFe, or LeSS) by copying the structural artifacts — squad/tribe naming, specific ceremonies, a specific org chart — without the underlying culture, trust, and context that made the source organization's version work. The structure gets implemented faithfully; the actual autonomy, psychological safety, or governance discipline that structure was built to support does not transfer along with the labels.

The fix: covered in this domain's scaling-agile lesson — treat any scaling framework as a specific bet about a specific coordination problem, evaluated against your organization's actual structure and needs, not as a template to copy wholesale because a well-known company was once described as using something like it.

Every one of these anti-patterns has the same underlying shape: a team or organization keeps the visible, easy-to-copy artifact of a practice — the meeting, the metric, the board, the org chart — while losing the actual mechanism that made the practice valuable in the first place. None of them are fixed by adding more process; every one of them is fixed by asking, specifically, what this particular ceremony or artifact was supposed to accomplish, and honestly checking whether it's still accomplishing that — the same question this entire domain keeps returning to, from the very first lesson's distinction between the Agile Manifesto's values and any single framework's mechanics.