"Retros Are a Waste of Time." Let's Unpack Why They're Not

"A retrospective? That's a waste of time" — a line I've heard so many times I could set it on repeat. And the problem is, the person saying it is often right. A bad retro really is useless. The question is why yours is bad.

Let's break this tool down honestly: what it's for, how to get people to tell the truth, what you still won't manage to pull out of them, and why without the final step the whole meeting turns into a collective scratching of heads.

What it's actually for

A retrospective is when you, the person "at the wheel," gather the team after a sprint (or any other stage) and try to figure out: what went well, what went not so well, and where all the weekends disappeared while the crew was "polishing" the release. Sounds nice: we talk, we share thoughts, we hunt for insights. In practice, any retro is quite the ride — especially when people have exhaustion in their eyes mixed with a desire to just not touch anything anymore.

But the alternative is worse. Without a retro you'll keep stepping on the same rake over and over, and the bump on your forehead doesn't get any prettier, even if you brand it with the company logo. As a manager, you need a few things.

Hear what actually worries the team. Maybe your DevOps engineer is still restarting servers by hand while you sincerely believed that had been automated ages ago. Things like this surface precisely at a retro — not on a status call where everyone cheerfully reports "all good."

Understand how the load was distributed. Why some colleagues got slammed the entire sprint while others calmly sipped tea. This isn't about punishing anyone. It's about the fact that an imbalance in load is the first warning sign of burnout for the strong and slacking off for the weak. Both will cost you dearly.

Get food for thought. Where the processes need to change, where you should "tighten the screws," and where, on the contrary, you should "loosen up." A retro isn't reporting, it's your sensor for the team's state. Switch it off and you're managing blind.

How to tune the team for an honest conversation

Let me say it upfront: getting people to speak sincerely and without fear is a separate quest with a boss at the end. By default, a person plays it safe at a retro: say too much and you'll get burned. Your job is to break that reflex. Here's what actually works.

Explain why the retro is needed — transparently and like a human being. If people think it's a "bureaucratic obligation for the sake of a checkbox," there will be no value at all. They'll sit out their time, toss in some safe platitudes, and scatter. The first thing everyone should have in their head: this hour isn't for the manager's report, it's for the team — so the next sprint is easier.

Agree that a retro never gets personal. Constructive feedback is welcome, but turning the meeting into a battle for the truth and a public "who's to blame" hearing is not an option. The moment you let one in-your-face attack slide, honesty is over: people go quiet, because staying quiet is safer than becoming the next target.

Praise those who aren't shy about speaking up. Even if someone is talking nonsense, the mere fact of engagement is already valuable — it shows the others that speaking isn't scary. With the right approach, "nonsense" sometimes gives birth to brilliant ideas: someone tosses out a raw thought, a second person builds on it, a third recalls a similar case — and there you have a ready solution to a problem you'd been dodging for half a year.

From experience: the atmosphere at a retro isn't something you set up in a single meeting. It's the reputation of the format, which you accumulate over months. Stage one public flogging and you'll spend the next six months coaxing people out of their shells. So think of honesty as an investment that earns interest, not as a switch.

What will stay off-screen regardless

And now, no illusions. No matter how hard you try, some things the team will never tell you to your face.

Someone is holding a grudge against a colleague over personal baggage and won't drag it into a group meeting. Someone is embarrassed to admit they can't keep up with learning new tech and are "flailing" in the code — because they're afraid of looking weak. And sometimes there's an unspoken "authority figure" in the team whom everyone is a little wary of, and criticizing them out loud is taboo, even if they're objectively slowing things down.

Accept this as a given. You won't pull everything out in a single retrospective, and that's normal. But if you run them regularly and, in parallel, talk to people in private formats — one-on-ones, casual chats, a coffee-break conversation — even the quietest ones will eventually open up. Or at least drop a hint about where you should take a closer look.

A retro is the tip of the iceberg. It catches what people are willing to say in front of everyone. Everything else lives in the back channels, and you can only reach it through trust, which you build outside the meeting. Don't expect a group format to replace personal contact. It complements it, but doesn't cancel it out.

The point isn't to talk, it's to do

This is where a retro most often dies. If the meeting turns into "we talked and then scattered," trust in the process drops to zero within a couple of iterations. People read it fast: they're being heard, but nothing changes. And next time they won't waste energy on honesty.

To keep that from happening, you as a manager need three things.

Write down the outcomes. Not "we discussed it and everyone felt better," but concrete action items. The kind like "add a new step to the pipeline so tests run automatically," or even "get together outside of work and play some board games to blow off steam" — yes, that's a valid outcome too, if the team is worn out. The key is that the wording is verifiable.

Assign owners. A task without an owner isn't a task, it's "a useful idea destined never to happen." Every action item needs a name next to it. Not "the team will do it," but "Pete will do it by next Friday." Blurred responsibility equals no responsibility.

Check the result a sprint later. Did it work? Didn't work? Why? Fix it and move on. This is exactly the step that closes the loop and turns a retro from chit-chat into a real improvement mechanism. Without the check, the previous point loses its value too: why assign an owner if nobody's going to ask about the result later.

Notice that these three steps are essentially the same loop you run your code through: you spotted a problem, you made a change, you verified that it worked. A retro without the last step is like shipping a fix and never looking at the monitoring.

A retro is not a penitential prayer

A retrospective really is a powerful tool. But only if you don't turn it into a ritual of "penitential prayer" or a "ceremony for hunting down the guilty." It's about the team growing up, about fixing processes, and about being honest with each other. Some grudges and unspoken things will always remain — these are people, not perfect machines. Your job isn't to scrub them down to zero, but to minimize them and create an atmosphere where people aren't afraid to own up to their screwups and dig out of them together.

And yes, sometimes all this lovely constructive work with action items shatters against the human factor and plain old laziness — we managers, too, sometimes never get around to following up. I'll admit it. But trust me: it's better to fidget and change something than to drift with the current and then be surprised why everything fell apart again the day before the release.

So no, a retro isn't a waste of time. The waste of time is a retro you run for the sake of a checkbox and then complain about yourself.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP