On Retrospectives

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?

Week One

First Impressions {Anagram: SOS: Fries Misprints!}

Heading into my (short) second week at MoFo, the following thoughts are swimming around my brain:

  • Everyone here is smart and kind, which I consider to be the two most important traits in colleagues. Win! Thanks to everyone for being so welcoming.
  • This feels like the type of environment where you have to/get to “jump in.” This makes me happy because I learn by doing, but I’ll have to ask for forgiveness in advance if my contributions sometimes lack full context. I’ll try to find the right balance between listening and contributing.
  • Given the facilitative nature of my role, I expect my main unit of contribution will be on the process side of things, rather than product, content, and the other outcomes of our work. In some ways I think it’s more difficult to jump in on process, because there may be a lot of context and history that I can’t read about on wikis and blogs. Again, apologies in advance for all of the things I’m sure I’m going to mis-read during my spin-up phase.

Lay of the Land {Anagram: Lady Halftone}

I’ve asked a few people what they think are the areas in which I might be helpful. I’ve heard several answers including: establishing a team-wide rhythm, improving communication habits and meeting practices, setting up systems, and increasing communication between the various parts of the Engagement team’s work.

I’m looking forward to asking the same question of everyone on the team. I’m going to need a metric to know how well I’m doing, and so far the main metric I’ve identified is “team member happiness regarding systems and processes.” (Suggestions for other metrics welcomed!)

Dropping Philosophy {Anagram: Holding Pro-Hippy Spy}

I’m a big believer in letting systems emerge, rather than designing them, at least when it comes to groups of people (and the web). Emergent systems start from the question, “What is happening now?” and use a repeated pattern of evaluation and incremental changes to work towards better systems.

Kanban is a tool used in the manufacturing and software worlds to manage workflow and prevent bottlenecks. I like to think of Kanban as a method for discovering the process you already have in place. Even if you haven’t sat down and defined a process, if work is getting done, there is some process in place—maybe a really messy one. Kanban helps teams expose that process, and then begin to identify any problematic parts and make changes.

Honestly, I don’t know if Kanban would be an effective tool for the communications- and development-flavored work of the Engagement Team. I bring it up here only because I do think it may be valuable to implement some kind of discover/experiment/evaluate rhythms into the team’s workflow. To clarify: I’m talking about the meta process part of the work (the How), not the outcomes part (the What), though of course discover/experiment/evaluate might also be applicable to, say, building a new web property or writing a grant.