Get the Most Out of Your Internal Retrospectives

Retrospective meetings are one of the most valuable tools to a successful software development project. They provide an opportunity to reflect on processes, communication, tools, and plenty of other things. The right forum for voicing concerns or #praise is not always obvious when you’re in the weeds of a project. This exercise aims to create a safe space where professional candor and feedback is encouraged.

There are several situations where retros can be employed: after sprints, at the end of a release cycle, at the conclusion of a one-off website build, and more. But in this article, I’ll cover something slightly different: a recurring full-team internal retrospective.

Given the size and scope of our work for Project Beacon, we’ve implemented tri-weekly retros. Every three weeks, we meet as a team (usually between 10-15 people) for a one-hour exercise and discussion about the project: processes, pace, thoughts and feelings, and general open conversation. If there is a concern about burnout, this is where it comes up. A pain point in communication? That’s the time.

Below, I’ll share what a typical retro process looks like for the Project Beacon team, and why we’ve found it successful.

The Meeting Philosophy

The idea here is to both discuss changes that could be made, but also to celebrate wins. Any retro where the conversation is solely around improvements is a failure. An environment where both respect and candor are prioritized is the right way to cultivate this.

Having an established and regular retro cadence helps in many different ways:

• It ensures no pain point goes too long without being addressed
• It lets us feel more comfortable about introducing new processes in the middle of a project, knowing that we’re going to reflect on how they went during the retro
• It can be a refreshing break from project work
• Being able to contextualize team sentiment with what features are currently being developed is a good data point to have when planning for similar upcoming work

The Meeting Structure

The meeting is centered around three different topics:

• What should we KEEP doing?
• What should we START doing?
• What should we STOP doing?

As the one leading the meeting, I usually open up a Whimsical board for people a few days beforehand so the team can add their thoughts whenever they have a free moment. However, “a free moment” is a hard thing to come by in software development, and you’re usually not in feedback mode when you’re knee-deep in your code or design, so most of the time the board stays empty until we meet—which is fine.

The Beginning

For the first 5-10 minutes, everyone takes time for silent reflection and to add their own thoughts to the appropriate category.

We use Whimsical's sticky notes feature for this to capture ideas, with each one corresponding to a single thought or piece of feedback. Each participant is assigned a color, and can add as many sticky notes of their color as they'd like to each of the three sections. Knowing who said what saves a bit of time when we transition to discussion mode (more on that later). Each sticky note should include a very brief overview of the topic, and then comments can be added within it if more context is necessary. But you want to be able to see everything at a glance.

While the rest of the team is doing this, I look for topics that multiple people are indicating they want to talk about and jot them down so that we can cover those first.

The Middle

To kick it off, I’d recommend appointing someone besides you to take notes. After 10 minutes or once everyone has nothing else to add, start a screenshare of the Whimsical board or of the tool you’re using. As you introduce the topics, I’ve found that sometimes sharing a thought about it yourself can help get the discussion going. If you don’t have any or don’t think that’s useful in this case, it’s better practice to ask the team membee who filed the card to give a little context rather than just saying “Does anyone have thoughts about this?”

As you make your way down the list, be mindful of time, and keep things moving. An hour is actually not very long for this exercise. You’ll most likely discover that running this meeting is a balancing act between wanting to cover as much as possible, but not wanting to stifle good discussion as it’s happening.

Once we’ve covered all the commonly requested topics, you can either pick out one you think is relevant to a bunch of people, or ask if there’s a single card in the column you’re on that a team member wants to discuss.

Some people just listen, some are very active, and some only chime in when it’s about something they’re working on. All of this is fine—the point is that it’s a comfortable environment, and people should do what they want to get the most out of it (although I would suggest occasionally prompting someone who you never really hear from).

The End

The bulk of the meeting is the discussion, so at the end I usually just thank everyone for their time and say when and where you’re going to share takeaways. Maybe a joke if I feel funny that day.

After the Retro

An important part of the process is the follow-up message. It’s sometimes challenging to figure out how to compose this. You’ll primarily want to share key takeaways and action items, but of course, not everything fits neatly into those categories—and you don’t want to post a jumble of notes that no one is going to read. To be honest, I haven’t found a perfect solution, but I tend to split it up similarly to how we structured meeting:

• Keep Doing - What did we discuss that we agree is a smart and effective thing we’re doing that we should keep up?
• Start Doing - What’s a thing we either don’t do enough of or don’t do at all that we should all try to enact, or at least be aware of?
• Stop Doing - These parts of the project aren’t really working or need improvement.
• Immediately Actionable - These tasks can be done right away. They should be assigned out to someone to take on as soon as they can.

You’ll see in this screenshot that Immediately Actionable items come from one of the other three categories.

A suitable-but-not-perfect philosophy is that if something is a recurring practice (eg, “Keeping ticket progress updated” or “Pairing”), it’s not technically immediately actionable. It’s more there as an omnipresent reminder that those are areas we should try to work into our day-to-day routines, rather than a task with work that needs to be done and can be Officially Completed ™. You can see the distinction there between the Stop Doing item “Too much on the project board” and the Immediately Actionable “Trim down the project board.” Also, “Plan for including test coverage time in sprints” could be considered a Start Doing item, but I was in the midst of charting out the sprints and it seemed like updating the template would take care of this feedback.

The primary lesson here is to do whatever you feel is appropriate so that takeaways don’t just float in the ether and nothing is ever done about them after they’re discussed in the meeting.

Conclusion

Just like most parts of your project, the process of planning and leading internal retros should continue to evolve. Feedback about the retro is pretty meta, but useful—again, the goal is to create a space for more than just one-off discussion.

If you hear that your team isn’t getting much out of them, change the cadence, structure, or something else to improve the experience for everyone.

Sharing is caring—and you can make that a reality for your project.