A team retrospective is not just another useless meeting, if it feels that way to you, it probably means you’re doing it wrong; and this article is for you.
With more than 10 years of experience as a Software Engineer, I’ve had the opportunity to attend hundreds of team retrospectives, and let me tell you: it’s the most valuable meeting a team can have, if you know how to do it properly. 😏
Why is it important? 🎩
A retrospective is when a team can learn from its own mistakes, share gratitude, ask for help, celebrate and talk about new ideas. Do you already see the potential? 📈
Self-improvement 🔁
Do you see something in the team that could be improved or is slowing you down? Raise your hand. 🙋♂️
“What if?” 🤔
Do you have a new idea? Do you want to try something new, and want to get the team’s opinion on it? Go for it!
Celebration!! 🥳
Did your team achieve something, or do you want to say thank you to a specific person that helped you out? (making it in public is better 😉)
Reflection 🙅
The power of this ceremony lies in encouraging the team to reflect on past events like what went wrong, or what could have been better.
Important It is about continuous improvement, not blaming. 🙅🏻
In a safe environment we should aim to point our fingers at processes that didn’t work, not at people.
Team Psychological Safety
Important Psychological safety is a very important thing to have in your team, the aim is to make the people feeling safe. This should be your top priority, the sooner you have it in your team, the better.
Having people in the team who feel safe is one of the most important aspects of healthy team dynamics. A team that feels safe, will be transparent, honest, and they will take risks. During a retro, you want people to have the courage to speak up and address issues by discussing solutions and ideas. You want your team not to be afraid of saying “we should stop this” or “this is not working for us”. Without psychological safety, we can’t have all the benefits we mentioned earlier. If people don’t feel safe, your retrospective simply won’t work. I’m not going to cover this topic here, but you can definitely have a look at some articles online like:
- https://www.thoughtworks.com/insights/blog/product-innovation/psychological-safety-product-innovation
- https://www.ccl.org/articles/leading-effectively-articles/what-is-psychological-safety-at-work/
- https://psychsafety.com/about-psychological-safety/
Format 👾
Many people I’ve talked with believe there’s only one effective retrospective format
Which is completely false, changing retrospective format depending on your team situation is crucial to get the most out of this ceremony.
Retros should be fun and effective. Not all sprints or quarters look the same; so why should your retro?
Different formats?
There are lots of templates online that can be used, my favorites can be found here:
Setup
Let’s pick as an example “The good, the bad and the ugly” retro format.
Set up three columns respectively with
- The good 👍🏻
- The bad 🙅🏻
- The ugly 👹
Old action items 📜
Before starting the retro, spend some time reviewing the action items created in the last retro. Get updates on them, always remember to have them assigned to someone and add them to the next sprint.
Let’s start ⏲️
In this phase the team can start creating stickies on the board.
Each sticky should be in the appropriate column.
- The good: things that went well, and we should repeat, and do more of it.
- The bad: things that should have never happened, and we must get rid of it.
- The ugly: things that did not go so well, and we should look for improvements, turning them into something better.
Write each one so the team can easily understand its context at a glance:
- ❌: “Our process doesn’t work for me”
- ✅: “The code review process is complicated and difficult to follow”
- ❌: “Lack of privileges”
- ✅: “Couldn’t do the migration due to lack of privileges.”
This activity should last around 3–5 minutes. If the team isn’t very active, wrap it up earlier; if they’re engaged, give them an extra minute or two.
Clarification and grouping 🏘️
In this phase the whole team reviews the stickies and clarify them if necessary, and start grouping similar stickies together. Something that works well for me is drawing a large square to summarize each group of related stickies, like in the image
Voting 🗳️
Now it’s time to vote, each member of the team should have 2 or 3 votes, and votes should be anonymous.
If there is a group of stickies, votes go on the main group label, otherwise they go on the single sticky.
This activity should last between 3 and 5 minutes, nowadays most tools show when everyone has voted, or you can say to your team members to raise their hand on your call to mark that they have voted.
After that you can show the voting results.
Discussion 🎙️
Pick the sticky (or group) with the highest number of votes, and set 10 minutes for the discussion.
The aim of the conversation is to explore what happened, and address it through the creation of action items.
After timing out, the team can decide if they want to continue for 5 more minutes or stop. Repeat until the team is satisfied and there are action items for that specific topic.
The conversation should be started by the author, and the team should follow up the conversation, adding insights and thoughts.
Important If there are 5 votes, at least two or three people should be talking and adding something to the conversation; having just one person talking it’s not a conversation, it’s a monologue. 🙅🏻
Action Items 🪧
As introduced above, action items are produced by the team to address their issues, they should be S.M.A.R.T.:
- Specific
- Measurable
- Achievable
- Relevant
- Time-Bound
Assign each action item to an owner that will be accountable for it to be executed during the following sprint.
Important Adding an action item to the backlog and leaving it there won’t solve the issue, solving the issue will solve the issue. 🤯
Round of Kudos and positive things 👏🏻 🎉
Before closing the meeting, spend some time reviewing kudos and positive stickies, to end the retro on a good note. 🧘🏻
Common Pitfalls 👎🏻
Team members become spectators 🥱❌
When retrospectives are always facilitated by the same person (usually the tech lead or manager), the outcome tends to be the same every time: the team tends to get used to it, and the retro becomes “another meeting that could have been an email”. Team members become spectators. Instead of feeling that this ceremony is for them, they start seeing it as someone else’s responsibility.
Problem: Always the same person facilitating the retro 🙅🏼♂️ Usually the tech lead or the manager facilitates the retro, leaving the team out of this duty.
Solution: Rotate 🔁 Rotate the facilitator every 1/2/4 weeks, make the people responsible for facilitating the retro correctly and efficiently. Give them feedback about how to improve it.
Tip: Automatic rotation 🤖 Add an automatic bot to rotate the person who takes the facilitator role for a specific time-window.
Hearing always the same voice 🎙️❌
Common scenario, have a sticky with lots of votes, but we hear just one or two people talking for the whole (time-boxed) time. Generally, if a sticky has a lot of votes, it means several people in the team care about the topic and have something to say. My advice is to let the author start, and then call out someone else who added a vote to it.
Question: Anybody else? Does anybody want to add anything? Can we hear another opinion? Thoughts?
Different people might have different reasons to vote a specific sticky and some people are more silent than others, the benefit of doing this might be:
- We hear what the owner has to say
- Hear others’ opinions (they vote it, they have at least one opinion about that topic)
- Keep people engaged.
Problem: Cards with lots of votes being tackled by a single person 🙅🏼♂️ We have only one voice in the room.
Solution: Let other people speak 🗣️ Don’t let the author of the sticky be the only one who gives an opinion, ask the rest of the team who voted the card to speak up and add more about the topic the team wants to talk about.
Tip: Involve silent people Try to involve people who didn’t talk during the whole meeting, but don’t force them to do so.
Not time-boxing 🍅
As a facilitator the timer is your best friend, it is your duty to keep the meeting rolling and on-time, making sure that the important topics are discussed and that some action items have been created. To do so, you need to have time-boxed discussions. Whenever a discussion starts let’s set 10 minutes to talk through the topic, if at the end of those 10 minutes the team is satisfied you can move on, otherwise just ask about adding up 5 minutes more.
Question: What now? Shall we spend 5 more minutes on this topic or move on?
Do it just once, and focus on finding an action item, then move to the following topic, it brings lots of overlooked benefits:
- Force the team to focus on what really matters
- Keep the timing under control
- It allows tackling more important topics
Problem: Spending too much time on a single topic Spending most of our precious time talking just about one or two topics for the whole meeting
Solution: Time-box discussions 🍅 Set 10 minutes for each topic conversation, the aim is to find an action item. If 10 minutes are not enough, ask the team if they want to talk about the topic for 5 more minutes or if they are okay with the outcome.
Tip: Shared timers Try to use a timer that is visually shared with the team, (or just share your screen) so everybody is aware of the timing.
Public voting 🃏
Some people in the team have more influence than others, and this can easily harm a retro meeting. Within a team there are multiple dynamics, and we have always to remember that those dynamics influence how we interact and work with each other. So, to avoid having this hidden influence within our meeting, voting should be anonymous.
Only one person doing the grouping 🏘️❌
Grouping helps the team to clarify the stickies and to come up with something that everybody understand and can vote, don’t let one person doing the dirty job when the rest of the team just stay still, involve them into the process, ask questions and how to name things. Make them part of the process.
Talk about every single sticky on the board 😴❌
Voting helps to prioritize what really matters for the team, and those stickies should be discussed before the end of the meeting. If more stuff can be discussed go for it, but it’s not something you should tackle, especially if the retro runs over time. Take those stickies into consideration and move on, closing the retro.
Problem: We ran out of time We talked about less important stuff. The team lost interest.
Solution: Pick the top 3 stickies Pick the first 3 most voted topics and discuss them, it should be enough to tackle the important stuff. Close the meeting whenever you are done with them.
Postponing the retro because “we are too busy” 📉❌
Seriously, don’t. The retro it’s one of those meetings that if run well can help your team to move faster. ⚡️ A busy team can overlook important things that in that specific moment are making the team itself slower or less efficient. Reflecting over the sprint the team just had can make more evident what is not working, especially if the team needs to be fast.
Example 🏎️ During a car race, if you have a flat tire, don’t you change it because you don’t have the time to address it?
Waiting for the team/tech lead to have a retro 🪫❌
The retro is for the whole team, not for single individuals and the team shouldn’t wait for anybody to run it. Action items are assigned to team members, making them accountable for resolving them.
Problem: Only the tech/team lead can solve the issue ✋🏻 Can be that some issues can’t be solved by individual contributors, so what’s the point to have a retro if we can’t do anything about it?
Solution: Have action items 📝 The team can always discuss the issue, create action items about it and assign the tech/team lead to follow up offline or whenever that person is back.
No product people in your retro ☎️ ❌
In some companies product and engineering teams are two separate entitites which collaborate here and there, but never share a strong communication funnel. So what I’ve been seeing is engineering teams complaining about product people that never receive that feedback promptly or with the right context.
Problem: Broken feedback loop ⛓️💥 Product people are not participating to the retro. Most of the engineers think that the retro would be too technical for product people, and product people think that they can’t provide any value to the engineering team conversations.
What worked very well in my experience, is involving them to the team retros, starting with just once per month and then increase the attendances according to the feedback.
Solution: Retros all together 🔗 Start involving product people in the engineering team retros, start small and then increase the frequency if it is needed.
I’ve seen product people become more aware of team issues and their surroundings. Engineering teams felt more heard by the people they were supposed to be collaborating with. Thanks to the faster feedback loop, everyone felt that collaboration improved by an order of magnitude, understanding better the reasons behind certain decisions and processes that were affecting the team.
Conclusion
I hope that these tips help you understand how you can make the most out of the retro and why you should care about having it in your team as well.
I’m just an engineer: I’m not a good faciliator! 🙋♂️ Facilitation is like a muscle, the more you practice it, the stronger it gets. And think about it, AI can’t do it. 😏
Next time you have your retro, apply one of these ideas, and you’ll see how fast a good conversation can transform your team. 🤞🏻
Until next time! 👋🏻