The Mechanics of a Retrospective

Nov 14, 2022

Sean Beckett

See the previous blog post, “Retrospectives: An Essential Ceremony” for an overview of the goals and philosophy of retrospective meetings. In this second of three blog posts, we lay out the basic structure and process.

Who to invite

Retrospectives should involve the entire team. If people are in the planning meeting, they should be in the retro. If they were involved in the incident response, or if they are on the client team, they should be in the retro. Excluding someone from a retro meeting sends a signal that their involvement is considered minor and their feedback is not relevant. This isn’t necessarily wrong, but it should not be communicated accidentally.

That said, retrospectives do not scale well. They are very similar to classrooms, in that ideal sizes are 6-12. They can be effective with groups up to about two dozen, but at that size some folks do not participate eagerly and it is challenging to identify them and find space for them to contribute. Retros with large groups usually amplify the voices of those most likely to speak up, and those are generally the opinions that least need to be amplified.

Retrospectives should include people with a range of experience, perspectives, and influence, if for no other reason than diverse teams are more successful in the long term. This can mean that a facilitator with a junior individual contributor role is asking an experienced senior leader to wrap up their thoughts, or to use more “I” statements. If this is hard for the team or the participants, that points to a lack of psychological safety in the team and should be addressed outside the retro context. In the meantime, it is okay to restrict retros to the folks that can collaborate well, but ultimately everyone should be able to be a good participant and contributor to the retro, and the team should strive to get back to that ideal.

Basic Retro format

  1. Collect discussion topics
  2. Discuss the topics
  3. Capture action items

Collecting discussion items

It is important to have a reasonable list of items before the retro discussion starts. Retro items can be added during the discussion phase but this can distract from the ongoing conversation.

A retro should have at least a few items per attendee. That gives enough discussion material to have a productive meeting, and it means that probably everyone is contributing to the retro items and the discussions.

It often works well to spend the first ~5 minutes of the meeting writing down retro items. This is best done in a public manner, so that everyone can see what’s being added. This prevents duplicative entries and provides inspiration for additional entries.

For in-person retros this is as simple as giving everyone a dry-erase marker and asking them to write items on the board. The columns should already be on the board so that folks can self-organize their items.

For remote retros the facilitator should have already shared a collaboration document where folks can enter their retro topics. At the beginning of the meeting the facilitator can share their screen while asking participants to add entries.

Collect before the meeting

Collecting the retro items only at the beginning of the meeting often leads to recency bias. We talk more about what happened yesterday because that’s what came to mind at the beginning of today’s meeting, and we forget what happened before yesterday. Collecting the retro items asynchronously before the retro helps avoid this recency bias, and means we can launch into each retro with a shorter brainstorming session at the beginning, leaving more time for discussion.

A simple pattern is to create a spreadsheet with the three columns and an Action Items and Owner section. The title should have the date of the retro meeting so folks remember when these items will be discussed. When the team is invited to collaborate on the sheet, everyone can add in items as they occur and recency bias is significantly reduced. A recurring reminder in Slack or another collaboration tool can be helpful to prompt folks to enter items throughout the week rather than just before the retro.

This also provides an easily shareable collaborative artifact for remote teams. When collecting things this way, people should write their names next to the retro item so that the facilitator knows who to ask for clarification on each item. It also allows the facilitator to defer or skip retro items entered by folks who aren’t present at the actual retro.

Basic three-column model

😄 | 🫤 | 🙁 — Happy, Meh, Sad — Keep, Discuss, Change

A retro template in GDocs.

The three column model is the default choice for retros. It is flexible enough to allow for a wide range of discussions, and it is structured enough to organize our thoughts. The definitions of each of the columns can be team specific, and may even vary from retro to retro. They are loose and relative, and only meant to express an initial categorization of the discussion item.

The left column is often headed by a smiley face emoji. This can be thought of as the Happy column, or the items describing practices we want to Keep or Do More of, or possibly Celebrate. In general things in this column are positive, and the person adding the item wants to acknowledge our accomplishments. Because these are things that are working well, they tend to generate relatively few Action Items, and the discussion of them is often as simple as a round of applause by and for the group.

The middle column is headed by a neutral face emoji. This can be thought of as the Meh column, or the items describing practices that we are Concerned about or Confused By, or that we want to Discuss with the group because we suspect there might be a lack of alignment or shared understanding. This column is where we put things that don’t feel great, but we aren’t sure if they are necessarily bad or wrong.

The right column is headed by a frowning face emoji. This can be thought of as the Sad column, or the items describing things that we want to Change or Stop Doing, or that are Not Useful. This is where people identify the things that are making life more challenging than it needs to be. For most retros this will be the column that generates the most Action Items, as these are the very practices that most need iteration.

