Retrospective meeting guidelines for an engineering team

Retrospectives are supposed to be meetings, usually at the end of a workstream, performed for the team to reflect on what went well, what went bad, and what needs to be done next time to improve the overall process. It's a valuable way to gain feedback and avoid doing the same mistakes again and again. After all, if you don't know you are doing something wrong, how can you fix it? And since everything is subjective, something obviously wrong for a team member, might not be obvious to another team member.

But not everyone is fun of retrospectives. Especially many engineers feel that these meetings are a waste of time.

And they are not always wrong in my opinion. Retrospective meetings can easily be a waste of time if not conducted carefully. So here's a list of what I consider to be the most important guidelines to follow when conducting a retrospective, to make sure it's providing value back to the members of an engineering team.

Keep it short

Might be obvious for some, but time boxing the event is super important. Discussions can easily wander in many directions without any useful conclusion. Timeboxing the event and regularly reminding people of the limited time devoted to this event helps keep people focused. There's nothing worst than a long and tiring retrospective meeting finishing, and listening to people saying this "could have been an email".

Push for things that went bad

In projects where no obvious thing went wrong, things that went well and action items can flow easily. But things that went bad are not easily extracted. And in most projects, there are at least a few things that didn't go well. People are more reluctant to list these things, especially if there are in front of people that "caused" these things to went bad. Lead by example and list a few things that went bad, always carefully and respectfully, without insulting or personally blaming someone. Even better, list something that went bad due to your behavior to show that honesty is appreciated and it's not punished.

Prioritize

Gathering the good, the bad, and the ugly is just the first step. It's easy to get lost in huge lists. And not every list item is equal. After the aggregation, make people vote, preferably with a limited number of votes. This will surface the most important things that the discussion should be focused on. Especially with a time-limited event, not everything can be discussed, so choose wisely what you vote for.

Map to action items

I've seen quite a few retrospectives finishing with action items that addressed only 1 or 2 of the things that went bad. Even though I recommend prioritization, I don't recommend ignoring everything except the top items. Aim for the action items to cover most of the things that went bad. Remember that you don't have to have a 1:1 relationship between action items and things that went bad. An action item ideally can cover multiple things that went bad.

Hopefully, this was a quick and useful list of how to improve your retrospective meetings.

Happy discussions!