Some Developing Thoughts about Facilitating a Retrospective

I recommend reading this post first. I received lots of insightful and thought-provoking feedback on my first post about retrospectives from several of my amazing colleagues. I'm excited to record a bunch of it here and update some of my thoughts. Pretty much everything written in this blogpost is directly from or inspired by my wonderful colleagues! All the credit goes to them.

---

First, I want to go over the steps I compiled in my original post--the steps for facilitating a retrospective. Updates/changes are in red. (Remember, these steps are written for a Team Lead intending to facilitate the retro.)

Step 1: Set up the retro board at the start of the sprint.

Step 2: Put the retro board link somewhere very accessible. Keep it there for the entire sprint.

Step 3: Throughout the sprint, give the team regular reminders that the board is always open and instructions on where to find it.

NEW Step 4: During the sprint, follow up on the actions that came out of the previous retrospective.

In the Sprint Planning meeting following the last retrospective, where we decided what work we would commit to in the current sprint, time/resources should have been allotted to these actions. Complete whatever actions were assigned to you (if they are expected to be completed within this sprint). Check that your team members are progressing with whatever actions were assigned to them. If they are blocked, try to unblock them (i.e. be a Team Lead). I am kind of thinking that maybe it would be good to review the retro actions each morning in the Daily Scrum, just like we review the in-progress work.

NEW Step 5: During the sprint, be thinking about whether anyone additional should be invited to the retro

Maybe there was someone from a different team or from the business that the team worked with a lot in this sprint, and we might want to extend an invitation to the retro? Or would that be like a "stranger" coming in to our "safe space". Maybe the safe and trusting environment of the retro is something that is created over time and inviting relative strangers in disrupts that safety?

NEW Step 6: To begin the retro, display an agenda.

I think this is a really good habit for starting any meeting. It sets expectations. It removes cognitive load from those attending the meeting. It's also great for any new joiners! The agenda will look something like this: 1. Review rules of engagement 2. Review Team Agreements 3. Review Actions 4. Write retro cards 5. Read shout-outs 6. 30 minute break 7. Grouping 8. Voting 9. 10 minute break 10. Discussion 11. Review big picture

Step 7: At the start of the retrospective, repeat the rules of engagement (concisely).

Step 8: Review previous Team Agreements.

