How to kill your Retrospective Debt

The expression technical debt is widely used among the software development community. The debt is some work that should have been performed but, for any reason, there was no time to do it. Some alternative solution was found and now we are living with it. The idea of debt is that you'll have to pay for it in the future, and you'll pay more the later you pay, maybe because the code will become harder to maintain.

Sometimes you find a group (maybe a team) where there's a lot of conflict, unsolved problems or difficult communication. Maybe they have been doing retrospectives but the hard topics have never been raised. Maybe there's a lack of trust and transparency and everybody seems burnout. You have to address it, and it's not easy (if possible at all).

If all these problems had been addressed when they appeared, maybe the tension would not be that hard. If the retrospectives had worked maybe the team would feel more motivated. As long as there are things that could have been addressed in retrospectives and weren't.

I'll call it Retrospective Debt. The later the team address the problem, the harder to fix. It's a debt that the team is going to pay later. What to do?

There's no unique solution for all teams, but I'm sure that doing exactly the same they were doing won't fix anything. Maintaining the same retrospectives won't work. And a single action won't fix anything. And it won't be quick. So, faith and patience.

Maybe you'll have to think in the five dysfunctions of a team, perform some dynamics in the team like a Lego game, introduce the Core Protocols,  perform retrospectives in a different way, use some clever coaching techniques or just have some beers.

Start as soon as possible, draw a plan, address people problems. Don't look for metrics, please.

And above all, don't let your Retrospective Debt grow.