In my time as a developer, I've seen all my teams adopt practices from the Agile methodology. This included the adoption of many "agile" meetings - standup, backlog grooming, sprint planning, and retro.
When I first heard of the idea of having a retro meeting, I was hesitant. I remember thinking "What is the point of blocking out this time that could be spent coding?" I quickly changed my opinion after attending a few retros. I learned how important it is to create a dedicated space for team feedback and how team health can be impacted if this space is not allocated.
π€ What is a Retro?
Retrospective meetings are a team-wide meeting in which everyone can feel free to give their feedback on the running of the team since the last retrospective. There is usually dedicated time to discuss what went well and what could improve. At the end of these discussions, action items are taken by team members to improve the team flow. These action items can be reflected upon at the beginning of the next retrospective.
β Before I start discussing my thoughts, I want to note that there is no "correct" way to run a retro. I've seen different teams use different styles successfully depending on their communication styles. Flexibility is key here.
The Importance of Feedback and Vulnerability
Let's examine the "why" of a retro. Why do we implement team feedback sessions and what are the important learnings that come from them?
In this article "How to Build Confidence While Showing Vulnerability" the author Dan Cable notes a few benefits that come from having open team communication. The first is that open discussions normalize and encourage learning. If we approach retrospectives from a "what can we improve on" mentality, people will feel more likely to say what is working/not working for them. People will feel more comfortable exploring alternatives in order to find the best solution to a team problem.
Another benefit that Cable notes with displaying vulnerability in a leadership role is better team engagement in other aspects of work. If the team feels heard, they are more likely to be excited about their work and show better cooperation.
π How Should Retros be Run?
1. Plan your goals
Before running a retro, it is important to do some preparation to make the best use of your team's time. You should start with a set of goals in mind to better customize the retrospective to your team's needs.
In my retrospectives I like to check our team "health", encourage everyone to give feedback, and inspire teammates to take ownership of tasks. These goals shape the way I run and participate in retrospectives as I want to make sure everyone feels heard and included.
2. Schedule!
Retros need to be frequent enough that people remember what they want to talk about. If over a month passes, team members may forget important items or feel that they cannot talk about anything specific because the retro spans such a broad length of time.
I recommend scheduling a retro every two weeks for an hour. This frequency does not have too long of a gap between meetings without draining too much time away from development.
3. Make sure EVERYONE is heard
One of the reasons I like retros so much is that everyone is given a chance to participate and give feedback. Every team member should be encouraged to share their thoughts on how the team has been doing (both positive/constructive criticism). I have found that in this situation some team members may feel shyer so it is important to encourage everyone to give honest feedback without any repercussions. If you are a manager leading the retro it is also important to prepare YOURSELF for feedback and not become defensive if someone says something critical.
4. Actually do your action items
It is one thing to voice concerns and opinions about team health, but it is another to actually implement the ideas that arise from the retro discussion. Action items should be clearly marked on the retro board and can be turned into Jira tasks or noted in public channels for further discussion. Everyone on the team should be aware of and responsible for these tasks.
If you are finding it difficult for the team to take responsibility for these tasks, then you might want to assign "task leaders" that will keep track of progress. Then at the start of every retro review last week's action items. Was progress made? How is the implementation of this action item going?
Good luck and have fun planning your team retros!
TLDR:
- Retrospectives are an important part of team health and maintenance and should be prioritized
- Make sure to plan your goals for the retrospective
- Follow through on your action items!
Finally please let me know your thoughts! Have you had successful teams that did not use retros? What do you think is the most important "health check" a team can do?
Resources used:
Cover art - https://www.vectorstock.com/royalty-free-vector/retro-neon-city-background-neon-style-80s-vector-22323112
How to Build Confidence About Showing Vulnerability - https://hbr.org/2022/07/how-to-build-confidence-about-showing-vulnerability
Retro definition - https://www.atlassian.com/agile/scrum/retrospectives#:~:text=A%20retrospective%20is%20anytime%20your,retro%20on%20just%20about%20anything!
Top comments (0)