Learning how to hold retrospectives
A few months ago I volunteered to help hold retrospectives in our cross-functional team. Up until then, we had a delivery lead hosting most of the retrospectives and from time to time a process designer would also come in and host retrospectives.
The thing is, while we were going through the motions of having a retrospective, including creating actions - I couldn’t see any improvement that resulted from having these retrospectives (there was no follow-through with the actions). After talking to the tech director about the possibility of helping host retrospectives, I also spoke to the delivery lead about it (who was more than happy to be relieved of that responsibility as he already had plenty on his plate).
The tech director lent me a copy of “Agile Retrospectives: Making Good Teams Great” to read and I asked him for some advice on hosting retrospectives before holding my first one.
My background with regards to Retrospectives
Before this project I had worked on several scrum teams that held retrospectives. I have spent more time working on projects where a dedicated scrum-master would hold these retrospectives but I had also worked on two teams where the Business Analyst would hold the retrospectives (as we didn’t have a scrum-master in those teams).
I had also helped organise and co-facilitate retrospectives before, but the other person had “taken charge” at these retrospectives.
Most of the retrospectives I had been a part of, in the past, were in-person, up until this pandemic started.
My goals in holding retrospectives
The most important part of the retrospective, in my opinion, is that it added value to the team. (I didn’t want to waste my team’s time on a meeting every two weeks where they feel like they could’ve done something better with their time).
But more specifically:
I wanted to create a safe atmosphere in which people could be open and honest about how the last sprint had been for them and where people felt safe enough to put forward their ideas on how to get better as a team.
I wanted to create tangible concrete actions, that we could follow up on, so that over time, we, as a team, could improve.
Preparing for the first retrospective
Since there had been retrospectives in the past, I did have a basic template to go off. I made a copy of the previous retrospective’s Mural board and then made edits to that. I then asked for feedback from one of the senior developers in the team and from the delivery lead - along with what hopes and expectations they had for this retrospective.
By this point I had read a few chapters of the Agile Retrospectives book, and had also skipped to some parts throughout the book (such as the activities sections). Ultimately though, I opted to keep the first retrospective fairly similar to ones we had before but wanted to focus on the actions and the communication about those actions (that is, the follow through both soon after the retrospective and then at the next retrospective).
For the discussions sections, I looked up how to create breakout rooms on Google Meet. Since we had 10 people in our team at the time, including me, I thought it would be easier to have discussions in smaller groups.
I also made a conscious choice to not participate in the retrospective. I didn’t want to risk influencing people’s opinions etc. or risk taking up more of the retrospective than necessary sharing what I thought about the past sprint etc.
Holding my first retrospective
To be honest, I don’t remember all the details in holding my first retrospective but I do remember explicitly telling the team that this was the first retrospective I’ve hosted solo and that I would like their feedback after on what worked for them and what didn’t.
I also remember sharing the agenda with the team and the goals for the retrospective (they were go over how the last sprint went, and create actions for us to focus on the upcoming sprint).
The retrospective itself ran relatively smoothly. The agenda looked roughly like this:
- Check-in
- Go over the last sprint using the Four L’s format by writing our thoughts then sharing with our team
- Vote on 2 topics we want to focus our actions on for the upcoming sprint
- Independently write ideas on how to address those topic
- In breakout rooms share our ideas
- Someone from each group shares ideas for the topics chosen
- We vote on the actions we want to take
- We assign people and deadlines for those actions
- Checkout
Getting feedback from my team
Looking back, I probably went a bit over the top with this.
I got some great, extensive feedback from one of the senior developers (the one who helped me prepare for the retrospective) and from the delivery lead. I also sent out an anonymous survey to the team with questions like:
- Did you get value from the retrospective? (scale of 1-10)
- Do you feel you were able to honestly share how the last sprint was for you? (scale of 1-10)
- What was the most beneficial part of the retrospective? (short answer)
- What would you improve? (short answer)
If that wasn’t over the top enough, I also DM’d everyone (yes, I’m super weird….), asking for their thoughts and what they wanted to see in future retrospectives.
Some key findings were:
People appreciated the actions and having a commitment to getting better as a team
There was some disagreement with the lengths of time assigned for various activities
What I’ve learned
I’ve learned it’s surprisingly difficult to manage time at retrospectives - sometimes discussions would go on, and making a judgement call on when to let the discussion continue or if it’s going on a tangent and you need to park the discussion.
Feeling like you are properly hearing from everyone, fairly, is something I still need to focus on. Just like any team, we have some more outspoken people and some quieter people - while I don’t think it’s bad to have a variety (I think it’s amazing actually), I do think it’s important that if anyone has something to say - they are given the opportunity to say it.