Retrospective

Why It Matters

Teams that do not reflect do not improve. They repeat the same patterns, hit the same friction points, and rely on individual heroics rather than system-level fixes. A retrospective creates a dedicated space for the team to examine its own processes, identify what is working and what is not, and commit to specific changes. Without this practice, improvement is accidental rather than intentional.

How It Works

A typical retrospective follows a simple structure: what went well (practices to continue), what did not go well (problems to address), and what will we change (specific commitments for the next cycle). The format originated in agile software development (where it is called a "sprint retrospective") but the principle applies to any team operating on a recurring cadence. The key constraint is that it must produce action items, not just discussion.

What Makes One Effective

Effective retrospectives share three properties. First, psychological safety: people must feel comfortable raising problems without fear of blame. Second, specificity: "communication could be better" is not actionable, while "status updates should include blockers, not just progress" is. Third, follow-through: the team reviews previous action items at the start of each retrospective to verify that commitments were honored. A retrospective without follow-through trains the team that nothing changes.

• Hold retrospectives on a fixed cadence (weekly, biweekly, or per sprint), not just after failures
• Limit action items to two or three concrete changes per session
• Open each session by reviewing commitments from the previous retrospective
• Rotate the facilitator role to prevent one person from dominating the conversation
• Focus on systems and processes, not individual performance

The Connection to Double-Loop Learning

Most operational reviews are single-loop: did we hit the target? Retrospectives at their best are double-loop: are we pursuing the right targets with the right methods? This distinction matters because single-loop learning optimizes within existing assumptions, while double-loop learning questions the assumptions themselves. A team that only asks "did we finish on time?" misses the deeper question of whether they are working on the right things in the right way.