Last week I convened a small, cross-functional team for a half hour debrief of the work we’d done together on last month’s Net Neutrality trainings and tweetchat. The trainings and tweetchat were largely successful efforts, but this debrief was to discuss the process of working together.

Here’s how we did it:

• First I sent around an etherpad with some questions. There was a section for populating a timeline of the entire process from conception to completion. And there were sections for capturing what worked well, and what people felt could be improved upon.
• As people added their thoughts to the etherpad, it became clear to me that a Vidyo chat would be useful. There were differences of opinion and indications of tension that I felt ought to be surfaced and discussed.
• Everyone took 30 minutes out of their busy schedules to meet over Vidyo, which I totally appreciated! I started the meeting by stating my goal which was to reach a shared agreement about two or three concrete things we would try to do more of or less of in the future.
• I would have loved to have had a full hour, as I felt we were just starting to surface the real issues near the end of the call. It felt a little strange to have to cut off the conversation right when we were getting into it.
• In the short time we had, we were able to touch on what I think were probably the most salient points from the pad, and everyone had a chance to speak. We also identified four concrete things to do differently in the future. By those measures, I think the debrief was successful.
• Some additional takeaways were shared via email after the call, and I think everyone is committed to making this the start of an ongoing process of continuous improvement.

I called this a “debrief” because it was a relatively unstructured conversation looking back at the end of a project. In my mind, a debrief is one flavor of a larger category of what I’d call “retrospecting behaviors.”

Here are some thoughts about what makes a good retrospective:

You don’t need to save retrospecting for the end. Retrospectives are different from post-mortems in this way. You can retrospect at any point during a project, and, in fact, for teams that work together consistently, retrospectives can be baked into your regular working rhythm.

First thing’s first: start with a neutral timeline. It’s amazing how much we can forget. Spend a couple minutes re-creating an objective timeline of what happened leading up to the retrospective. Use calendars, emails, blog posts, etc. to re-create the major milestones that occurred.

Bring data. If possible, the facilitator should bring data or solicit data from the team. Data can include so many things! Here are just a few examples:

• Quantitative and qualitative measures of success.
• Data about how long things took to finish.
• Subjective experiences: each team member’s high point and low point. One word or phrase from each team member describing their experience.

Be ready for the awkward. For a breakthrough to happen, you often have to go through something uncomfortable first. No one should feel unsafe or attacked, of course, but transformation happens when people have the courage to speak and hear painful truths. Not every retrospective will feel like a group therapy session, but surfacing tensions in productive, solution-oriented ways is good for teams.

Despite their name, retrospectives are about the future. The outcome of any retrospective (whether it’s a team meeting, or 5 minutes of solo thinking time at your desk) should be at least one specific thing you’d like to do differently in the future. Make it visible to you and your teammates.

A “Do Differently” is a specific and immediately actionable experiment. Commit to trying something different just for a week. Because the risk is low (it’s just a week!), you can try something pretty dramatic. Choose something you can start right away.  “Let’s try using Trello for a week” or “Let’s see if having a 10-minute check-in each morning reduces confusion.”

Retrospectives often also inspire one-time actions and new rules. One-time actions are things like, “We need to do a CRM training for the team” or “We should update our list of vendors because no one knew who to call when we ran into trouble.” New rules are things like, “We should start every project with a kick-off meeting, no matter how small the project is.”

Both one-time actions and new rules are important, and should be captured and assigned a responsible person. But they are not the same as “Do Differentlys” which are meant to create a culture of experimentation that is necessary for continuous improvement.

It’s not about how well you followed a process; it’s about how well the process is serving the goals. This is another difference between retrospectives and post-mortems. Whereas in a post-mortem, you might be discussing what you did “right” and “wrong” (i.e. how well you adhered to some agreed upon rules or norms), in a retrospective you discuss what “worked” and “didn’t work” (which might lead to changing those norms).

Celebrate. Retrospectives are occasions to recognize the good as well as the bad. I won’t lie. Some of my favorite retrospectives involved cake.

What would you add to or change about the above list?

http://hannahgrams.com/2014/09/06/on-retrospectives/