How to run a retrospective for a team of three to eight people
Retrospectives come from agile software teams, where they happen at the end of every sprint. Many small teams outside software have heard of them, tried one, and found it awkward: forty sticky notes, an hour of discussion, and nothing different the following week.
The idea is still good. A small team that pauses every few weeks to ask "how is our way of working going?" improves faster than one that never does. It just needs a lighter format.
Keep it to 30 minutes
For a team of three to eight people, 30 minutes is enough. Longer retros produce more notes, not more change. Run one every two to four weeks, or at the end of a project.
Use three questions
There are dozens of retro formats with clever names. For small teams, three plain questions work:
- What helped us this period?
- What got in the way?
- What is one thing we will try differently?
Give everyone five minutes to write answers privately before anyone speaks. That stops the loudest person from setting the agenda.
Look at the board, not just feelings
Opinions are useful, but they drift. Bring the actual board into the conversation:
- Where did work wait the longest?
- Which projects had nothing moving for a week?
- Did anything sit in Other because nobody chased it?
On a 2D board, these patterns are visible at a glance: a crowded Other column, a row with an empty Mine, actions that keep moving back from Done. See the easiest way to see blocked work.
Pick one or two changes
The output of a retro is not a list of observations. It is one or two specific experiments:
- "We will chase anything in Other on Tuesdays and Fridays."
- "Every new project row gets a first action before it goes on the board."
- "Client approvals go in Other with the client's name."
Write them down where you will see them, and check them at the next retro.
Make it safe to be honest
Retros only work if people can say what is not working without it becoming personal. Some ground rules help:
- Talk about the process, not individuals
- The facilitator speaks last
- Nothing said in the retro is used against anyone
Google's Project Aristotle research on team effectiveness found psychological safety to be the most important factor in high-performing teams, as described on Google's re:Work site. A retro is one of the few regular moments where that safety is tested.
Rotate the facilitator
The same person running every retro shapes every outcome. Rotate it. The facilitator keeps time, makes sure everyone speaks and writes down the agreed changes.
When to skip it
If nothing has changed since the last retro and the team is in the middle of a crunch, a skipped retro is fine. A retro that happens on schedule but changes nothing is worse than none, because it teaches the team that talking about problems is pointless.
Where it fits
Retros pair naturally with a weekly review: the weekly review keeps work moving, the retro improves how the team works. See weekly project reviews on one board and build a work system people use.