A guide to modern retros: how to host valuable project post-mortems

Kyle Daigle, Senior Director of Strategic Programs at GitHub, has been working in product for over 15 years. He’s worked on all kinds of projects, from fixing issues with GitHub’s existing features to working on GitHub's Arctic Code Vault — a data repository and archive of open source code stored in Svalbard, Norway. 

Suffice to say: Kyle’s led more than a few retros with big and small teams alike. He’s seen both the good and the…less good approaches. “Everyone's always talking about, ‘we're going to do a retro,’ as if it were something that you just pull out the retro notebook or binder and go: Step one,” he says. 

But depending on the size, makeup and dynamic of the team, a retrospective may sometimes need to be more than just a project post-mortem: “This needs to both be a retrospective — looking back at the work we did, what went well, what didn't go well — and also, a trust building exercise.” Here are Kyle’s tips for hosting high value retros. 

Goals of the modern retro

“The goal of a retro is to give you a unique insight,” says Kyle. “Otherwise, it's just a very expensive meeting with your entire team.” 

And while the point of retros is to come out with a list of action items for the team to own and change themselves, when you don't have trust among team members, “it's very hard to get to a unique insight,” says Kyle. “So you have to focus on getting trust by letting people share their real experiences. I think this is a modern retro.”

Retrospectives can be an exercise in trust and team dynamics

While you do want to maintain objectivity during project post-mortems — or at least set them up to be as blameless as possible — Kyle believes that current approaches to retrospectives may be too rigid. Enough that they may be blocking out pertinent information, like whether the team is meshing and working together well. 

“Is [the team] extremely high trust? Have they done this work together before? Have they demonstrated the ability to have a unique insight and act on it? Because if you don't have that, you can't just break out the binder,” says Kyle. 

The ideal retrospective doesn’t only look back on what did and didn’t go well with a project, Kyle says that it’s also an important opportunity to do some trust building with the team. 

Retros with new teams

In classic retros, a team lead or manager may identify some of the sticking points during a project. Kyle says “you're supposed to say things like, ‘I see that we didn't spend enough time speccing out this feature before we built it. Does anyone have any thoughts on how we should take this, and who should take it and go work on it?"

But if the team doesn’t have a history of working together, team members may be reluctant to speak up and criticize processes. To build trust, Kyle says you need to reframe retros as an open conversation about people’s experiences during a project. You’ll soon realize that, often, the main blockers for a new team aren’t necessarily technical, but interpersonal. 

“If someone's like, ‘I kept feeling pressured to move my story along. I just had to get it out and I didn't feel like I had enough time,’ then you might want to have another teammate— not the manager — or potentially a facilitator dig into that a bit and find out if anyone else on the team felt that way to validate it.”

Creating space for vulnerability among newly formed teams gives you the opportunity to unearth unique insights, which is what the retro process is all about. 

Meta retros (retros involving multiple cross-functional teams)

In larger organizations where projects involve a range of cross-functional teams — from engineering to marketing — getting perspective on what did and didn’t work is more complicated than setting up one meeting. 

Here, Kyle suggests that each functional group can do a retro, and then a delegate or a few delegates from each of those groups can go to a “meta retro” to represent their group. “That allows you to get unique insights, for example if the product marketing team didn’t feel that they received enough context or collaboration from engineering teams,” he says. 

Time to retro: When should teams review projects?

Generally speaking, it’s best to have retrospectives soon after a project ends, so that the experience is fresh on everyone’s minds. 

You don’t want to have them too soon after a project ends (for example, within a few days) to avoid recency bias. Team members may claim that the whole project was a crunch when really it was just the last two days of the project, and they’re still winding down from that experience. 

Then again, if you push the retrospective too far out, you risk it getting postponed or cancelled altogether. By establishing a general pace and cadence for retrospectives with your team, for example committing to having them one to two weeks out from a project ending, then it’s easier for the team not to let retros slip. 

Facilitating better insights

“Some of the best retrospectives aren't facilitated by the direct manager,” says Kyle. “It's hard to speak truth to power when you're telling your manager that you didn't think they did a very good job of getting the resources that you needed for the team, for example,” he says.

Whatever that person's role is, Kyle says that every good retro has to start by assessing whether everyone in the room trusts each other. “And then, does everyone in the room trust, or can they quickly build trust with the facilitator?”

A habit Kyle’s noticed over the years is that team leaders and managers tend to host retrospectives when some kind of breakdown has happened. Then, rather than guiding the discussion, they try to “incept the team” with an idea of what the problem or topic of the retrospective is. “I think it's hard to build trust that way, when you're trying to facilitate this conversation and steer it to a certain point,” he says. 

Here’s a practical list of Kyle’s tips, do’s and don’ts: 

