What happens when leadership removes the feedback loop?
I want to tell you a story about what happens when leadership removes the feedback loop. A BA colleague and I were pulled aside after a sprint review once. The director overseeing the engagement wanted to talk.
He told us that one of the developers on our team had gone to him, the director, to ask whether he could be excused from some of the Scrum ceremonies.
The director was puzzled. Why didn't the dev just come to us directly?
Fair question. But here's the context he may have forgotten: this was the same director who had told us, and told the clients, that this team doesn't do retrospectives. "We do just enough Agile," was the line.
So what had that developer learned? He had watched leadership deliberately cut the one ceremony that exists specifically so the team can raise exactly that kind of concern. He had no reason to believe bringing it to us would go anywhere. So he went up the chain instead, and what we got was an awkward three-way conversation that didn't actually fix anything.
When you pull the retrospective out of the process, you don't eliminate the feedback. You just lose control of where it goes.
That's why I take retros seriously. Not as a box to check, but as the mechanism that keeps small frustrations from becoming big problems. Here's what I've seen make the difference between a retro that actually changes something and one that just burns 45 minutes
Start with what went well
Not as a formality. If you open with problems, you get a venting session. Starting with wins gives the team something to protect and sets a more balanced tone before you get into the harder stuff.Pick one thing to improve and decide how you'll know it's working
Every team has a list of things that could be better. Pick one. A single improvement that actually gets done is worth more than five that end up forgotten by the next sprint. I usually ask: if we could only fix one thing, what would have the most impact?
Then ask one more question before you move on: how will we know it's actually better? It doesn't have to be complicated. Maybe it's "our daily scrum ends on time," or "we go into sprint planning with all stories sized and ACs written." Something the team can look at two sprints from now and say yes, that changed, or no, it didn't. Without that, you're just hoping.
Give it an owner and a due date
If a retro action item doesn't have a name and a timeframe attached to it, it's not a commitment. It's a wish. I treat retro action items like backlog items. Someone owns it. We check on it.
Open the next retro by looking back at the last one
What happened with the thing we committed to? Did the thing we said we would measure actually move? If we did it, say so. If we didn't, figure out why. Either way, saying it out loud builds the habit of taking these commitments seriously.
Retros work when the team believes something will actually change as a result of having the conversation. That trust is built one kept commitment at a time. And it gets undermined the moment leadership signals the feedback loop is optional.
What's one improvement your team has been talking about for a while but hasn't actually tackled? What would it take to pick that one thing and actually follow through on it?