(In my original post, I wasn't sure where to put this step.)

One of my colleagues pointed out that if there are a lot of Team Agreements, it might not be realistic to review them at the beginning of every single retro (this point was made by James Sawh - an amazing Business Analyst that I worked with for a few months). I think James is 100% correct. I could see this being really un-engaging and unnecessary, especially if there are a lot of team agreements. If this were the old days (pre-COVID), I would say that we should post the Team Agreements all over the walls of the office near where the team sits. Or on the backs of the stall doors in the bathroom. Or things like that. But those types of solutions don't really work anymore. I suppose I could encourage my team to take 10 minutes out of their day to read over the Team Agreements every now and then? Or maybe start the retro with some fun and engaging way of reviewing these - like fill in the blanks or a word scramble or something. I'd say I could order my team custom mugs that each have one team agreement written on them - but that's no good because the Team Agreements can be changed at any time.

Step 9: Check-in on whatever actions are still in progress. Review what actions were completed during this sprint.

(In my original post, I wasn't sure where to put this step.)

Also from James, the fantastic BA, "I would always recommend reviewing previous sprint actions before starting to document new sprint retro notes . . . if we are trying to make small changes to improve our ways of working . . . if we come up with too many, then we need to focus on the ones we think will make the biggest impact. If we have 5 actions still in progress, we need to decide if they are done or not and if they are still of value. If we say yes to all of them and then we identify another 5 new actions in the retrospective, then how many do we say we agree to focus on in the next sprint? We could just be collecting a list of actions that never move and therefore no improvement is being made. I’ve seen this happen on many occasions in the past, in which case I would normally raise a retro note to say 'what should be our max number of actions from a single retro (including carry-over actions)?'." I love this insight! I hadn't thought about any of this before. But it's certainly true - I would want to avoid a perpetually growing list of actions that isn't "moving the needle". I'd also want to avoid trying too many experiments (i.e. tweaks in our workflow and processes) at once. If we are trying too many experiments at once, we won't necessarily know which experiment is responsible for the (good or bad) outcome. This makes me think. . . I wonder if at the time of creating the action, we should also decide on how urgent it is. Is it something that needs to be fixed within the next sprint? Something to be fixed within the next month? Maybe we should be more intentional with adding due dates / prioritizations to these actions. I'm thinking that I might need to add an additional step near the end of the retro to review the current actions--in other words, to look at what's already in progress / not started as well as the new actions we've written during this retro. So that we can make sure everything is still consistent (no duplicates, no contradictions) and also so that we are all aware of the state of things. That we all have the same expectations for the coming sprint. From another one of my colleagues, "I think it’s very important, if not essential, to keep track of the actions defined in a retro, and to make sure they are reviewed during the next retro (I like seeing them in the beginning of the retro). Even if the action is not done, it should always be revisited. But resolving the actions should be made a priority for next sprint. It doesn’t necessarily have to be a solution to a problem, it could be something as little as 'I talked to so and so, and it was raised' or 'I asked about it and unfortunately this is not in the plans for now, but let’s revisit it in 3 months'."

NEW Step 10: Provide the retro link for everyone.

Yes, I know it's been available to them the whole sprint and they can find it themselves. But if I were ever a Team Lead, I would take on these sorts of small tasks myself. I want to make the meeting as smooth and easy as possible for everyone in it. So everyone can just show up and participate without having to make a bunch of peripheral effort in order to be able to participate. I would put this in the Zoom chat in our case. You could put it in a team Slack channel if that's easier. Whatever is easiest for the participants.

Step 11: Set the timer for 7-10 minutes.

Step 12: Ask if anyone needs more time.

Step 13: Read through all of the shout-outs. NEW Step 14: 30-minute break to accommodate anyone who prefers to read through all of the cards before grouping and voting.

Step 15: Grouping.

Step 16: Voting.

I've been thinking about this step more. In my original post I wrote "I'd remind everyone to vote on what you think is most important to discuss (not on what you 'like' the most - or is this just another thing I say because I worry about not getting to the important stuff - does this advice still hold if we always have enough time to discuss everything?)" I think this is the right thing to do - to remind everyone to vote for which discussions they want to prioritize. Thinking about this now, plus the fact that we often run out of time to discuss all of the topics. . . I am just thinking. . .it seems like an easily solvable problem really. I could easily write a simple script where I would input the number of minutes left in the meeting, some sort of item ID, and the number of votes that each item (identifiable by ID) received. And the script could spit out a schedule for the rest of the meeting. And if we all agreed that the proposed schedule did not allot us enough time per topic, we could decide to extend the meeting and then re-run the script with the new number of minutes. The only challenging bit would be feeding the data to the script. Maybe TeamRetro already has a feature that does something like this. I will have to poke around.

Step 17: 10-minute break.

Step 18: Discussion.

I wrote something in this step about generating actions from the discussion. One of my colleagues pointed out to me, "Maybe it’s just me, but I feel like during retros, (especially when there’s something that can be improved) people are eager to write actions. But sometimes things happen as a casualty, a one-off event. So to me it’s important that those moments are recognised, and heard. Something like 'this was indeed something that could’ve gone better, I understand your frustration and we will keep it in mind to identify similar situations in the future before it happens'. So there’s no concrete action, but simply the discussion would give me some inner peace. The important thing to me is that people feel heard, always." I really like this insight. It's 100% true. Sometimes no action is needed. Sometimes the discussion is all that was needed. An outlet for some frustrations. An acknowledgement of what went wrong/right. I think I was really aggressively pushing actions at the time I wrote the original blogpost because there were several managers/leaders in my current sphere that were never taking any actions out of retros.

NEW Step 19: Review all actions (old and new).

Look at the bigger picture and make sure it all still makes sense. I wonder if it would be a good idea to post these somewhere after the retro. Somewhere very accessible/visible to team members. Or maybe this (reviewing the big picture - aka how this one new action fits into the already-existing actions) should be part of creating the new actions during the discussion step? I think at the very least, it could be useful to have the current actions visible during the retro discussion.

Step 20: Thank the team for participating.

Step 21: Remind team members that they are welcome to try facilitating a retro if they would like.

---

I am pretty happy with these steps. I think this is a good go-to approach. However, as one of my colleagues pointed out, "it is all about humans and after a while, having the same retro format over and over is a bit boring. Yes, it's comfortable in the sense that you know what to expect from it and you don't have to face a new challenge, but at the same time, does each person really reflect back every 2 weeks? It's good to break habits sometimes and raise a specific topic or have a break from retro for a month. For example, if we think things are going well enough maybe skip the retro that sprint." I love love LOVE the idea of skipping the retro once in a while. Because it can become very tedious to constantly analyze one's progress. Sometimes we just want to get on with things. I think it would be absolutely healthy to take a break from retros every so often. Just skip one here and there. Obviously, not if there were any sort of catastrophes during the sprint and it's clear that people want to let out some of that frustration. I also love the idea of having a specific focus every now and then for the retro. Like "Standup" or "the code base" or "the current feature" or "the release process" or "your least favorite part of coming to work" or "3 things you would like to change about the company". I love the idea of just getting everyone's gripes about a particular topic out in the open! However, I think this would only be useful if action is actually going to be taken in response. Otherwise, I wonder if team members may end up just feeling frustrated and unheard. And while I do like the idea of figuring out a good format once and then sticking to it (for the sake of saving future time and effort), I think my colleague is 100% correct. We are human. It's a good idea to shake things up every once in a while. I think the key here is "once in a while". It shouldn't be a different format every single retro - because that's a lot of work for everyone involved. I would wait to shake things up until the team is in a pretty solid routine. Wait until things are actually getting boring. Don't shake things up when everyone is already overwhelmed.

---

Next, I want to go over the feedback I got addressing some of my scenarios in this section.

Plans for Non-ideal Scenarios

What is my plan if we run out of time?

Original thoughts

Do I schedule a "part 2"? Or do I just write the remaining points in the team Slack channel? I think I'd probably ask the team what they prefer. Or potentially try both approaches (on separate occasions) and see which one fosters the most engagement.

What I will NEVER do is to ignore the items that we didn't get around to discussing. Ideally every single discussion is addressed before the next sprint. So we avoid going in circles and facing the same issues over and over again.

Feedback

"In one of my previous teams, we had so many items to talk about that we were putting a timer of 7 minutes per topic. When the timer went off, if more than 2 people voted to continue talking about this matter, we would continue on this item."

I like the idea of using a timer. With a max of 7 minutes for any topic. The part I don't like is that someone has to manage this - and that seems like a lot of logistics! But if I were the Team Lead, I would certainly give it a try!

What if one team member is talking too much?

Original thoughts

Is this something I can tactfully and gently address in real time? Or is this something that I need to talk to that individual about one-on-one after the retro? Help! Advice needed.

Feedback

"One member talking a lot is fine as long as other people are also getting involved."

I am currently reading a book called The Culture Map, which I think might give me more insight on how to handle this type of situation.

What if someone interrupts someone else?

Original thoughts

Do I interrupt them? Or do I politely wait until they are finished and say "I think Bob was not finished with what he was saying. Bob, did you want to say more about [bla bla bla]?"

Feedback

"I think whoever is running the retro should invite the person that got interrupted to speak again. That should be enough in my opinion."

I like this suggestion. I think this feedback is right - if this is not enough to solve the problem, then the interrupting individual needs to be coached one-on-one (outside of the retro meeting).

What if some team members never talk?

Original thoughts

Do I put them on the spot? Ask right there in the retro for their opinion on a topic? Or do I save this for a one-on-one conversation where I ask them if they don't feel comfortable speaking up in the retro? And remind them that I think it's really important to hear all points of view, especially differing opinions.

Feedback

​"The person facilitating can really help manage this by trying to open it up to more people in the room. I’ve sometimes found myself answering a question and then trying to get other members of the team involved by mentioning a specific scenario and asking for their view. So I would say, as a team, we can help to get each other involved." -James, outstanding BA

"This is tricky. When I joined, I would only write green things/shout outs because I had no reference of things to be improved. I was coming from such messy places, that I was mesmerised with how things looked here. So this is the first case: people might be happy.

But also, they might not feel safe/comfortable. So this should be brought up during 1:1's IMO, and whoever is running the meeting should be made aware (not necessarily mentioning names or anything), that they do not “propagate” such safety in the meeting. This is something that can be practiced as well (although I do not know how).

Also, something that happens often during zoom calls, but not so much in person. I usually agree a lot with other people, and because they say whatever I wanted to say, I don’t add anything, I just nod in agreement. But it feels weird both to nod, and to unmute myself to say “I agree”. Sometimes I do unmute myself, but I often feel unmotivated because there’s a lack of feedback. Whoever is running the meeting could acknowledge both disagreements AND agreements."

I absolutely love the suggestion for the meeting facilitator to acknowledge (vocally) if other people are agreeing over zoom - whether it be nodding or an emoji reaction. This is such a great idea!

---

And lastly, the bit that sparked the most conversation!

Who should attend a retro?

Original thoughts

I feel that everyone who had any involvement in the sprint should join the retro. This means more perspectives in each discussion. This also means more ideas for possible solutions, and solutions coming from a wider variety of perspectives.

So to me this means: developers, designers, product owners, business analysts, team leads and anyone else who might have participated in the sprint. Maybe that means someone from a front-end team or back-end team that helped out a lot. Maybe that means someone from data science. Maybe that means someone from the analytics team.

Feedback

​"I think it is important for all the members involved in the sprint to be present during the retro meeting. Even if we spend 30 minutes talking about pure engineering issues, it helps the rest of the team ( PO, BA, UX) understand the problems the team has. It creates empathy too, and this can help explain certain things like "we think the devs don't deliver at speed", "why isn't it smooth?", "why are there so many bugs or hotfixes?"

BUT this can only work in a situation where no one takes the comments personally or feels attacked.

Which means, if you don't set up an environment of trust within the team, some people will be scared of raising issues in front of their boss or the PO/BA/UX"

​"I always wonder if everyone feels comfortable speaking, especially as the group gets bigger if/when you start to include everyone you suggested. Also how do you balance healthy discussions around “team” level topics (eg. specifics around making the day-to-day team function better like “let’s change the daily scrum to this!”) versus “wider team” topics (eg. It’s hard to get a response out of my BA/PO, we hate what we're working on) and keep everyone engaged? My thoughts at the moment are that the bigger the team (ie. the number of distinct roles represented at the retro), the more dilute the focus and possibly people start to feel less “safe” especially to express disagreement or dissatisfaction - you’d be very lucky to be able to open up your retros and still gather the same quality / kind of feedback. It will be different for every team, every person in that team and ultimately every company…"

My response:

This is SUCH a good point and something I totally had not thought about - at least not past the point of thinking that no higher-ups should be in the retro - which I didn't even write down, but realizing now that I should.

SO yes - I think you hit the nail on the head with the idea that part of what makes a retrospective good is that it feels like a safe environment to speak - and it feels like that to everyone in the retro.

Your point that developers may feel uncomfortable saying things like "It's hard to get a response out of my BA/PO" and "we hate what we are working on" is such a good point. Because any developer could certainly write that anonymously on a card, but then maybe no discussion will happen because no one will feel comfortable discussing this with a BA or a PO in the retro. (And the BA or PO might feel like they are being attacked.)

I'm totally at a loss here! What do you think? Should it be only devs in the retro and not other people/groups that they work with?? I don't know!!! Maybe I will start asking around to lots of BAs/POs.

Maybe one solution is defaulting to only devs in the retros, but then always reminding the team that we can invite other people to our retros if we think they are needed??

My other thought now is also that, in my experience a lot of the retro topics are very "dev-heavy" - like have to do with problems in the code base or just problems that only the devs face. . . so maybe retros feel mostly boring / irrelevant to BAs and POs a lot of the time. I think I will have to start surveying all the BAs and POs on this topic. And designers.

Getting the team to invite members, yes this is something I’ve been thinking about recently. It is a hard one and again it depends so much on individuals and individual circumstances. I guess the important thing is to recognise these things and (if needed) try new things out!

I’ve never been a dev so my experience is very one-sided. It can sometimes feel like you’re outnumbered as a BA (or PO/designer/team lead I’m sure!) but the way I think about it is that it’s also on us to take a step back! And if something is really that bad then of course take the discussion further after the retro!

As for "dev-heavy" topics - I think it's also the nature of the beast. By definition we (BAs, POs etc) are outnumbered but something I've decided for myself is that part of my role in that team is to stay away from the details (I lean on my TL for that!) which allows me to watch out for trends or listen out for "other" things - I think of it a bit like sitting in on an interview (ie. assessing a candidate but not being the one leading the interview). That being said though, it really does depend on what topics come up as well as how chatty / disgruntled people are feeling!

This discussion gave me so much to think about, but my biggest takeaway is that the most important criteria for a successful retro is that all members of the team feel safe to express their opinions and share their experiences.