🔗 Why your retrospectives don't work and how to fix them

Every team must believe in improvement, even when it no longer happens. That’s what retrospectives are for.

Most teams also use retrospectives for documenting problems that nobody has time to fix. That way, when the retrospective comes, we can all nod in agreement that yes, the problem is real, and yes, it should be fixed someday, but not today.

Sometimes, we even go as far as assigning someone to "investigate" the problem. Yet, that "investigation" never goes anywhere. Maybe it's because nobody really knows what "investigating" means, except that it definitely does not mean "fixing" the problem, otherwise we'd have written that down.

But hey, we've got it all documented! Now there's also plausible deniability. If the problem ever blows up, we can just say that "we documented it months ago" but "we just didn't have time to fix it yet." Then, we take those statements at face value and keep doing whatever we were doing.

It sounds dysfunctional, but that's exactly how most retrospectives work. They have nothing to do with continuous improvement; they're just a ritual to make us feel better about all the broken things teams keep ignoring.

If that's your case, I hope this blog post can help clear up the confusion between what retrospectives are supposed to be and what they actually are.

Believe it or not, retrospectives are fixable. I've experienced pretty good continous improvement cultures in the last few teams I worked at, including the current one. So I'll share a thing or two I learned along the way. At the end, I'll also share a few thoughts about how there will always be something a little broken, and why that's okay.