Retrospective

The retrospective is agile's built-in improvement loop: a recurring, protected meeting where the team examines how it works and commits to specific changes. Small word for what may be the highest-return hour in engineering — the mechanism by which a team gets better at getting better.

What It Is

A retrospective (retro) closes each sprint: the team reviews what went well, what went wrong, and what to change, then commits to a small number of concrete improvements for the next cycle. Formats vary (start-stop-continue, 4Ls, blameless postmortems for incidents), but the operative disciplines are constant: psychological safety (the goal is fixing systems, not assigning blame — 'blameless' is the explicit norm), specificity (actions with owners, reviewed next time), and cadence (the loop must actually run every cycle to compound). The same ceremony at larger scale — release retrospectives, incident postmortems — serves whole programmes.

Why It Matters to You

For executives, the retrospective is the leading indicator of engineering health. Teams that run honest retros improve relentlessly; teams that skip them or paper them over repeat every mistake they make, at interest. Two signals worth acting on: retro actions that recur unchanged cycle after cycle (organisational blockers the team cannot fix alone — your queue), and retros that go quiet under delivery pressure (the improvement loop is the first thing sacrificed and the last thing that should be). Vendors who share their retro practice are showing you how they learn; vendors who have none are showing you they don't.

When You'll Meet It

In team health reviews, programme governance, and incident follow-ups. The one question: 'what did the last retro change?' — an answer with specifics means the loop is alive.