You have been in this retro before. Not one like it, this exact one. The same communication problem gets raised, the same dependency gets blamed, the same "we need to plan earlier" lands on the board, and everyone nods because everyone agreed to it last time too. The actions get written down, the meeting ends, and a fortnight later the same three items come back around like a song you cannot get out of your head.
When a retrospective starts to feel like déjà vu, it usually is. And a ritual that surfaces the same problems without ever moving them stops being a review and becomes a scheduled complaint.
Raising issues is the easy part
Most teams are perfectly good at naming what went wrong. Where it breaks down is the gap between the action list and anything actually changing. When the actions from one retro quietly never happen, the next retro re-discovers the same issue, honestly believing it is new.
There is a quieter failure underneath that. When nothing changes for long enough, people stop raising the real problems and start offering safe, surface-level ones, because putting energy into a genuine issue that never gets fixed feels worse than saying nothing. The retro keeps running, but it turns into a pressure valve: the team gets to vent, so that nothing has to change.
Ten actions you will not do is worse than one you will
The instinct at the end of a retro is to capture everything, so the board fills with eight or ten well-meaning improvements. The following sprint has room for maybe one, so nine get dropped, and the team quietly learns that retro actions are optional. A short list you actually finish rebuilds that trust; a long list you abandon spends it.
Some of what surfaces is also outside the team's power to fix: headcount, a cross-team dependency, a deployment pipeline someone else owns. Naming those every fortnight without a route to escalate them just teaches everyone that speaking up leads nowhere. Those items need a different destination than the team's own action list, and pretending otherwise is corrosive.
Why the format matters more than the facilitator
Retrospectives are one of the situations the LEGO Serious Play method was built for — a complex, no-single-answer question where you want everyone's honest input. When the review is run so that every person builds and speaks to their own account of the sprint, you get past the two or three loudest read-outs and surface the causes that a quick round-the-table would miss. That changes which problems even make it into the open.
A facilitated session is not the move for a smooth sprint with nothing much to unpack. It earns its place when the same issues keep recurring, when honesty has gone quiet, or when a project wrap-up needs the whole team thinking.
One fix you can run Monday
At your next retro, cap it hard: pick one problem, assign one owner, agree one small experiment to try before the next session, and nothing else goes on the action board. Then open the following retro by checking that single item first, before anything new is raised. It is a small change that breaks the loop, because the team sees, in front of everyone, that raising something leads to something.
If your retros keep circling the same ground, you can take the free Brick Spark fit assessment for a straight read on whether a facilitated review would help you get past it, or whether the fix is somewhere else entirely.