Scrum and DevOps both have a retrospective phase. Many teams use it to solve frictions.
That’s generally a bad practice.
The Problem With Waiting
A retrospective keeps the friction alive until the meeting.
If a developer hits a problem on Tuesday, and the retrospective is Friday, the problem repeats on Wednesday and Thursday. Everyone works around it. Nobody fixes it. The team has agreed to be uncomfortable for three more days.
And when Friday comes, the friction has to be remembered — which means it has to be significant enough to recall. Small frictions get forgotten. Which means they never get fixed at all.
The Better Practice
Solve the problem when it’s recognized.
That doesn’t require a meeting. It requires someone to notice, someone to decide, and the decision to be acted on.
A meeting is a ceremony. It costs every attendee’s time, and most of that time is spent listening to problems that don’t affect them.
Collect opinions from the people affected. Let the leader decide. That’s faster, and it produces a decision while the problem is still in front of everyone.
On Voting
Avoid democratic voting as the decision method.
No solution satisfies every member. If you vote, you’re choosing the option that satisfies the most people — which is not the same as the option that works.
And voting has a hidden cost: it commits everyone to the outcome, including the people who voted against it. Then the minority quietly doesn’t adopt the change, and the problem persists.
The standard should be: an acceptable method. Not the best method. Not the most popular one. One that everyone can work with, decided by someone accountable for the outcome.
What the Leader Owes the Team
Decision by leader isn’t decision by authority. It comes with obligations:
- Decide fast. The point is to fix the problem while it’s live, not to deliberate.
- Explain the reasoning. People accept decisions they understand, even when they disagree.
- Revisit if it fails. A decision made quickly is a hypothesis. If it doesn’t work, change it.
- Don’t decide what you don’t know. If the leader can’t judge, ask the people who can — and then decide.
What Happens to the Rest
Some problems won’t have a solution at the moment. Or they’ll be real but low priority.
Those get recorded. A ticket, a note, a list. The team can return to them later — and a retrospective is a fine place to do that.
So the retrospective isn’t wrong. It’s just wrong as the only time improvements happen.
Fix what you can, when you can. Record what you can’t. Revisit on a schedule.
The Point
The retrospective treats improvement as a periodic event. That’s what makes it wasteful — not the meeting itself, but the assumption that frictions should wait.
Improvement should be continuous. The retrospective should be a catch-up for what didn’t get solved, not the mechanism by which anything gets solved.
Related: