"We just spent $300-$400 talking about jack s***."
That's a retrospective consultant, after facilitating a two-hour session. Frame that quote.
Not because retrospectives are worthless—they're not. But because it captures what developers already know: something is broken about how we do retrospectives.
The Pattern
Sprint 1: "Our CI pipeline is slow."
Sprint 2: "The CI pipeline is still slow. Nothing happened."
Sprint 3: "Can we escalate?"
Sprint 4: Nobody mentions the CI pipeline.
I've watched this pattern dozens of times. Different companies, industries, team sizes. The specific issue changes but the trajectory is identical.
Organizational Immunity
When a team identifies a problem, it falls into two categories:
Category 1: Team-solvable. Communication patterns, code review practices, internal processes.
Category 2: Organizationally-dependent. Budget, headcount, infrastructure, cross-team processes.
The uncomfortable math: 70-80% of meaningful problems fall into Category 2. And Category 2 triggers organizational immunity—mechanisms that neutralize threats to existing power structures.
The Facilitation Fallacy
The Agile industry says dysfunctional retrospectives mean you're facilitating wrong. Try the sailboat format. Try roses and thorns.
I've tried them all. I've facilitated retrospectives dressed as a pirate.
Facilitation techniques can marginally improve engagement. But they cannot give teams authority to solve problems they don't have authority to solve.
Blaming facilitation is like blaming the suggestion box for management not reading the suggestions.
What Actually Works
Categorize by locus of control. Green (team can resolve), Yellow (team can influence), Red (no control).
Focus time on green issues. These are the only ones where action items have realistic chances.
Document red issues, don't relitigate them. Maintain an Organizational Impediments Log. Acknowledge, point to it, move on.
Escalate strategically. Quantify impact. Propose solutions with costs. Set deadlines.
Accept some problems won't be solved. Some organizational problems are features, not bugs, from leadership's perspective.
The Uncomfortable Truth
Retrospectives were designed for team-level improvements in team-controlled contexts. Not as mechanisms for organizational change.
We told developers Agile would empower them. Gave them ceremonies that invited them to surface problems. Then embedded these "empowered" teams in traditional hierarchies where budget, staffing, and strategy get decided three levels above them.
The retrospective became a pressure valve. Appearance of voice without substance of power.
Senior developers stay quiet. They've learned. Their silence isn't apathy. It's adaptation.
Originally published at agilelie.com
Top comments (0)