I’ve written before about some techniques that I think help to run a good meeting[1].
Recently, I made the decision to delegate[2] the running of most of our team meetings to my reports. Typically, we have daily five[3]-minute standups, bi-weekly Sprint Planning, the occasional brainstorm, and a weekly meeting with stakeholders.
We now do a rotation, with each member of the team (including the interns) running the daily standups and bi-weekly Sprint Planning meetings in turn.
I’ve had to learn some things about delegating, but that’s a story for another post.
For today, I wanted to talk about some of my observations about how to run (what I think is) a good retrospective.
Normally, our retrospective is sandwiched in the middle of our Sprint Planning meeting thus:
1) Adjust any tickets which have changed status since the daily standup[4]
2) Close the Sprint
3) Retrospective
4) Choose a name for the new Sprint (Generally the most difficult[5] part)
5) Add items to the new sprint, prioritizing and estimating as we go[6]
It wasn’t until I watched others running a Retrospective that I understood a lot of the small things that I do that make a difference.
The (way I see) steps to a Retrospective are as follows:
1) The Facilitator draws the visualization[7] to start people thinking:
The facilitator writes something akin[8] to the following diagram on the board:
Went Well Not So Well
*---------------*----------------*
| | |
| | | In Our Control
| | |
*---------------*----------------*
| | |
| | | Not In Our Control
| | |
*---------------*----------------*
The point of this is to help the group think about and distinguish things that are in their direct control and out of their direct control. Many groups will come up with a definition for this after their first argument, often placing the line of ‘direct control’ at the edge of the group in the meeting/team in question. There are also many ways to write ‘Not So Well’, which I won’t get into, except to say that I prefer the hopeful phrasing. 🙂
Overall, you can think of your group process as bringing issues from ‘Not So Well/Not In Our Control’ to ‘In Our Control’, then ‘Went Well’, then noting new issues and starting the cycle again. We had one retrospective a while back where basically everything was ‘Went Well/In Our Control’, or ‘Not So Well/Not In Our Control’, so we ended up brainstorming ways to get things under our control, or at least influence, so we could fix them.
It’s not necessarily the worst thing in the world if most items are in the ‘Went Well/In Our Control’ category, but this may also mean that there are underlying issues that you may need to ferret out in your one-on-ones (You *are* having one-on-ones with your team, right?). One such issue came up recently in a one-on-one, and when it was brought up in the Retro., I hijacked the meeting for half an hour to have a specific brainstorm on that topic, to make sure it was covered in depth.
2) The facilitator asks the team to write things went well or did not go well on sticky notes and to put them on the board:
Each member of the team writes happenings from the past two weeks on sticky notes and posts them on the diagram. We use standard-sized sticky notes, and sharpies, so that the notes can be (mostly) read from across the room. My understanding of why this is done with sticky notes is so that people feel some measure of safety and anonymity, and therefore are more likely to express what they really think.
When running this part, I ask people to think along process lines. It’s helpful (and sometimes nice!) to talk about the fact that a particular project went well or poorly, but it’s often more helpful to talk about the parts of our process or other teams’ process that affected the outcome. Identifying process issues and fixing them is what really makes the difference here.
3) The facilitator clarifies each of the posts:
In some order, the facilitator goes through each (group of) post(s) and invites the author to clarify anything ambiguous, such that the whole group understands what each post means (often caused by my handwriting… :/ ). This should only take a few minutes. As they go, the facilitator will often do step 4). Along the way, some problems may be resolved simply by bringing them up, but some may require more thought/brainstorming. Those conversations are shelved until a later step by the facilitator.
As far as ordering, we generally talk about what went well first, probably for psychological safety reasons.
4) The facilitator de-duplicates the posts:
This is more of an art than a science. In some serious brainstorms, the facilitator will call a break at this stage, because it is non-trivial to get correct, while being quite important.
The goal is to group the posts into groups that are likely to have similar solutions. I don’t have good advice here, but it is often a good call for the facilitator to ask the group if two things go together, if they seem to sound similar. More insight on this will come with experience[9].
5) The facilitator decides whether to continue:
The facilitator decides whether any of the posts require a more in-depth conversation. This will likely have become obvious in step 3). You can always check in with the group, if you’re unsure.
6) The facilitator invites dot voting to determine the order for further discussion:
If there are multiple items to address, the facilitator invites the team to come up and ‘dot vote'[10] on which items they think are most important. A good number to choose seems to be 1/3 to 1/2 the number of items to be voted on. If people complain about the number of dots, you can change this, or remind/tell them that they can put multiple dots on items.
7) The facilitator counts the dots and orders the items in dot priority order from highest to lowest
8) The facilitator brainstorms solutions in descending priority order:
Starting with the item which had the most dots:
a) Make sure everyone understands what the issue is. If this is really unclear, you can brainstorm a list of ideas to try to get to the root cause[11].
b) Brainstorm solutions. Some of these will have obvious actions and owners. For things which are not so obvious, you may want to dot vote again.
c) Make sure you clearly write down (and perhaps make into tickets) any actions which arise.
d) Continue until no items with dot votes are left, you run out of time, or your group becomes unengaged.
That’s it! You’ve now run your first Retrospective. Let me know what you think in the comments below!
[1]Wow, I write a *lot* about meetings…
[2]Stay tuned for a post about ‘Power to the Edge’!
[3]Our daily standups are trending to the long side these days, perhaps up to 10 minutes, but people seem to find them useful, specifically the conversations to solve problems that can more easily be initiated when you know people are already interrupted.
[4]It’s always nice when people update their tickets as they’re doing things, but it’s not necessary. We’ve had success with doing it in our daily standup.
[5]I am not joking. Try it with your team and see for yourself. I went to an auction at a gaming convention during my youth, and the item which went for the largest amount of money was a book to assist people in making character names. Making good names is *difficult*.
[6]’Just-in-time’ planning. This also feels like a separate topic for a post.
[7]This is a whole topic. I like this particular visualization, but you could see that many others could work just as well. The following [8] is another.
[8]There are a number of ways to draw this. It’s sometimes good to change it up, to help people think about things differently. Another popular diagram is a ‘speedboat’ diagram, with wind, anchors, obstacles, and goals as the four categories. It’s not an exact mapping to the above, which has it benefits and drawbacks.
[9]I should write about this, too.
[10]’Dot Voting’ is where you give each person a number of ‘dots’ that they can place on the things they’re voting on. In this context, we use it to choose which thing(s) to talk about next. Some people insist on only one dot from each person per topic, some are more flexible.
[11]’Getting to the root’ in a Brainstorm is a really interesting topic. It’s non-trivial, and deserves its own write-up.
