2.3 Anti-Patterns in Accountabilities
Key Takeaways
Accountability anti-patterns undermine psychological safety, disguise systemic bottlenecks, and transform empirical Scrum into ceremonial command-and-control.
The Scrum Master acting as a project manager or taskmaster induces learned helplessness, destroys developer self-management, and degrades the Daily Scrum into a status update.
Proxy Product Owners lack authentic fiscal and scope decision mandate, causing crippling decision latency, diluted product vision, and feature-factory churn.
Intra-sprint mini-waterfalls—sequencing analysis, coding, and testing across the Sprint timebox—back-load risk, subvert collective ownership, and compromise the Definition of Done.
Advanced Scrum Masters resolve anti-patterns not through superficial enforcement, but by acting as organizational change agents who make delay costs and quality risks transparent to leadership.
2.3 Anti-Patterns in Accountabilities
When organizations undergo agile transformations, they rarely abandon their historical hierarchies and cultural habits overnight. Instead, traditional management reflexes, risk aversion, and functional silos frequently co-opt Scrum terminology, producing subtle yet destructive accountability anti-patterns. These anti-patterns preserve the illusion of agile adoption while reinforcing command-and-control behavior, eroding psychological safety, and severing empirical feedback loops.
An advanced Scrum Master (PSM II) must possess the diagnostic acuity to identify these systemic dysfunctions beneath their superficial symptoms and deploy nuanced, long-term coaching interventions to realign the organization with true Scrum principles.
Anti-Pattern 1: The Scrum Master as Project Manager or Taskmaster
Observable Symptoms
- The Scrum Master leads the Daily Scrum like an interrogation, asking each developer: "What did you do yesterday? What are you doing today? Are you on schedule?"
- Team members direct their updates to the Scrum Master rather than talking to each other.
- The Scrum Master assigns tasks to Developers, estimates story points, updates burndown charts on behalf of the team, and manages Jira tickets.
- Individual developers are held accountable by the Scrum Master for task-level hour estimates.
Systemic Consequences
This anti-pattern completely dismantles developer self-management. When the Scrum Master acts as an administrative overseer, Developers disengage their proactive problem-solving faculties and adopt a posture of passive compliance. If a roadblock arises, they wait for the Scrum Master to assign them a workaround. Furthermore, if the Scrum Master is absent, the Daily Scrum either collapses or devolves into awkward silence because the team lacks peer accountability.
Diagnostic & Coaching Intervention
- Step Back and Silence: During the Daily Scrum, the Scrum Master physically or virtually steps outside the circle, refraining from speaking or making eye contact. If Developers look to the Scrum Master, the Scrum Master redirects their gaze toward the Sprint Backlog board and their peers.
- Hold Up the Mirror in Retrospectives: The Scrum Master brings objective data to the Retrospective: "I noticed that during the last two Sprints, all board transitions were executed by me, and 80% of Daily Scrum comments were directed at me. What impact is this having on our collective ownership?"
- Transition Board Ownership: The Scrum Master ceases updating tasks or managing workflow tools, making it clear that the Sprint Backlog is owned exclusively by the Developers.
Anti-Pattern 2: The Proxy Product Owner
Observable Symptoms
- The named Product Owner cannot make definitive decisions during Sprint Planning, refinement, or Sprint Reviews without consulting an external steering committee, department head, or executive sponsor.
- Frequent scope churn mid-Sprint because an external executive rejects the work prioritized by the Product Owner.
- The Product Owner answers developer questions with: "I will check with the business and get back to you next week."
- Backlog items represent a raw aggregation of stakeholder wish-lists without unified strategic vision or cohesive Product Goal alignment.
Systemic Consequences
The Proxy Product Owner is an administrative buffer rather than a value optimizer. This structure creates crippling decision latency. In complex product environments, Developers require rapid, contextual trade-offs to keep work flowing. When decisions take days or weeks to navigate corporate approval layers, developer velocity plummets, work-in-progress (WIP) explodes, and the resulting Increment fails to reflect coherent value.
Diagnostic & Coaching Intervention
- Quantify Decision Latency and Delay Costs: The Scrum Master tracks the cycle time of product decisions—from the moment a clarification is raised until an authoritative response is received—and models the economic cost of delay (e.g., idle developer hours, context switching, blocked features, and lost market opportunities), using the organization's own numbers rather than generic estimates.
- Executive Coaching on Empirical Governance: The Scrum Master works directly with executive leadership, explaining that true agility requires delegating fiscal and product authority to a single empowered Product Owner. The Scrum Master presents leadership with a clear choice: either grant the current Product Owner full decision-making mandate, or have the actual decision-maker step into the Product Owner accountability directly.
Anti-Pattern 3: Committee or Distributed Product Ownership
Observable Symptoms
- The organization assigns a "Product Ownership Committee" or multiple co-Product Owners to a single product.
- Backlog refinement sessions become battlegrounds of political horse-trading, where stakeholders compromise by including a little bit of everyone's pet features.
- The Product Backlog lacks a clear ordering; instead, hundreds of items are marked as "High Priority" or "Urgent."
- Developers receive conflicting instructions from different business sponsors, resulting in conflicting code implementations.
Systemic Consequences
When product ownership is distributed across a committee, nobody is truly accountable for product value. Decisions stall in endless consensus-building cycles. The resulting product becomes a bloated, fragmented "feature factory" that attempts to satisfy every internal stakeholder while delivering negligible cohesive value to actual end users.
Diagnostic & Coaching Intervention
- Reinforce the Scrum Guide Mandate: The Scrum Master reminds leadership and stakeholders of the core rule: the Product Owner is one person, not a committee.
- Establish Stakeholder Governance Channels: The Scrum Master helps the Product Owner design structured forums (such as regular Product Backlog refinement workshops and collaborative Sprint Reviews) where stakeholders can voice their perspectives, review empirical market feedback, and provide input. However, the Scrum Master coaches stakeholders that the Product Owner retains the ultimate, unquestioned authority on final ordering.
Anti-Pattern 4: The Intra-Sprint Mini-Waterfall
Observable Symptoms
- Developers spend Days 1 through 6 of a two-week Sprint purely writing code, without executing integration or end-to-end tests.
- On Day 7 or 8, code is "thrown over the wall" to dedicated QA testers on the team.
- Testers are completely overwhelmed during the final 48 hours of the Sprint, logging defects that cannot possibly be resolved before the Sprint Review.
- Backlog items routinely carry over to the subsequent Sprint for "testing and bug-fixing," or the team requests separate "Hardening Sprints."
Systemic Consequences
The mini-waterfall inside the Sprint timebox completely negates empiricism. Risk is back-loaded to the very end of the Sprint, precisely when there is zero time left to inspect and adapt. If testing fails on Day 9, the entire Sprint Goal is compromised. Furthermore, this dynamic perpetuates an adversarial "us versus them" mentality between programmers and testers, directly violating collective accountability and the Definition of Done.
| Pattern | Days 1–3 | Days 4–7 | Days 8–10 | Outcome |
|---|---|---|---|---|
| Mini-waterfall (anti-pattern) | Analysis and design; testers idle | Coding; testers idle | Testing and panic; testers overwhelmed | Carryover, hidden defects, no usable Increment |
| Healthy flow (vertical slices) | Story A designed, coded, tested, Done | Story B Done; Story C in progress | Story C Done | Usable value accumulates throughout the Sprint |
Diagnostic & Coaching Intervention
- Promote Vertical Story Slicing: The Scrum Master coaches the Product Owner and Developers to slice large requirements into thin, end-to-end vertical slices that deliver a tiny slice of real functionality across all layers (UI, logic, database, test) within 1 to 2 days.
- Introduce Swarming and Test-First Practices: The Scrum Master encourages Developers to pair and swarm on one or two stories at a time, limiting work-in-progress (WIP). Programmers and quality specialists collaborate from Day 1, defining automated acceptance tests before and during code implementation, ensuring continuous integration and immediate verification.
Anti-Pattern 5: The Rescuing Scrum Master and Learned Helplessness
Observable Symptoms
- The Scrum Master handles all administrative overhead: booking conference rooms, updating calendars, configuring board filters, ordering team snacks, and resolving every interpersonal friction.
- If two Developers disagree on an API design, they run to the Scrum Master to mediate.
- When an external team fails to deliver an API dependency, the Scrum Master immediately assumes personal responsibility for chasing down the external team's manager.
Systemic Consequences
While the Scrum Master believes they are "servant leading" by clearing paths, they are actually fostering learned helplessness. The team remains infantilized and fragile, incapable of navigating healthy conflict or asserting itself within the organization. When the Scrum Master is on vacation or leaves the organization, the team's ability to operate independently completely collapses.
Diagnostic & Coaching Intervention
- Embrace Productive Discomfort: The Scrum Master exercises deliberate restraint, resisting the reflex to fix every discomfort immediately. Allowing the team to feel the productive friction of an unresolved challenge motivates them to collaborate and formulate internal coping mechanisms.
- Coach Peer-to-Peer Resolution: When a developer complains to the Scrum Master about a teammate's code quality or behavior, the Scrum Master asks: "Have you shared this feedback directly with them? How can I support you in having that conversation safely?"
- Empower Team Dependency Management: Instead of acting as an administrative courier between teams, the Scrum Master facilitates direct, engineer-to-engineer communication channels between interdependent teams.
Summary Diagnostic Matrix
| Anti-Pattern | Primary Indicator | Underlying Root Cause | Strategic SM Intervention |
|---|---|---|---|
| Taskmaster SM | Daily Scrum is a status report directed to SM | Management muscle memory; lack of trust in developer self-management | Step back; maintain silence; hold up mirror in Retrospectives; transition board ownership |
| Proxy PO | PO must ask permission from executive sponsors | Fear of delegating fiscal authority; risk aversion in leadership | Measure and visualize decision latency; coach executives on cost of delay; demand empowerment |
| Committee PO | Conflicting priorities; bloated backlog; endless debate | Political diffusion of responsibility; inability to make trade-offs | Reinforce one-person rule; structure stakeholder advisory channels while upholding PO final say |
| Mini-Waterfall | Testers swamped on last days; defects carried over | Horizontal component thinking; large horizontal batch sizes | Coach vertical slicing; implement swarming and pair programming; embed test automation |
| Rescuing SM | Team paralyzed when SM is absent; cannot resolve conflict | Hero complex; confusing service with administrative servitude | Embrace productive struggle; coach peer feedback; guide team to resolve own technical impediments |
An organization assigns a junior business analyst as the 'Product Owner' for a mission-critical logistics platform. However, the analyst has no decision-making mandate; every Product Backlog refinement question, release decision, or scope adjustment must be formally approved by an executive steering committee that meets every three weeks. Consequently, Developers are repeatedly blocked and forced to context-switch between half-finished tasks. How should the Scrum Master address this anti-pattern?
Gather data on decision latency and its cost, then coach leaders to empower the Product Owner fully or have the real decision-maker take the role.
Instruct the Developers to pause all work and remain idle whenever a decision is pending until the executive steering committee holds its tri-weekly meeting, so that no rework is created.
Encourage the junior business analyst to secretly make unilateral product decisions without consulting the executive committee to keep the development workflow moving.
Assume the accountability of co-Product Owner alongside the analyst, using the Scrum Master's organizational standing to approve backlog items without waiting for executive oversight.
In an organization running two-week Sprints, a Scrum Team consistently exhibits a mini-waterfall pattern: Developers spend the first seven days writing code, and then transfer the batch of completed items to two QA specialists on Day 8. Inevitably, the QA specialists are overwhelmed, numerous critical defects are uncovered on Day 10, and multiple unfinished stories must be carried over into the next Sprint. The team proposes creating alternate 'Development Sprints' and 'Testing Sprints' to solve the crunch. How should the Scrum Master guide the team?
Approve alternating Development and Testing Sprints so both specialities can work at a sustainable pace.
Direct the QA specialists to work overtime during the final weekend of every Sprint to clear the accumulated testing backlog before the Sprint Review.
Recommend that the team eliminate testing from the Definition of Done and instead deploy untested code directly to production to gather user telemetry.
Reject phased Sprints, and coach the team to slice items into thin vertical slices while adopting swarming, pair programming, and automated testing throughout the Sprint.
During the Daily Scrum, the Scrum Master observes that the Developers stand in a line facing the Scrum Master. Each developer sequentially recites their completed tasks, current tasks, and hours logged while looking directly at the Scrum Master. Team members do not interact with one another, and when one developer mentions a critical blocker, no one responds. How should the Scrum Master intervene to correct this behavior?
Require each developer to submit a detailed written status report before the Daily Scrum so the Scrum Master can run the meeting more efficiently and spot blockers sooner.
Step out of the circle, stay quiet, and coach that the Daily Scrum is the Developers' event for replanning toward the Sprint Goal.
Cancel the Daily Scrum entirely and replace it with an automated daily chat notification in the team's messaging platform.
Intervene immediately during the meeting to assign the mentioned blocker to another developer and establish new deadlines for the affected tasks so the critical issue cannot be ignored again.
Sections you finish are checked off in the contents.