I’ve lost count of how many teams have quietly told me some version of:
“Our retros don’t really do anything.”
The ritual is there. The team gathers, adds sticky notes, talks about what went well and what didn’t, creates a list of actions… and then mostly goes back to business as usual.
Over time, people learn that retros are where you say the right things, not where things really change. Engagement drops. Frustration builds. Eventually, someone asks the question out loud: “Do we even need retros?”
I don’t think the problem is retros themselves. I think it’s what we’re asking them to do.
Why most retros feel heavy and ineffective
A few patterns show up again and again:
- Too much scope. The retro tries to fix everything at once: process, tooling, strategy, interpersonal tension, leadership decisions.
- Action-item obsession. Success is measured by how many tasks end up in Jira, not by whether anything actually gets better.
- No feedback loop. Actions are rarely revisited. The next retro might mention the same issues again, with a new list of tasks.
- Emotional risk, little safety. People sense that naming certain issues would be risky or pointless, so the conversation stays at the surface.
The result is a ceremony that looks like improvement work from the outside but doesn’t feel like it on the inside.
What if retros were about experiments instead?
When I work with teams, I often reframe retros around a simple question:
“What is one small experiment we want to run between now and the next retro?”
Not “what’s our full solution?” Not “how do we fix everything?” Just: what’s a small, safe-to-try change that might move this in a better direction?
An experiment has a few key qualities:
- It’s specific and time-bound.
- It’s small enough that the team actually has capacity to try it.
- It’s framed as learning: “We don’t know yet if this will work.”
That shift — from tasks to experiments — sounds subtle, but it changes the whole tone of the retro.
Designing a simple experiment-driven retro
Here’s a lightweight flow you can try. (This lines up with the Experiment-Driven Retrospective Toolkit I use with teams.)
1. Start with real experience, not just events
Instead of jumping straight to “what went well / what didn’t,” begin with questions that surface the human experience of the last iteration:
- “Where did you feel most energized this sprint?”
- “Where did you feel most stuck?”
- “What surprised you about how we worked together?”
This helps the team move beyond the usual story (“we were busy”) and notice the specific moments that felt off or alive.
2. Name one or two themes
Instead of trying to address every issue, look for patterns:
- “It sounds like we’re constantly redoing work after feedback.”
- “We keep bumping into unclear ownership.”
- “Interruptions are blowing up our focus time.”
Pick one theme that feels both important and workable. You can keep a backlog of other themes, but the retro itself isn’t the place to solve all of them.
3. Design one experiment together
With that theme in mind, design a small experiment. A useful pattern:
“For the next sprint, we will [change] in [this specific way] to see if [this outcome] improves.”
Examples:
- “For the next two weeks, we’ll run a 15-minute alignment check at the start of each day focused only on blockers and dependencies.”
- “For the next sprint, we’ll treat focus time as a team-level commitment: two mornings with no meetings and no Slack pings for deep work.”
- “For the next three retros, we’ll start by revisiting the last experiment before adding any new topics.”
Make sure the experiment has an owner (or small pair) and a clear check-in point.
4. Close by naming how it feels
Before you end, ask:
- “On a scale of 1–5, how confident do we feel about this experiment?”
- “What might get in the way of us actually doing it?”
This surfaces obstacles early (vacations, deadlines, unclear expectations) and gives you a chance to adjust before the idea disappears into a ticket.
What changes when you work this way
Over time, experiment-driven retros can shift the culture in a few important ways:
- From blame to curiosity. If something doesn’t work, the question becomes “What did we learn?” rather than “Who dropped the ball?”
- From overwhelm to focus. Instead of drowning in action items, the team knows exactly what they’re testing this sprint.
- From ritual to practice. Retros stop being a box to check and become a real feedback loop with the rest of the team’s work.
It also creates a track record of change. You can literally look back and see the experiments you’ve run, what you’ve learned, and how your way of working has evolved.
What this requires from leadership
None of this works if leadership treats experiments as performance tests. For experiment-driven retros to work, leaders have to:
- Allow for experiments that don’t “succeed” in a conventional way.
- Protect some time and attention for this work, even when delivery pressure is high.
- Be willing to hear uncomfortable feedback about the system.
When leaders engage with retros as co-learners — not just reviewers — teams are far more likely to be honest and creative.
A small invitation
If your retros feel heavy, repetitive, or disconnected from real change, you don’t have to throw them out. You can start with one experiment:
“For the next two retros, we’ll treat them as experiment-design meetings, not action-item factories.”
Try the flow above. Keep it light. See what you learn. You can always adjust from there.
And if you’d like support designing or facilitating experiment-driven retros for your team, that’s a big part of my work.
Reach out if you’d like to explore it together.