The retro that repeats itself
When the same complaint appears three sprints running, the retro is working. The system around it is not.
Read six months of a team's retro notes in one sitting, which is a thing we do in diagnostics and recommend to any manager with an hour, and a pattern usually surfaces: the same two or three complaints, recurring under different phrasings, each time generating an action item, each action item evaporating before the next occurrence.
The instinct is to blame the retro. The retro is fine. It is doing exactly what a sensor should do: detecting the same fault every time the fault occurs. What is missing is the part of the system that acts on sensor data, and it is missing for a specific reason: the recurring complaints are almost always cross-boundary. Flaky tests owned by everyone, environments owned by no one, a review bottleneck that belongs to a different team. Inside the team, the retro can fix things, and does, which is why the fixable items do not recur. The residue that repeats is precisely the set of problems the team cannot fix alone.
So the move is not a better retro format. It is an escalation path with a name on it: recurring items get promoted out of the team ceremony to whoever actually owns the boundary, with the retro history attached as evidence, and they come back with a decision, including possibly a documented no. The tradeoff is that managers acquire a queue, which is the point. A complaint that recurs three times is not a mood. It is a measurement.