Mr. Hands

The most ironic item on our latest retrospective was labeled,

Clarify the confusing nomenclature

Which absolutely nobody understood to mean, "our naming of things fucking sucks"

I just spent 90 minutes of my limited time on this Earth in a meeting with the client where they painstakingly constructed a design process that was essentially "Horizontal Waterfall." This means they start with a design briefing document, which is handed over to the UI designer for prototyping, then handed over to the UI artist to create a wireframe, and then given to the UI programmer (me), who goes, "Wtf is any of this"

My producer asked me to host today's retrospectives because she was checks notes "too busy with other stuff". I'm supposed to be a Senior UI Programmer, but sure, whatever. Lucky for her, I was in middle management, so I've done this before.

A retrospective, in Agile parlance, is a meeting held periodically, ideally at the end of a Sprint. The goal is to bitch and moan about how much the work sucks, that your coworkers are awful and that your boss is an incompetent asshole. Then you slap each other on the back, shake hands, and you're ready for another two weeks of that shit.

As you might expect, it's very easy for these meetings to run into one or more multiple fail states:

• They drag on for literal hours because the only thing people love more than complain is hear the sound of their own voice
• One person talks about their pet issue for far too long, drowning out issues from other people that also need to be addressed
• People blame everyone but themselves for the issues in the team

I've seen all these issues (and more!) play out myself, so I have a very specific playbook for moderating a retrospective. As the moderator, I aim to make the process more democratic, crack the whip like a bitch from hell, and keep the meeting under an hour.

Here's how I do that.

Phase 1: Ideation

Attendees are given a stack of Post-It notes to write down their grievances. It doesn't have to be good or positive, and they don't have to care about what other people are writing down. Everyone writes down what's on their mind, for example:

• "Toilet on the second floor is broken."
• "People keep forgetting to bring donuts on Donut Wednesday."
• "Jira sucks balls"

This phase runs for 15 minutes.

Phase 2: Categorization

The moderator (that's me) asks people to read their notes out loud. The notes are then placed in a category in a public space. If you're in a physical office, that means on a whiteboard, otherwise some kind of shared virtual nonsense like Miro, Figma, or fuck it, Jira.

Attendees are given very specific instructions that we're not discussing the notes just yet, we're just putting them in categories. (They will do this anyway. It's your job as moderator to keep them focused on the task!)

For example, notes from different attendees are moved into these categories:

• Toilet Maintenance
• Donut Wednesday
• Jira

This phase also runs for about 15 minutes, depending on how fast you can get through the notes.

Phase 3: Voting

Attendees are then given three votes. They are instructed to vote for the categories they would like to discuss with the team, ignoring the notes in the categories. Everyone's vote counts the same, but you can vote for the same category multiple times.

This takes about 5 minutes.

Phase 4: Discussion

Now we get to the actual meat and potatoes of the meeting.

The moderator sorts the categories by votes. If there's a tie, they break it according to their own preferences. (Should have voted better, suckers!) Topics are then discussed from most votes to least.

During this phase, the moderator instructs the attendees to phrase their responses in one of two ways:

• What should the team START doing?
• What should the team CONTINUE doing?

These are your Action Items, and the moderator writes them down. For example:

• START: Give feedback to the janitorial staff about the toilet situation
• CONTINUE: Bringing donuts on Wednesday
• START: Investigate alternatives to Jira

This phrasing aims to get people to think about what they can do to improve their situation. Blaming outside forces is therefor discouraged. The attendees will ignore these instructions, so it's the moderator's job to keep them in line.

At the start of the discussion, the moderator starts a timer for three minutes. The topic is discussed for this time. When the timer runs out, the moderator asks the team if they want to continue discussing the topic for another three minutes or move on to the next. If anyone wants to keep talking, a new timer is started for another three minutes. This puts friction on how much time people can waste talking in circles. They will do this anyway.

This phase runs for as long as you want, or until you run out of topics.

Conclusion

My process is far from perfect, but it has been honed over multiple iterations. Its biggest drawback is that only popular topics get discussed. But since these are also the ones that will have the most impact on the team, it evens out. Still, you will always have people feeling frustrated at the end. I've found that the best remedy is not to extend the meeting but to do it more often.