I’ve attended a lot of retrospectives, and generally they’ve all followed the same evolution of events:

• First, we (the engineers) have been working on a feature that turns into a mess.
• After we ship the feature, someone schedules a retrospective a couple of days later.
• During the meeting we discuss items that were anonymously submitted prior to that day—“what went well” and “do better” items—and oftentimes the discussion becomes heated.
• Someone takes notes, and after the meeting he or she documents the follow-up items in a company wiki article, only to be read by no one.
• We start a new feature, and—surprise (not)—some of the same issues happen again.

Retrospectives are supposed to help us in two ways: 1) to recognize the things we did right so we can do them again and 2) to learn from our mistakes so future development is better. But in my experience things don’t get better. I have to believe this isn’t uncommon. So why do we have retrospectives in the first place, and how can we reap some actual change from them?

Having retrospectives validates that a company is “good,” but sometimes they exist just so we can vent a lot of crap.

If companies want to appear progressive and healthy, they incorporate certain things into their processes and culture. One of those things is the retrospective meeting. On paper retrospectives are great. They give us the chance to celebrate our successes and improve ourselves through feedback.

Unfortunately I feel like retrospectives are more often one-time bitchfests. I’ve worked on some projects during which there was yelling and head butting, so it’s no wonder we immediately have a retrospective after the feature is shipped. Feelings are still raw, and even though no one will admit it, people are dying to dump their grievances. Luckily I’ve worked with people who are civil enough to not name names even though we all know who’s being roasted during a meeting.

It’s totally human to get charged up before a retrospective. The problem for me is that positive change seldom happens after it’s over. Why is that?

People don’t own their mistakes.

If you or your team is called out for a “do better,” you need to own it before you can do something about it. What does it mean to own something anyway? It means you accept that what you did—or didn’t do—had a negative impact and you don’t blame someone else, even if it wasn’t 100% your fault. You also focus on how you can do things differently and perhaps reach out to others for a more well-rounded solution.

People don’t want to change.

Some people know they can do better but won’t. There are others who believe they didn’t do anything wrong; therefore, there’s nothing to change. Either way this can be a big problem, especially if you try talking to them or their managers about it and nothing happens. I don’t have any great suggestions here, only this: If someone’s performance egregiously affects feature work on a regular basis and complaints fall on deaf ears, you can either 1) put up with it or 2) get a new job. Life can suck, but sometimes your options are cut and dry.

So how can we get some real change from retrospectives? I don’t know. The only thing I can do is suggest a couple of things that haven’t been proven to work. (Who knows? They might.)

Sympathize with people and their grievances.

Sometimes discussion items in a retrospective don’t apply to you. Sometimes you’ll disagree with a few. Either way, don’t automatically dismiss them. If someone brings up an issue, there must be a reason. Always go into a retrospective with an open mind; there’s no such thing as an invalid grievance. Dismissing someone will instantly destroy the supportive space retrospectives are supposed to provide. If you immediately shoot people down, especially without acknowledging their issues, they will mentally check out right away, and they’ll tune you out for the rest of the meeting. That’s not how a retrospective is supposed to go.

Also, if you put yourself in someone else’s shoes, you’re more likely to participate in the solution. Having sympathy brings all of you together and creates a positive mindset.

Promote retrospectives to first-class citizenship.

After you document the notes from a retrospective, what do you do with that information? I’ll bet nothing.

I’m going to assume that the departments in most companies have their own monthly or quarterly all-hands meetings. If your department doesn’t, it should. Let’s take an engineering department in a tech company for example. An engineering all-hands is a good opportunity to share engineering-specific notes from all the retrospectives in a quarter. People who didn’t work on a feature can provide their neutral input, and everyone can use this as a learning experience for future work. Plus, this information is reintroduced so it’s not as easily forgotten.

Ownership.

Managers should review the notes from prior retrospectives before the start of a new feature. That way they can identify potential pain points they can proactively address. Of course ICs also need to own their past mistakes and do better, but if managers take that extra step to remind the troops, there’s more onus on the ICs to follow through.

So now what?

Look, the time you put into retrospectives should be well spent. They should be productive and provide an ROI, but they can’t unless you have the right attitude and follow-through. The right solutions can vary from company to company. Talk to your manager or department head to see what those could look like for your team.