The Limitations of the Sprint Retrospective

Short personal thoughts, ideas, and reflections

Back in my Scrum days — yes, with 20+ years of experience, I am allowed to say that — I genuinely enjoyed facilitating Retrospectives. It was a perfect moment to pause and identify areas for improvement.

For two weeks (my go-to Sprint length), the team would be in build mode, minimizing dependencies and getting things done. Then, we’d come together to reflect.

I’ve always liked how Scrum offers structure — a reliable frame with roles, artifacts, and events to help navigate complexity. As someone who leans process-heavy (okay, maybe a bit of a process freak 😅), that gave me peace of mind.

But over the years, I’ve grown to appreciate flow. Not just a continuous flow of value but also a constant flow of improvements. ♻️

Scrum doesn’t forbid you from releasing more often or improving outside the Retrospective. But in practice? Many teams act like the Retrospective is the only moment to reflect.

We often see this when teams start using Columinity — our product for identifying improvements based on data and scientific insights. Some teams treat it like a Retrospective-only activity.

But here’s the thing: the philosophy behind Columinity — Action Research — relies on continuous cycles. Not once per Sprint. If you uncover something valuable today, why wait until the Retrospective to act on it? 🤷‍♀️

Sure, you don’t want to derail focus with every tiny insight. But the solution isn’t to bottle them up until some scheduled ritual. That’s not agility — that’s a waterfall mindset in disguise. 🙈

So here’s a thought: improve continuously… and who knows, maybe you won’t even need that scheduled Retrospective anymore.

What’s your take on this?