At times the same item will show up in multiple columns, with two people having different perspectives on the same process or experience. This is an exciting signal. It often leads to very productive discussions, as it identifies an area where the team isn’t aligned or where the impact is not shared equally.

Prioritizing topics

Teams tend to get into a rhythm where the number of retro items raised and the time spent on each fills up the meeting without neglecting any of the items. This is not a guarantee, and there will be meetings where the number of topics on the board clearly cannot be covered in the time allotted.

The facilitator’s role is to create good discussions, not to determine what topics the discussions will cover. There are a number of ways to equitably produce a priority ordered list of what to discuss. This has the benefit of providing a structure, as well as allowing participants to predict what will be next and what may not be covered.

Dot voting

After the items have been added to the board, we crowdsource the items of greatest interest to the group. The facilitator gives each participant a fixed number of votes and a time limit for adding them. A simple default is three votes per person and one minute to vote. Each person then adds a dot on the whiteboard next to the three items they most want to discuss in the meeting. For remote tools this can be a more challenging pattern but it can work to add an ‘x’ or similar marking to the spreadsheet cells.

When the minute is up and each person has spread their votes, the facilitator counts up the votes for each item and goes through them in descending order of votes received.

Note that there are no rules for how people vote, other than they should stay within the vote limit. Placing no votes at all is perfectly valid, as is putting all your votes on one item, or voting only for your topics, or never voting for your own topics. This is a gauge of interest, not an election, and therefore the only really bad pattern is to amplify your own voice above others by voting more times than allowed.

By rotating nomination

Another pattern that works well for smaller retro teams is to give each person in the room a chance to nominate the next item for discussion. This ensures that each person has an opportunity to discuss their top priority item, and can be repeated for as many rounds of selection as is needed. Randomness is desired, so ordering nominators by position in the room or in the video app grid is preferable to something like a popcorn pattern, where each person nominates the next, or having the facilitator pick people themselves. Anything relying on human ordering will have some bias, and that may lead to feelings of exclusion or favoritism.

By row

A simple way to order the discussion topics is to start at the upper left item (a Happy column entry), and then move on to the top item in the middle column, then the top item in the left column, then back to the next undiscussed item in the left column, and so on. This ensures that the tone of the discussion varies and that many items are covered.

It can mean that later entries are left out due to lack of time, and they may be of more overall meaning or interest to the group. Thus, the by-row pattern makes the most sense for a fairly sparse retro board when we are confident all items can be discussed in the allotted time.

By column

Another simple way to order discussion topics is exhausting each column in turn. This works best when at least one column is sparse, and works best when there are two sparse columns, leaving the third to drive the bulk of the discussion. The facilitator picks the least populated column and goes top to bottom through the discussion items in that column. Once finished, tackle the second most populated column, and then finish with the densely populated column. It may be reasonable to use another prioritization technique at this point to ensure that the topics of most importance are discussed.

Typically, this format makes sense when there are not very many middle or right column entries. The left or happy column entries can almost always be covered quickly, and then the most empty of the Meh or Sad column can be covered, leaving the rest of the meeting for the dense Meh or Sad items.

This can be draining as the team tackles one challenging discussion after another. By-column is probably not a good pattern for teams new to retros, or for a novice facilitator.

Discussing topics

Most of the allotted time should be spent discussing the topics people wrote down on the board. The discussions should be collaborative and wide-ranging, and facilitators generally shouldn’t steer them much at all unless the rules of the meeting are being forgotten or there’s a time concern.

The facilitator’s biggest role is to keep the team moving through discussion items. When a discussion topic feels resolved, or when an Action Items has been identified and assigned, it is time to move to the next topic. Similarly if a topic is generating lots of commentary but not much new or different, it may be time to move on. The facilitator should acknowledge there’s more to say but we have other topics to cover, and if we’re not heading for an Action Item perhaps the discussion is better taken elsewhere.

Facilitator reads

To begin each discussion, the facilitator reads the topic aloud, exactly as written. This gives a neutral voice to the topic and indicates to the group that the discussion is moving on. Acronyms can be expanded but in general the facilitator should not embellish what is written, as that exerts their own influence on how the topic is perceived.

When reading their own topic submissions, the facilitator should read the topics exactly as written before then describing them as the submitter. This properly separates the two roles for the audience.

Submitter describes

Once the facilitator has read it aloud, the person who wrote the topic gives a little more explanation of the meaning and intent behind the entry. In most cases a few sentences is enough.

Group discusses

When the submitter has given their reasons for suggesting the topic and clarified any questions, the group should discuss their thoughts and feelings about the topic. This is when the rules of the meeting are most important. One speaker at a time, with everyone focused on listening to them and hearing what is actually being expressed, and respecting that everyone is trying to improve the team.

