Retrospective Antipatterns

Hey! Hey! You! Yes, you. Come here. Let's have a little talk.

Just to be clear, we're not here because you're the guilty one or anything. (The real reason we're talking is that I started a very long data extraction on my machine and I'm bored waiting 'till it's over.)

So... I've been to some of your retrospectives lately and I'm kind of disappointed, you know? It's like... you guys are so clever, there's so much potential. And still, there's a few things that drive me crazy...

First of all, the moaning.

I get it. After X weeks of hard work, you finally get a chance to air your frustrations and talk about the bad stuff. That's great, do it, let it all out. But make sure you're done in less than 10-20 minutes, depending on the length of the entire meeting.

You see, venting is not the real point of the meeting, or at least not the only one. We're conducting retrospectives to improve as a team, which is hardly done by an hour or two of complaining all around. At one point, you need to shift away the focus from feelings onto the underlying problems and their potential solutions.

Second thing on the list... focusing on everything else and everybody else.

Ah, this other team does (not) this and that!

Ah, this stupid legacy code that we inherited!

Ah, this tool that we're missing or doesn't work as we expect it to work!

Ah, these company processes slowing us down!

Ah, these changing requirements!

Do you see a pattern here? Ah, wait, I already spoiled the answer.

Bad news, placing the responsibility on other people and external factors is not going to move your project forward and improve the way your team works.

Good news, at least you identified some pain points. In most cases, you can directly translate these into something your team can tackle:

WE are not collaborating with the other team effectively enough.

WE are not refactoring hard enough on a day-to-day basis.

WE didn't ensure we have the right tools for the job.

WE haven't figured how to work effectively along with company's processes and/or WE are not pushing hard enough to change ineffective ones.

WE don't have a short-enough feedback loop.

Look, this is not to say that you and your team are responsible for every bad thing that happens in your project/company. I'm just saying that during a retrospective you should look for ways to either:

• fix bad things you can influence
• work effectively despite the things you can't influence (either temporarily or permanently)

Understand? Great.

Now that you're in the right, improvement-oriented mindset, my next point should seem pretty obvious.

You. Should. Avoid. Bikeshedding. Really.

It's so easy to dispute over the small, unimportant details - tabs or spaces, this library or that library, this naming convention or that naming convention. Oh, I love it! Let's polish this baby as much as possible!

The dragon lying there somewhere on a lone sticky note or, perhaps, already forgotten, just mentioned in a single sentence? That's difficult. That would require... thinking!

Put simply, your job during the retrospective is to recognize the dragon and come up with a plan to slay it. Petty peasant disputes and issues can be tackled afterwards or not at all if there's not enough time.

Next up...

Wait! Where are you going?! Stop! I'm not done yet!

Em... Okay! Nice talking to you, see you another time!