Retrospectives: An Essential Ceremony

Nov 02, 2022

Sean Beckett

Retrospectives are one of the fundamental ceremonies for iterative work. Forward-looking planning ceremonies are extremely common and widely understood to be necessary for project success. A retrospective is a way to review and assess the assumptions and goals from our planning efforts and close the feedback loop.

Retrospectives are how we improve the way we collaborate and create a shared sense of ownership and cohesion around our practices, processes, and pain points. They are a direct application of the 12th principle behind the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Goals for Retrospectives

Retrospectives are a ceremony that helps us celebrate our successes, learn from our mistakes, and uncover where we need further discussion or research. We come together as a group in a spirit of radical candor and psychological safety to learn and share how things have been going over the interval since our last retro.

Retrospectives

- acknowledge what has been working well

-- so that we can do more of that

- uncover areas where there is confusion or lack of alignment

-- so that we can share a better understanding

- describe what has been painful or unproductive

-- so that we can find a better path

What groups should use Retros?

Any group with a recurring planning meeting should probably also hold regular retrospectives. This maintains actual feedback loops or closed cycles instead of serially connected wishful-thinking plans. Full circle patterns are a hallmark of healthy communication patterns. Without reflection, we don’t actually validate or correct what was originally said.

Identifying a facilitator

Retros provide the most value when everyone is an equal participant in the outcomes. There should be a meeting facilitator to keep things on track, but that needn’t be the same person every time, and it can quite easily be the most junior person on the team, as long as they are comfortable with the retro format.

Retros run best when the facilitator is aware of the team’s day to day challenges and tasks and understands their jargon and shorthand. Outside facilitators can be very useful if there are particularly emotionally charged topics to discuss, or if the team leaders find it difficult to create an atmosphere of equality in the room.

In general, teams with reasonably healthy psychological safety should have a facilitator from the team itself. This can be the team lead as the practice gets going, but once retros are well established, rotating the facilitation through the group helps build a sense of shared ownership and empathy for how best to participate. Some folks may be very uncomfortable leading the group, so it should never be a requirement, but it should be a goal for everyone to facilitate some of the time.

Rules of the meeting

It’s good to start the first few retros with a review of the meeting guidelines. These guidelines and commitments create an environment that allows for frank and honest discussions while also keeping things emotionally safe for everyone. If folks cannot follow these guidelines it will usually erode the effectiveness of the retro. When people slip up in the meeting the facilitator should gently remind the room of the commitments we made to each other.

Facilitators and people managers should address any repeat infractions in a kind but direct manner after the meeting. Treat a violation of retro rules as similar to any other disruptive workplace behavior, although generally the negative impact is more contained.

No multi-tasking, no external devices

Always give your full attention to the speaker. This is a collaboration and requires complete presence from everyone or the impacts are significantly diminished. If our attention is divided, the current speaker is being short-changed, and we are not listening deeply enough to be changed by their perspective.

Only one speaker at a time

No side conversations, and if people have something to add or clarify please share it with the entire group. Similar to external devices, violating this guideline divides the attention of the group and prevents deep shared understanding.

Speak from the “I” perspective

Use sentences with "I", not "you". Talk about your own feelings and impressions, not what you project onto others. Instead of “you didn’t try hard enough” say “I feel I put in more effort than others.” Instead of “you don’t understand” say “I don’t feel heard.” This is a very challenging thing for most of us, and we may slip back into “you” statements under stress. A good facilitator helps us reword these statements into “I” sentences.

The group can often help with this, as well. People less emotionally attached to the discussion can often see the neutral way to word the statement, and folks should help each other find a way to communicate clearly but without blame.

Assume good intent

Remember that disagreements are most often from honest mistakes or different perspectives, not maliciousness. Rarely is someone truly trying to attack or sabotage our ideas (and if that’s happening the team has bigger issues than retro behavior!) Instead, assume that everyone is honestly sharing their best opinions. If they don’t line up, most likely one or both of you are missing something that would allow you to empathize with the other’s position. We won’t always agree on everything, and a diversity of opinions is important, but no opinion is more valid or true than another.

Leave your hats at the door

Don't bring organizational hierarchy or roles into the discussion. All viewpoints are valid, even if they don't come from designated experts or influencers. No one should have more of a voice in the retro just because they are a manager. Simply because someone contributed more to a project doesn’t mean their thoughts about that project are more valid or important. They may be more informed, but often an outside perspective is helpful to see the overall impact.

If someone is making statements that come from a place of authority, or trying to sort opinions into truth and untruth or valid and invalid, the facilitator should remind them that we’re all equal in this room, we’re all bringing our best, and any disagreements are more likely to point to a mismatch in perspective or expectations. An expert should be able to meet others where those people are, not dictate that the other person’s feelings are invalid until they can meet the expert at their level of understanding.

Listen deeply enough to be changed

Actively listen to what's being said rather than assuming you already understand or know what the speaker means to convey. Allow your assumptions to be challenged directly and consider that you may be the one with the less informed or minority opinion. If we assume good intent, we can accept that others have things to teach us and that we may be learning as often or more than we are teaching.

No attribution or sharing outside the room

Don't share what was said in the retro with others, unless you have permission to do so. Participants must feel safe to share honestly and without concern that there will be retribution or external consequences for what they say. Before someone in the retro can express a negative opinion of an external person or team, they must know that the room will keep their confidence. Don’t gossip about your retros, treat it like a therapy session or AA meeting or a confessional. What’s said in group stays in group.

Anti-goals for Retrospectives

Groupthink

Retros should avoid becoming self-congratulatory hype sessions where we only tell each other how awesome we all are. Critical feedback has to include areas of improvement or it cannot create meaningful change.

Conversely, retros should not become complaint sessions where people rant or unload all their pent up frustrations. Retrospectives are about honestly sharing what is working or not for each individual, so we can identify whether it is shared by the group. Individual insights are the starting point for retro discussions, but a consensus understanding is the goal.

Planning or Scoping future efforts

Retrospectives should not get into discussions about next steps or future plans, except to identify and assign Action Items. The “how” of the Action Items shouldn’t be part of the retro. For example, “spike on foobar framework” is a reasonable retro Action Item. Once an Owner is assigned, the retro discussion should avoid any more talk about the foobar framework or how the spike might proceed. The discussion can return to the original topic that prompted the Action Item, or move on to the next topic on the board. People with opinions or thoughts for the Action Item should follow up with the Owner of that Action Item after the retro meeting.

Rigid structure

Retrospectives are a more improvisational meeting than most, since we can never know beforehand the mix of topics to discuss. The meeting needs to be flexible to allow for the conversations to go where they need to go. Retrospectives are also collectively “owned” by the participants. There isn’t a single role or person who benefits or determines the structure. The entire team should feel empowered to take the retro where it needs to go.

This doesn’t mean retros are a free-for-all or completely unstructured. It means the structure is there to encourage the dialogue, not control or constrain it.

One-way feedback

Retros are not about giving the team lead or senior manager a platform to seek validation for their decisions. Leads should trust that meaningful feedback will surface naturally. If their decisions aren’t showing up in the Meh/Discuss or Sad/Change columns then presumably the team is okay with those decisions. (Leaders seeking validation may consider having an Anxiety Party to expose and contextualize their concerns.)

Next: “The Mechanics of a Retrospective

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