Handling Common Anti-Patterns

"We do Scrum, but..." usually means not really doing Scrum.

Common variants:

• "But we don't have a real Product Owner" (no authority, multiple people)
• "But we can't do 2-week Sprints" (3-month 'Sprints')
• "But we skip retros when busy"
• "But leadership sets the Sprint scope"

Approach:

1. Understand why they're deviating
2. Explain what they're losing
3. Address root causes (often organizational)
4. Experiment with doing it "by the book"

Going through the motions without the spirit. All events happen, but nothing improves.

Symptoms:

• Standups are status reports
• Retros don't lead to change
• Sprint Goals are ignored
• No one talks to stakeholders
• Team doesn't care about outcomes

Treatment:

• Reconnect to purpose: Why are we building this?
• Involve real users/stakeholders
• Make metrics visible and meaningful
• Experiment with formats to reenergize

Scrum in name only, sandwiched between traditional phases.

Pattern:

• Requirements phase (months) → "Scrum" Sprints → QA phase (months)

Why it fails:

• No feedback until the end
• Sprint output isn't truly "done"
• Teams don't own the work end-to-end

Approach:

• Push for cross-functional teams
• Expand Definition of Done to include testing
• Get stakeholder involvement throughout
• Start small—one truly end-to-end slice

Using velocity to measure developer productivity or performance.

Why it's harmful:

• Incentivizes inflating estimates
• Discourages helping teammates
• Ignores value delivered
• Creates fear and hiding

Better approaches:

• Use velocity only for forecasting
• Measure outcomes, not output
• Track value delivered to users
• Focus on team health, not individual metrics