The Anti-Pattern Library: 10 Agile Dysfunctions and How to Coach Through Them
Every experienced agile coach develops an internal library of dysfunctions — the recurring patterns of broken practice that appear in team after team, organization after organization, regardless of industry or company size. The details vary, but the shapes are remarkably consistent. You walk into a new engagement and recognize within the first sprint that this team has the Ceremony Theater anti-pattern, or the Solo Decision-Maker, or the Backlog as Wish List. The recognition is useful because it compresses the diagnostic process. You do not need to re-derive from first principles what is wrong. You need to match the pattern and apply the coaching intervention you already know works.
This post catalogs ten of the most common agile anti-patterns, drawn from coaching practice and from the organizational dynamics that Lean UX literature identifies as the primary barriers to effective product team operation. Each pattern description includes the observable symptoms, the root cause, and the coaching approach that addresses it — not with a silver-bullet fix, but with the first set of interventions that typically creates enough movement to start a genuine change process.
Pattern recognition accelerates coaching: identifying the dysfunction type points directly to the intervention
Anti-Patterns 1–4: Process Dysfunction
Anti-Pattern 1: Zombie Scrum. The team runs all the ceremonies — sprint planning, standup, review, retrospective — but the ceremonies produce no genuine learning or adaptation. Stories are completed, velocity is reported, and the product continues to drift from user needs without anyone treating this as a problem. The root cause is almost always that retrospective action items are never implemented, which teaches the team that the retrospective is performative. The intervention is to open every retrospective by reviewing the action items from the previous one and asking what happened to each.
Anti-Pattern 2: Ceremony Theater. The team treats ceremonies as compliance checkboxes rather than as collaborative tools. Sprint planning takes forty-five minutes regardless of complexity. Retrospectives cover identical themes sprint after sprint. The root cause is that the team does not believe the ceremonies serve a real purpose. The intervention is to redesign one ceremony at a time with the team's explicit input, making the value of that ceremony visible before moving to the next.
Anti-Pattern 3: The Perpetual Backlog. The backlog has hundreds of items spanning multiple years, is never prioritized with sufficient discipline to have a clear top ten, and grows faster than it is consumed. Product managers treat it as a commitment ledger rather than a hypothesis list. The root cause is that items are never removed — everything added to the backlog is implicitly promised. The Lean UX intervention is to reframe the backlog as a living assumption list: each item is a hypothesis about value that either gets tested and proven, or gets discarded.
Anti-Pattern 4: The Discovery Desert. Engineering capacity is fully committed to delivery, leaving no time for user research, prototype testing, or assumption validation. Teams build based on requirements documents and stakeholder input, discovering usability problems and product-market fit issues only after features are live. The intervention is to carve out a consistent research cadence — even four hours per sprint — as a non-negotiable team investment.
Retrospectives that never produce implemented action items teach teams that reflection is performative.
Anti-Patterns 5–8: Collaboration Dysfunction
Anti-Pattern 5: The Solo Decision-Maker. One person — usually a strong product manager or a HiPPO (Highest Paid Person's Opinion) — makes all significant product decisions unilaterally. The team delivers on instructions rather than contributing to shared problem-solving. The root cause is a combination of hierarchical culture and a team that has learned that contributing ideas is not worth the political cost. The intervention is to create low-stakes collaborative exercises — design studios, assumption mapping sessions — where team input demonstrably shapes outcomes, building the team's confidence that participation matters.
Anti-Pattern 6: The Siloed Designer. The designer works ahead of the team, producing detailed specifications in isolation, and hands them over for implementation. The team has no understanding of the design rationale and therefore cannot make intelligent tradeoffs when implementation constraints arise. The Lean UX intervention is to involve engineers in design sketching sessions from the beginning — not to have them design, but to have them co-create, so that implementation constraints inform design intent before specifications are finalized.
Anti-Pattern 7: The Absent Stakeholder. Key business stakeholders are invited to sprint reviews but attend inconsistently, provide feedback asynchronously after the fact, or delegate review to a proxy who lacks decision-making authority. The team ships work that stakeholders have not genuinely engaged with, then absorbs rework requests after release. The intervention is to restructure the sprint review into a participatory working session rather than a demonstration — stakeholders who engage with a prototype rather than watch a demo tend to provide richer, more actionable feedback and feel more invested in the outcome.
Anti-Pattern 8: The QA Bottleneck. Quality assurance happens at the end of the sprint, performed by a separate team that the engineers treat as a gate rather than a collaborator. Bugs discovered late require expensive context-switching to fix. The intervention is to move QA participation into the story-writing and sprint planning process, so that acceptance criteria are co-authored and testing approaches are designed before a single line of code is written.
Anti-Patterns 9–10: Culture Dysfunction
Anti-Pattern 9: The Fear of Failure. The team treats failed experiments and missed sprint goals as performance failures rather than learning opportunities, and consequently avoids any commitment that involves genuine uncertainty. Innovation atrophies because no one will propose an experiment they might not win. The root cause is usually a management culture that rewards predictability over learning. The coaching intervention — which requires organizational support to be sustainable — is to create an explicit learning culture artifact: a 'failure log' that celebrates the lessons extracted from failed experiments, making visible that the organization values learning as an output, not just delivery.
Anti-Pattern 10: Agile in Name Only. The organization has adopted agile terminology and ceremonies but has not changed the underlying decision-making structures, funding models, or governance processes. Teams run sprints but receive annual budgets tied to project-level commitments. They hold retrospectives but have no authority to change the processes they are reflecting on. They commit to sprint goals but are interrupted mid-sprint by executive priority changes. This is the deepest and most common dysfunction, and it cannot be coached away at the team level. It requires organizational change that starts with leadership. The agile coach's role in this pattern is to make the organizational contradictions visible — to name the specific structural misalignment preventing team-level practice from taking hold — and to help leadership understand what changes at their level are prerequisites for agile to function as designed.
The Bottom Line
Anti-pattern recognition is only valuable if it leads to coaching action rather than just diagnosis. The ten patterns described here are starting points, not endpoints. Each requires iterative coaching over multiple sprint cycles, organizational support that team-level coaching alone cannot manufacture, and a team that is willing to be uncomfortable in the service of genuine improvement. The coach's job is to make the dysfunction visible without making the team feel judged by it, and to design the smallest possible intervention that creates enough movement for the team to experience the difference between their current state and a healthier one. From that experience, motivation for deeper change follows.
Related Posts from Sense & Respond Learning
Fixing Broken Standups: How to Run a Daily Sync That Actually Surfaces Blockers
From Story Points to Outcomes: Coaching Teams to Measure What Matters
Dual-Track Agile: Managing Discovery and Delivery in a Single Sprint
Coaching Upward: How to Get Executives to Support Agile Transformation
Further Reading & External Resources
Lean UX — Gothelf & Seiden (O'Reilly) — Foundational reading on integrating UX and agile at team and organizational level
Zombie Scrum Survival Guide — Johannes Schartau et al. — Comprehensive guide to diagnosing and treating Zombie Scrum
An Agile Adoption and Transformation Survival Guide — Michael Sahota — Research-based framework for understanding organizational agile transformation
Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.
Explore the full library at https://www.senseandrespond.co/blog.
