Some Nascent Thoughts on Facilitating A Retrospective

Lately I've been reflecting a lot on leadership and management within the software development world. Today I was planning to list some of the qualities of Team Leads I've had who I thought did a good job. I started with "facilitates excellent retrospectives" and then went on a tangent thinking about what makes a retrospective good.

So, recorded below are my thoughts. EDIT: I have now written a second blogpost that continues some of the discussions started here.

---

If I were a Team Lead running a regularly occurring retrospective at the end of a sprint, I would:

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

Make sure to set up the retro board ahead of time (ideally right at the start of the sprint) AND let everyone on my team know once the retro board is "open". (I am assuming an online, digital retro board, rather than a physical retro board.) At my current job, we use TeamRetro. I've got no major complaints about it. Gets the job done from what I can tell.

Please note: It is not enough to set up the retro board ahead of time if you don't communicate that to your team.

Step 2: Put the retro board link somewhere very accessible.

In addition to announcing that the board is now live, I would put the link to the retro board in the team's Slack channel (as in, I'd put the link in the channel description) with the title: "Next Retro". That way everyone on the team always knows where to find the retro board and never needs to waste time or energy looking for it. (I believe that part of a Team Lead's job is to take on cognitive load so that their team does not have to - that way, their team can focus on developing software.)

Discussion My friend Oussama commented (on the first version of this blog post) that "One of the key points that got my attention is how you approach it as a continuous collection of thoughts during the sprint in step 2. I always note my retro feedback on a personal note, because I know I will not remember all of them when the retrospective comes." Just like Oussama, I also tend to keep notes on my computer's desktop (where they are very quickly and easily accessible) in a text file titled "Next Retro". I think even if the retro board is open, I prefer not to add my notes right away for 2 reasons:

1. Sometimes, if I'm noting a problem, the problem gets resolved before the end of the sprint - although it probably should still be mentioned in retro and reviewed (could we have avoided the problem completely? could we have come up with a better solution? is there a better solution for next time?), and so the way I write the card might be different.

2. My natural writing style is super direct. And I don't spend any time making the notes I keep on my computer diplomatic or tactful or even clear to anyone other than myself. I save that for the actual day of the retro. My notes are just for jotting things down super quickly so that I don't forget.

This is just my own personal preference. (And of course, I could write my raw thoughts on the retro board and then edit them later - no one can see what I wrote until we move to the "grouping" phase anyway. However, despite my personal preferences, I think it's still a best practice to have the retro board open for the whole sprint. This is especially useful when there are team members who aren't able to attend a specific retro. They can still write cards, and this way, their points still get discussed.

Step 3: Give the team regular reminders throughout the sprint that the board is always open and where to find it.

I would regularly remind the team that the retro board is available if they want to add cards as things come up. I think this is a reminder I would give in standup/ Daily Scrum each day or every few days. This is, again, part of my philosophy of removing cognitive load from my team and taking it upon myself, as the TL.

Discussion I must mention that it took me about a year to finally get into the habit of writing notes during the sprint for my retro feedback. But I'm so glad I finally started doing this because it allows me to use retros so much more effectively. I cannot recommend this habit enough. The goal is to find yourself often thinking, throughout the sprint, "I should bring this up in the retro". And never getting to the retro thinking "Hmmm, what did we do in the last 2 weeks? What should I write?"

Step 4: Repeat the rules of engagement (concisely)

At the start of each retro, I would: 1. Address any new joiners - to let them know that since this is their first retro with the team, they should feel free to sit back and observe, but also that they are more than welcome to participate, we'd absolutely love to hear any feedback they've had about their experience so far.

2. Review the rules of engagement, such as:

• Everything that goes on the board is anonymous (even to the board admin/creator)

• You are welcome to identify yourself on your card(s) if you want to for whatever reason

• If we don't understand what a card means, we can't meaningfully discuss it, so we will skip it (I don't feel it would be a worthwhile exercise to guess what the writer meant)

• So make your feedback/comments specific!

• Don't try to guess who wrote a card - that's not the point of the retro at all

• The retro is not a place for constructive criticism directed at a specific individual - that is what 1-to-1s and private conversations are for

• Absolutely no interrupting

• (Any other Team Agreements regarding our rules of engagement for retros)
  

Step [not-sure-where-to-put-this-bit-yet]: Review previous Team Agreements

Review previous team agreements. To avoid wasting time having discussions we've already had.

Step 5: Set the timer for 7-10 minutes

Then I'd set the timer for 7-10 minutes (would experiment with figuring out a good amount of time) , and I'd let it go all the way to zero. I would not poke and prod people before the time is up to see if they are done and we could save a few minutes. I'd rather get as many of their thoughts on the board as possible. I don't want to rush people to finish.

Discussion One of my colleagues pointed out to me - "What if everyone is finished before the time is up?" (For context, TeamRetro has a button people can click that says "I'm finished". So if everyone is finished writing their cards, this is clearly indicated.)

This is a good point. Do I still let the timer run out? Just in case someone thinks of something after they are done? I'm so paranoid about missing out on any feedback! But at the same time, maybe some of the team will become impatient (and possibly disengaged) sitting doing nothing for 5 minutes. . .although, I guess that is a problem anyway if not everyone is done.

But especially, what if everyone is done after only 5 minutes and I've set the timer for 10 minutes? I am not sure what the best thing is to do here!! I'd love to hear some opinions! Another of my colleagues gave me the following feedback, "​​I think both ways can work. If you are worried about letting the clock run down just let people know they can grab a drink and come back. When I used to run these in a room where people were physically present, I would always give the whole time. Also worth remembering there are so many different ways to run retros (some more fun ways) so you may need a little more time in some cases e.g. draw a picture that represents the last sprint, this does spark some great conversations."

Step 6: Ask if anyone needs more time

When the timer runs out, I would ask if anyone needs more time. If anyone says yes, I will give 1 more minute.

Step 7: Read through all of the shout-outs

We often set the board up with a "shout-outs" column. I think this is great. I think. Sometimes when I am grumpy I want to be like "Ughh who cares, there's important stuff to talk about - let's skip slapping each other on the back for 10 minutes" but that's probably a product of 1) me being grumpy or 2) retros where I worry we won't have enough time to get to the important issues or 3) experiences where important issues weren't resolved or given enough time because there was too much positive stuff <-- reading this back later, I should probably be grateful that this is a "problem" we have. SO. First, I'd read through all of the shout-outs out loud.

Discussion

My one friend has really demonstrated to me just how important this part is. (I must emphasize here that I am writing all of this as a developer, not a TL. These steps are about how I'd facilitate a retro if I were a TL.) Which is great, because I had not realized it. Here is the thing: I take the shout-outs for granted because--at the time of writing--I currently work in a very healthy work environment / culture. (That's not to say there is no room for improvement, but just that I wouldn't classify the culture as toxic.) Because of the healthy work environment, and the good people that I work with, I know that my work is appreciated, valued, and recognized. I get positive feedback on a regular basis. I know that others think I am making valuable contributions and that they appreciate my efforts. I know that my TL thinks I'm doing a good job. That is not to say that every single person I work with thinks I'm great or has no complaints about me. But that some threshold percentage appreciate the work I do, so that I don't ever feel as though my team does not respect my skill or as though they doubt my competence. If you are on a team where no one ever recognizes a job done well--well, I'm not sure that having a "shout-outs" section will solve that issue BUT - it could be a good way for a TL to detect this kind of problem. (Which would be the first step in addressing the issue.)

This has me thinking that if I were TL, I'd probably keep a spreadsheet or something with each of my team members' names and a record of the shout-outs they'd gotten each retro. This would serve multiple purposes:

1. It would assist me in gauging the performance of each individual team member (which is part of a TL's job - at least, sometimes it is, if they are a people manager too). Strong emphasis on the word "assist". It wouldn't give me a complete picture of course - just one of many tools I would use to evaluate individuals.

2. It would highlight any patterns to me - is someone getting all the praise? Is there anyone getting no shout-outs? Is this because they aren't pulling their weight? Or because of some problematic team dynamic? Patterns are important - especially if they highlight a cause for concern. And if there are problematic team dynamics, I want to deal with them as quickly as possible and control the damage.

Step 8: Grouping

Then it's time for grouping. I'd remind everyone not to worry about grouping shout-outs (because we've already gone through them all at this point). I think if I were facilitating I might sit back and watch for this step rather than participating (?????) Might be good to have at least one person maintaining a sort of bird's eye view of the board (??????)

Step 9: Voting

Next is voting. I'd remind everyone

• to ignore the shout-outs when considering their votes (because we've already gone through all of them)

• the # of votes they have

• votes are anonymous

• they can vote more than once per item

• 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?)

Step 10: Short break

At this point, I think it might be time for a 5-10 minute break, before we get into discussions?? Or maybe that's a bad idea? I will have to experiment to find the best slot for a small break.

Step 11: Discussion

Discuss each card (or group) one by one. Before this part of the retro, during the short break, I'd remind myself (as the TL or facilitator in this scenario):

1. Make sure to do more listening than speaking

2. Be open-minded

3. Seek first to understand

4. Do not get defensive

5. Make sure I fully understand the card before commenting

6. Resist any urge to fill awkward silences with idle chit chat. Allow people a moment to gather their thoughts before they start talking

7. Don't get mad - anger is useless and unproductive in this sort of scenario (and also potentially damaging to candor in future retros)

8. Try to be as action-oriented as possible - most discussions should end in a new team agreement, an adjustment of a previous team agreement, or an action (with a specific assignee and a specific check-in date!)

This is the part of facilitating a retro where I'm sure I have the most to learn. But I also think it's an interesting experiment to write down what I think now. Then, later in my career, once I maybe am a Team Lead, I can come back to this and see what I would add/change. Or laugh at my own naiveté. And list what mistakes I made!

Discussion

Two separate individuals have given me feedback mentioning "emotion" in regards to this step. I want to record here my friend Oussama's feedback from my original LinkedIn post, because it was a completely new idea to me: "Proposed step: Emotional read of all notes from the retrospective.

- What: try to read emotions expressed through team members contributions in the retro. Not to identify them, but to unwrap the emotion and extract the information inside.

- Why: Emotions are raw unformatted information. Missing them can lead to missing big on what to improve or what to keep and even some root causes.

- Where: behaviour-related indications, career-impact-related topics, environment-safety-related observations, all given directly or mostly indirectly in the retro."

This is very interesting to me because I have always been extremely strict with myself about not inserting a tone into anyone's written communication. I am very, very insistent on not making assumptions. However - I see the use of identifying emotions. "Is this feedback angry? Sad? Disheartened?". I need to think about and discuss this more!

Step [another-not-sure-where-to-put-this-step-yet]: Follow up on previous retro actions

Follow up on old retro actions. Ideally, this is something I'd follow up with in stand-up / Daily Scrum as retro actions are addressed and as their due dates come up. . . I think I'd rather not follow up here - but maybe this is a place to at least quickly go over which actions are still in progress...which makes me think that maybe this step should happen earlier in the retro, where we review Team Agreements.

Step 12: Thank the team for participating

Thank everyone for their cards and for grouping and voting and for their discussion. Remind everyone that we all depend on a culture of speaking up to help us continue improving our processes and team output and job satisfaction. And that there will never be negative consequences for disagreement or constructive criticism.

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

Remind everyone: if anyone is interested in facilitating a retro, that is an option and do please reach out to me if interested. (But also no pressure!) If you are interested in the TL position, this is a great way to master some of the skills (or just start practicing them) ahead of time. But it's not required - although I do highly recommend doing it at least once just to experience the retro from a different perspective. It might influence the way you participate.

---

Plans for Non-ideal Scenarios

What is my plan if we run out of time?

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.

What if I as the TL cannot make the retro?

Should the retro still happen without the TL? Or should we move it? As an engineer, I hate the idea of a "single point of failure" or having "dependencies". So the idea that the TL is not vital to the retro appeals to me a lot.

I think if the TL is a good listener, and can be trusted to read the retro points once they are back at work, read any new Team Agreements that were added as part of the retro, and to take on any actions assigned to them during the retro, then it's fine to have the retro without the TL. Where this falls apart is when the TL is the source of most of the team's problems. In that case . . . you really want the TL to be there, because in this case, they can't be trusted to read the retro points later on and digest the feedback. Regardless of the specific situation on a team, every team member should have access on TeamRetro to create a retro board and facilitate the retro.

What if one team member is talking too much?

And preventing others from having a say? 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.

What if someone interrupts someone else?

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]?" Advice needed!

What if some team members never talk?

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. Advice needed!

---

Team Agreement Examples

(Coming soon)

---

Who should attend a retro?

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.

---

What categories are present on the retro board?

First of all, I don't have many opinions on this. (Maybe I will if I ever become a Team Lead or join a company that is particularly bad at retrospectives). I think this is really up to your specific team. There is no one-size fits all solution.

Second of all, I think this could probably be an entire blogpost on its own. (Or maybe I'm over-estimating. Maybe everyone pretty much already agrees on the basic categories.)

Lately, I've been on teams that use one of the TeamRetro options (TeamRetro has many different options listed here) that includes:

• shout-outs

• what went well

• what went poorly

• what puzzles us

• what do we want to try next

I really like this set up. It covers everything I need in a retro discussion.