How to run a useful retro on a system
Most retros are venting sessions that change nothing. A good one turns what went wrong into a concrete change in how the system works.
After something breaks or finishes, teams gather to reflect. Too often the retro is cathartic and useless: people air frustrations, nod, and change nothing. A useful retro produces specific changes, not feelings.
Blame the system, not the person
If a retro looks for who to blame, people get defensive and the truth hides. The productive question is what about the system let this happen, and what change would prevent it regardless of who’s involved. Good people in bad systems still produce bad outcomes.
Output is actions, not insights
A retro that ends in 'we should communicate better' has failed. One that ends in 'we’ll add a check at this step, owned by this person, by this date' has succeeded. Every retro should leave behind concrete, owned changes, and the next retro should check whether they happened.
A retro that doesn’t change the system is just a support group. Leave with actions, not feelings.