The retrospective is the team’s primary mechanism for self-improvement. If you could only keep one ritual, this would be the one. Everything else helps the team execute. The retro helps the team get better at executing.
The format is simple: look back at the last iteration, talk about what’s working and what isn’t, and agree on one or two small changes to try next time. That’s it. The value isn’t in the conversation itself. It’s in what changes as a result of the conversation.
When you need this#
- The same problems keep happening and nobody is sure why or how to fix them.
- The team is frustrated but there’s no structured place to talk about it.
- Process changes happen top-down and the people doing the work don’t have a voice in shaping how they work.
- Things went well, but the team can’t articulate why, which means they can’t repeat it intentionally.
Who should be there?#
The team. Engineers, team lead, and optionally product. Rotate the facilitator each session so nobody falls into the habit of “running” the retro. The facilitator’s job is to keep time, make sure everyone speaks, and push the group toward action items. They’re not in charge of the outcomes.
The format#
1. What went well?#
Start positive. What worked this iteration? Did a process change from last retro actually help? Did pairing on a tricky ticket go better than expected? Did the team hit its goal?
This isn’t filler to make people feel good. It’s how the team identifies what to keep doing. If nobody can name anything that went well, that’s a signal worth paying attention to.
2. What didn’t go well?#
This is where the retro earns its keep. What slowed the team down? Where did things get confusing? What was frustrating?
A few ground rules:
Talk about the process, not the people. “Code reviews took too long this iteration” is productive. “Alex takes forever to review PRs” is not. The retro is a safe space for honest feedback about how the team works together. The moment it becomes a place where people get called out, people stop being honest.
Be specific. “Communication could be better” is too vague to act on. “I didn’t know the API contract changed until my tests broke” is something the team can actually fix.
The facilitator should watch for silence. If the same two people are doing all the talking, directly invite others in. “Anything you’d add?” goes a long way.
3. Action items#
This is the only part that matters.
A retrospective without clear action items is just a venting session. Venting might feel cathartic in the moment, but over time it becomes demoralizing. The team raises the same frustrations week after week, nothing changes, and eventually people stop bringing things up because they’ve learned it doesn’t lead anywhere.
Every retro should produce at least one concrete action item with a specific person responsible for it. Not “the team will try to communicate better.” Instead: “Jamie will post API changes in the #eng channel before merging. We’ll check next retro if this helped.”
What makes a good action item?#
Narrow and incremental. The goal is a small adjustment you can try for one iteration and evaluate. Not a process overhaul, not a new tool adoption, not “we should rethink how we do code reviews.” Try “we’ll add a 24-hour SLA for PR reviews this iteration and see if it helps.”
Owned by a person. “We should do X” means nobody does X. “Sarah will do X” means it gets done, and the team can check in on it next retro.
Reversible. The best action items are experiments, not permanent policy changes. If it doesn’t work, you drop it. This makes it safe to try things without the pressure of getting it right the first time.
Checking last iteration’s action items#
Every retro should start by revisiting the action items from last time. Did we do them? Did they help?
This is the accountability loop that makes retros actually work. If the team committed to trying something and nobody followed through, that’s worth discussing. If they followed through and it didn’t help, great, drop it and try something else. Either way, closing the loop proves that the retro leads to real change, which is what keeps people engaged.
Common problems#
The same issue comes up every retro. Either the action items aren’t specific enough, nobody is owning them, or the team is working around a structural problem that small tweaks can’t fix. If something has surfaced three retros in a row, it needs a bigger conversation outside the retro.
People don’t feel safe being honest. This usually means the retro has become a performance review in disguise, or that past feedback led to someone getting blamed. The facilitator needs to actively reinforce that the retro is about the process, not individuals. If trust is really broken, consider anonymous input (sticky notes, a shared doc before the meeting) as a bridge until the team rebuilds safety.
The retro runs too long. 30 to 45 minutes is plenty for a small team. If it’s going longer, the facilitator is letting discussions spiral. Timebox each section. If a topic needs more time, take it offline and give it a dedicated conversation.
Action items are too ambitious. If the team leaves the retro with five action items and a process redesign, none of it will happen. One or two small changes per iteration. That’s enough. Trust the compounding.