• Front load your retro with the knowables. Do something along the lines of, "Hey, when we worked on this project together, we only had six weeks. That wasn't a timeline that we would have chosen. We knew coming into this and during it that we probably either needed more time or we needed to do something based on the amount of time this project had. So does anyone disagree with that?"
• Never ask, "Does everyone agree?” You have to frame it as, "Does anyone disagree?" because that gives folks a little bit more permission to be contradictory. That also gives the space to bring unique insights to the surface. 
• Explain the role and purpose of the facilitator. My biggest advice, especially if you’re the manager of the team, is to say, "Hey, I'm entering this conversation as a facilitator. That means I won't be giving feedback during the retro. I'm not going to give you my experiences. I'll put them in, in advance, and then let the team discuss them, but I'm not going to dive in and out." Because you can't facilitate and provide feedback simultaneously. 
• Ask senior team members to help facilitate in advance. Go to some of the more senior people on the team, that you hopefully already have a high trust relationship with, and ask them to help keep the momentum going by chiming in. Remind them that this doesn’t mean that you want them to own the conversation, but ask them to help out when it gets quiet either by sharing their experience or helping to call on some of the quieter members of the group for their insights. “In my experience, people who tend to be a little bit more quiet or a little bit more reserved are really great at noticing things,” says Kyle. “They're the ones that see everything going on.” 
• That said, don’t make retros a watch party for leadership. I think that one of the issues I see sometimes is when you invite a senior leader who’ll say, "I'm not going to talk, I'll sit off the video, but I just want to watch." Nothing squelches interesting conversation more than having an executive sitting in a room and being like, "I'm just watching." Somehow I feel like that's worse than actually participating.
  

Kyle says the act of drawing out good answers and facilitating conversations “is a great way for people who want to become leaders and managers to try it out.” So you can rotate who performs the role to give team members experience with it. However, Kyle says to keep your retro “playbook the same, meaning: have a couple of formats that you all generally follow.”  

Two frameworks for project post-mortems (and some tools, too)

There are two general frameworks that Kyle follows. The first he uses with teams that have a rapport and established dynamic, the second he tends to use with newly formed teams. 

Running retrospectives with established teams 

Kyle says that, if you have a team that has high trust and that's going to raise things up as they come up, without needing much prompting,” then he follows, what he calls, “the four Ls”. Which stand for: liked, learned, lacked, and longed for. 

In this framework you take a group discussion approach, and ask the team to share their experiences: What did they like about this period of work? What did they learn during this time? What did they lack? What did I really wish we had? 

As a facilitator, Kyle’s conscious not to end these discussions on a low note. “I don't like to end retros on what did you long for? I longed for more people, more support, more whatever,” he says. “I try to end on a positive note, so I’ll say something like, ‘Thanks everyone for all of your honesty. Now let's end.’ 

Running retrospectives with newly formed teams 

The second setup that Kyle uses with newer teams is one that he calls the “mountain climber scenario.” Kyle describes this exercise as: “You envision someone that's about to climb a mountain, or just finished climbing a mountain and you use analogies for everything,” 

“What are the ropes that you used? What are the things that helped the team during this process?”

“What boulders did you encounter? What unseen obstacles did you run into?”

“What was the weather? So, a mountain that's hard to climb is harder to climb when it's raining, versus when it's sunny out.” 

“What's the mood, the feelings?”

Tools for running remote retrospectives 

When it comes to tools, Kyle tends to be a bit of a traditionalist, funnily enough. “As someone who doesn't want to focus too much on the tools, I don't tend to use the various and sundry retro tools that folks have. I just like to stick with stickies.” 

That said, many of Kyle’s retros are remote these days, and so he still needs to rely on digital tools to manage the process, even the stickies part. 

“Most of my retros are remote. So we'll use stickies.io, which is a web collaborative format,” he says. “If you like the skeuomorphism of being able to move stuff around and organize them, which I tend to like a fair bit, that's the one.” 

Another one his team just started using is called TeamRetro, which Kyle says adds just enough functionality on top of stickies to help you lead a productive virtual session. 

Finally, never underestimate the power of sentiment analysis. Kyle says that most standup tools, like Geekbot, give you some kind of way to quickly poll the team on how they’re feeling. “Sometimes you swear at the bot,” he admits.

Kyle says to keep the options simple. Have people rate their mood or feelings by choosing either negative one (meaning they feel poorly), zero (they feel neutral), or one (they feel positively).

When you take this kind of poll at the end of a meeting or retro, or even throughout the lifecycle of a project, it can provide a pivotal layer of insight for managers and help them see when they may need to jump in to help a team or team member sort through issues. 

“There's something to be said about saying, ‘Hey, I'm a negative one," in this very safe way in this team meeting. And hopefully that helps bring you to a more solid, complete retro,” says Kyle. 

Final words on modern retros

“I think that the modern retro allows us to do more team building, more trust building, and achieve more understanding within the team than just talking about process,” he says. “We need to do the process side too, but there's multiple different tactics to do that, depending on where your team is at.”

“If you don't get a team to share what they're experiencing — good, bad, ugly — then fixing the process doesn't matter,” he says. “Because you'll just end up fixing superficial stuff.” 

At the base of it all, Kyle says the difference between modern and more traditional retros is that modern retros consider the whole person, team and organization. It’s not just about identifying efficient tools and systems, but asking yourself: “How can I get that unique insight that's going to make us faster, more cohesive, and more inclusive?” 

Thanks to Kyle, these tips are probably a good place to start.

This post is part of an ongoing series featuring snippets from Same Page — our event series that explores the design process. Explore In the Margin to see full-length recordings and more content on the design process.