The same problems come up in every retrospective. What's likely wrong?

Too many vague actions without owners, measures or follow-up. Pick one or two changes, assign owners, define how you'll measure the effect and review them at the start of the next retro.

What is the Retrospective Prime Directive and why read it?

Norm Kerth's statement that everyone did the best job they could given what they knew at the time. It sets a blameless tone so people can discuss problems honestly.

How do you make sure quieter team members contribute in a retro?

Start with silent individual writing before discussion, use dot voting, and rotate facilitators — so ideas are collected before the loudest voices shape the conversation.

Retrospectives That Change Things — The Team Lead Handbook

Scenario

Example team: the checkout team's retros follow "what went well / what went badly / actions". Every two weeks the same items appear: "too many meetings", "flaky tests", "unclear requirements". Actions are written down and forgotten. Attendance drops.

What you see on the team

The same problems raised retro after retro.
Long lists of actions with no owners.
A few voices dominate; quieter people stay silent.
People see retros as a ritual rather than a tool.

The common mistake

Running retros as a complaint session with many vague actions instead of a focused improvement experiment with one or two owned changes.

Why it happens

Collecting problems is easy; changing things is hard. Lists of ten actions spread effort thin, and without follow-up nobody notices they weren't done. The Retrospective Prime Directive, written by Norm Kerth, sets the tone that makes honest discussion possible: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time..."

The playbook

Structure (60 minutes for a two-week cycle):

Set the stage (5 min) — read the Prime Directive; check last retro's actions: done or not, and did they help?
Gather data (15 min) — silent writing first (so everyone contributes), then group. Bring data: flow metrics, incidents, planned vs done.
Generate insights (15 min) — dot-vote the top theme; ask "why?" a few times.
Decide what to do (15 min) — pick one or two changes, each with an owner, a measurable result and a check date.
Close (5 min) — quick feedback on the retro itself.

Vary the format every few sessions (timeline, sailboat, start/stop/continue) to keep it fresh. Atlassian's Retrospective play has ready-made formats.

Treat actions as experiments: "For two sprints we'll try a WIP limit of six; we'll check cycle time at the next retro."

Escalate what the team can't change — and report back on what happened, so people see the retro reach beyond the team.

What to say

Opening:

"Before we start: last time we agreed to try review slots twice a day. Median review wait went from 20 to 5 hours. Let's keep it. Now — silent writing for five minutes: what helped and what got in the way this sprint?"

Closing on actions:

"We have eight ideas. Let's pick one, maybe two. Who owns it, what will we measure, and when do we check?"

Trade-offs

Fewer actions feel less ambitious but actually get done.
Data-driven retros can feel clinical; balance metrics with how people felt.
The lead's presence can inhibit honesty; occasionally let someone else facilitate or step out for part of it.

Signals it's working

Actions from last retro are reviewed and mostly done.
Recurring complaints disappear from the board over time.
Everyone contributes, not only the loudest voices.
People suggest topics for the retro between sessions.

Key points

Start with the Prime Directive and last retro's actions.
Silent writing first, then group and vote, bringing data.
Pick one or two changes with owners, measures and a check date; treat them as experiments.
Escalate what the team can't change, and report back.