Facilitators can participate in the discussion, but as someone with a privileged position in the meeting they should be careful not to step on anyone or take a disproportionate amount of time. If the team lead is also the facilitator, it is even more critical that they mostly listen and contribute only when it is truly meaningful.

Calling Time or Time-boxing

Some discussions can go down rabbit holes or get into circular arguments, or they may trigger raw emotions and become unproductive until people can calm down. When the conversation is no longer about clarifying ideas or suggesting action items, the facilitator should step in to redirect it to some form of closure.

When a natural endpoint seems unlikely, the facilitator should call for a time limit on further discussion. This should not happen out of the blue, but as a series of warnings. “We’ve spent 5 minutes on this already, let’s take another 2 minutes to wrap it up or identify any Action Items.” Give additional warnings with one minute left and when the time limit is reached. It is important not to cut someone off in mid-thought, but also do not let the last person continue to speak beyond their current sentence or two.

This is a delicate balance for the facilitator, but others in the group are likely experiencing fatigue or anxiety with continuing to discuss an unresolvable topic. Look to the room to provide some passive or active assistance in moving on to the next topic.

If the topic isn’t closed and no one has identified Action Items, the facilitator can simply call for a targeted discussion or meeting some time in the future. Add an Action Item for someone to schedule a later talk and then move on to the next topic.

Action Items

Meaningful Action Items are a primary goal of retrospectives, along with creating shared understanding on the team and giving participants influence over the team’s direction. Action Items are the output that drives the outcomes, and good Action Items are key to iterative improvement.

Action Items should be tactical rather than strategic, and achievable before the next retro. They should have a clearly defined owner, and they must be periodically reviewed to ensure accountability and progress.

A retro may produce two action items or twenty, it depends on the group and the discussion, but a retro without action items may indicate the conversation didn’t go deep enough.

As discussions progress, any member of the team may call out an Action Item. The facilitator should seek broad approval from the team, and if there are no strong objections, add the Action Item to the list.

Single discrete tasks

Action Items should be bounded, tightly scoped, well defined, and achievable.

“Create a Persona list” is not a good Action Item. It describes an activity that takes place over a long stretch of time. It is a matter of opinion when the list is good enough, so people can disagree whether the Action Item is done. The activity is highly collaborative, and putting an Owner on it may unfairly burden them with responsibility for the outcomes.

“Schedule the first Persona definition meeting” is much more appropriate. The meeting is either scheduled or it isn’t. There’s no disagreement as to whether the Action Item is done or not. Setting a meeting is a simple task that appropriately belongs to only one person. By limiting it to the first meeting, we keep the goal tactical and short-term.

Action Items are about the next step, not the whole journey. We need to make sure the process starts, and then we iterate in our future planning and retro meetings.

Well-defined owner

Every Action Item should have a single owner, or if multiple owners, it should have a single point of contact. This ensures accountability. Action Items without an Owner are pointless.

The facilitator should write the owner next to the Action Item on the retro board. If no one volunteers, the team lead may nominate people as appropriate, or the group may decide the Action Item is not valid and remove it. Ownership can be applied when the Action Item is first written down, or at the end of the meeting when Action Items are being reviewed. Often folks will claim ownership at the time an Action Item is proposed.

Don’t fall into the trap of usually assigning Action Items to team leads or those with organizational authority. That pattern just reinforces their influence instead of spreading it through the team. Action Items are an excellent way to build experience for individual contributors and more junior folks, and to give them a voice in the team’s direction.

Periodic Review

Setting an Owner is necessary for accountability, but not sufficient by itself. The team must periodically review the Action Items to encourage progress and learn about the results.

This review can take many forms. Action Items from previous retros can be reviewed at the end of the next retro meeting. Action Items can be reviewed as an agenda item in a planning meeting. Action Items can be periodically broadcast in the messaging platform or written on an information radiator in the office.

The only sure way to fail is to forget about them. If Action Items are brought back up at least as often as retros are held, they should receive enough attention to remain valid. If not, that’s an excellent retro discussion topic!

After the Meeting

The facilitator should ensure the Action Items and Owners are properly recorded in whatever format encourages later review and broadcast them to the team. If there were particularly emotional moments, people or team managers may want to check in with folks to see if further support or discussion is needed.

Part 3 coming soon: “Retrospectives: Sustaining the Practice”

Read More Like This

Interchaintest v8.1 Release Notes

Interchaintest v8.1 Release Notes

Feb 06, 2024

Local-Interchain: Launch Private Testnets for Rapid Development

Local-Interchain: Launch Private Testnets for Rapid Development

Nov 28, 2023

Sunsetting the Public Voyager API

Sunsetting the Public Voyager API

Sep 05, 2023