Why Do Retrospectives Feel Like a Waste of Time?

Source: Dev.to

“We just spent $300‑$400 talking about jack s***.”
— Retrospective consultant, after facilitating a two‑hour session

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 seen this pattern dozens of times across different companies, industries, and team sizes. The specific issue changes, but the trajectory is identical.

Organizational Immunity

When a team identifies a problem, it usually falls into one of 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 belong to Category 2. These trigger organizational immunity—mechanisms that neutralize threats to existing power structures.

The Facilitation Fallacy

The Agile industry often blames dysfunctional retrospectives on poor facilitation: try the sailboat format, roses and thorns, even a pirate‑themed session. Facilitation techniques can marginally improve engagement, but they cannot give teams authority to solve problems they don’t control.

Blaming facilitation is like blaming a 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, and move on.

• Escalate strategically – quantify impact, propose solutions with costs, and set deadlines.

• Accept some problems won’t be solved – some organizational problems are viewed as features, not bugs, by leadership.

The Uncomfortable Truth

Retrospectives were designed for team‑level improvements in contexts the team controls, not as mechanisms for organizational change. We told developers Agile would empower them, gave them ceremonies to surface problems, and then embedded those “empowered” teams in traditional hierarchies where budget, staffing, and strategy are decided three levels above them.

The retrospective became a pressure valve: the appearance of voice without the substance of power. Senior developers stay quiet—not out of apathy, but as an adaptation to the reality of limited influence.

Originally published at agilelie.com