Retrospectives at scale: How to run a retro session for a large group
At the end of June we ran a retrospective session to review how things have gone in our product development organisation during the first half of 2019. It was the first time we have organised a retro session at this scale; we have 12 development teams with a host of leadership and specialist roles to support them, so there are a lot of people to include. On the day, forty brave Redgaters turned up to the session to share their thoughts, insights and ideas as they reviewed the first 6 months of the year. I thought I’d share what we did in the session and how we made it work for such a large group of people.
Hang on… what’s a retrospective, again?
If you are new to the term, a retrospective is part of a typical agile software development process. It’s run at the end a development iteration or at the end of a project phase. In those sessions the team looks back on what they have done and how they have done it, ultimately deciding what they should do to improve. More succinctly; the team inspect and adapt.
Instead of reviewing a team’s work and approach for an iteration or project, our Product Development Retrospective’s goal was to inspect how things have gone in the organisation in the previous six months, and to decide what we should adapt in order to improve in the rest of the year and beyond. It’s worth noting we focused on how we work and what we do, as opposed to reviewing products’ commercial strategies.
Structuring a large retrospective
I’m a big fan of the retrospective structure popularised by Esther Derby and Diana Larsen in their brilliant book Agile Retrospectives. Their structure breaks retrospective meetings up into five sections, each with a specific aim.
- Set the stage — Aim: Set the tone and direction for the retrospective
- Gather data — Aim: Create a shared memory; highlight pertinent information and events
- Generate insights — Aim: Think creatively; look for patterns, themes and connections
- Decide what to do — Aim: Generate and prioritize valuable, clear actions
- Close — Aim: Summarize and gather feedback on the session
I like to visualise the structure as follows (with the little bubbles representing data, insights and ideas):
For each section of the meeting, the facilitator plans an activity that meets the aim for that part and progresses the team along their mission to “inspect and adapt”. The process discourages our urge to jump straight to conclusions or solutions by deliberately asking us to think about observations and data first. It then encourages creative thinking as we look to generate novel insights before forcing the group to converge, prioritizing the most important areas for improvement and creating valuable actions.
We used these sections to structure our retrospective. In my view, this was even more vital when running a large-scale session. The structure bakes-in the agenda and process, creating a path for the facilitator to navigate the whole group along, as the easiest thing to do will be the right thing to do. The additional challenge here was to choose activities in each stage that gave everyone in the large group a voice but still allowed us to identify high-level themes, so we could converge towards some concrete areas for action.
Using micro-spectives to give everyone a voice
Although the structure scales well, I don’t believe that many of the activities you might typically apply at each stage for a individual team’s retrospective will do the same. For example, the ubiquitous Stop-Start-Continue post it note exercise that works really well for a team of 8, will not work well for 28 contributors; there will be too many post-its on the wall to parse and it’ll take too long to hear everyone share their ideas.
To avoid these scaling issues, we should look to break up the large group and run many small retrospectives concurrently, synthesising key messages between the sub-groups and building their insights towards a larger group understanding. In honour of my engineering roots, let’s call this approach micro-spectives :)
An inspiration and excellent resource while planning creative sessions for large groups is the brilliant Liberating Structures book and website. Liberating Structures focus on harnessing the insights and creativity of larger groups and comprise a selection of 33 activities for facilitating meetings and conversations, as curated by Henri Lipmanowicz and Keith McCandless. Some of these activities can play a key part in the “micro-spectives + synthesis” pattern of larger retrospectives, like 1–2–4-All described below, by bubbling up key themes from the sub-groups and helping us identify the most valuable ideas to build on as a whole.
What we did in the session
Our first Product Development organisation was run in our canteen (named the SQL Servery ;o) at 14:00pm in midweek. The session lasted 90 minutes and we had 40ish attendees. I led the facilitation of the event, but was hugely helped by the supported of two other facilitators — Mike Upton and Ragan McGill — who helped when activities were underway.
Setting the stage
First things first; we explicitly called out the session’s goal to Explore how things have gone in Product Development during the first half of 2019 and decide where we should try to improve and set expectations for how the session would run. Then we ran a quick icebreaker to wake everyone up and practice the process of working in smaller groups before combining into larger groups. In the process, Josh Crang won some chocolates for being unreasonably good at Rock Paper Scissors.
Gathering data
We then asked people to form small groups to gather their observations on what happened in Product Development in 2019. This took a little while and some prompting with a pre-prepared timeline, as six months is a long time to recall and consider. Here’s an example output from that activity:
Generating insights
Having had a look at what happened in 2019 H1 from the perspectives of our small groups, we asked everybody to write down three areas they personally thought were important for Product Development to improve in the coming months. Importantly, we wanted participants to be clear about why they thought they were important, because that was going to be vital to the process of prioritizing all the areas the whole group would identify.
We then used an activity called 1–2–4-All (from Liberating Structures) to converge our ideas towards the most important few that we should invest in as a development organisation. The activity asks people to pair up and work together to decide between them which 3 of their pool of 6 ideas is most valuable. Here’s where the all important whys came in — to help people understand and compare the importance of their personal suggestions. Two pairs then form a group of 4 and do the same activity, whittling down the ideas from 6 to 3. Finally, we had groups of 8 identifying their favourite 3 areas, before then sharing with everyone and identifying the key improvement areas as decided by the process. You can find what the group highlighted in a following section.
Deciding what to do
Our final activity (again, from Liberating Structures) encouraged participants to get involved in making change happen in those improvement areas. Often, improvements we want to make to an organisation may feel outside of our control or too big to take on. However, if we really think about it, we can often find small actions that serve those aims that individuals already have the freedom and resources to act upon. For instance, if there was an improvement area to break down product team silos, a big scary top-down initiative here may be to reorganise the teams. But what if instead everyone decided to go and spend 10 minutes tomorrow talking to someone in another team about what they are up to and the problems they are trying to solve. It’s clear to see that team silos would start to be bridged. Small, individual actions can create momentum and add up to something big.
So, in this activity we asked attendees to pick one of the key improvement areas they felt most passionate about and spend some time thinking about where they have the discretion and freedom to act in service of that improvement. Participants wrote down these personal actions and chatted about how they might achieve them in small groups. We asked people to share their actions after the meeting if they felt comfortable doing so, and many did in a spreadsheet shared on Slack minutes after the session.
Suggested areas for improvement in Product Development
Here are some of the main the improvement areas suggested by participants in the “generate insights” stage of the retrospective:
- Build on our L&D initiatives; communities of practice, sharing of good practices, increase volunteers and participation
- Encourage more cross-team JFDI/tactical work collaboration
- Help the teams get the most from the Four Key/Accelerate software delivery performance metrics we can now measure
- Provide more help/guidance for teams to prioritize their work and do “capacity planning”
- Build on the OKR process; we’re better than we were but there is still room to improve, especially when it comes to KRs
- Capitalise on the momentum behind the Redgate Platform; attitudes, tangible results and benefits
- Make it easier to move teams; but think about not doing a big move around Christmas (when many are away)
To actual improve these areas we need to decide where we want to focus additional effort as a development organisation, in addition to individual participants taking actions to help us progress in many of them. We did not decide those organisational initiatives in this session because we did not have time and all the right stakeholders in attendance — but I think we could have if we’d have extended the session by another hour and secured those extra attendees. A lesson for next time.
Feedback on the session from participants
To find out how people found the retrospective and to help us decide if we should run these in the future, we asked participants to give us feedback as they left the session on what was good and what we should look to improve.
Here are the common themes from that feedback:
+ It was good to retrospect at this level/scope (x5)
+ Getting together cross-teams to do this was great (x7)
+ Event was well run and facilitation clear (x8)
+ Large ice-breaker worked well (x3)
- Some roles were under-represented (x4)
- Things felt a bit rushed in 1.5 hours (x4)
Lessons for next time
Given the favourable feedback on the session and the actions people have already started to take, we’d like to run another retrospective towards the end of H2. We’ll do our best to learn from the above feedback to make at the next retrospective an improvement over this one. Here’s a few key takeaways for us to build on next time we run one of these:
- Doing this was a good idea! People really engaged in the process, collaborated across teams and came up with some valuable insights. Furthemore, attendees appreciated having input to the wider discussion and sharing their improvement ideas.
- It was probably a good call to make this 90 minute meeting optional, as it meant that everyone the came along had done so willingly and were naturally engaged in the process. However, as a result we did not have representation from some teams or some roles. We’ll need to decide how to improve this next time.
- Using the Retrospective Structure and Liberating Structures worked really well. Everyone had a voice, we converged towards key themes & insights and stayed to time! We could have done with an extra 30 minutes to really drill into our suggested areas for improvement.
- The time poured into planning paid off as the session ran very smoothly. It was totally worth the half day I spent preparing!
- Having two extra facilitators involved to walk around the sub-groups while activities were underway were invaluable in ensuring every group made good progress. I would not have been able to do it on my own.
- Mixing up the attendees, so they were not sitting next to people who they work with every day, would have been a good idea. It would have encouraged more cross-team sharing. Next time, I’ll choose an icebreaker that does that more deliberately.
Hopefully, at our retrospective at the end of 2019 we will have even more people there, raring to give us their insights. If that one is successful, we’ll make these retrospectives a regular event in our calendar.
Want to know more?
We’re happy to provide help or advice to anyone interested in running a larger retrospective. If you would like to find out more about how we facilitated the event or have any other questions, please let me know.
This article was first posted on Leading Agile Teams.
