Adventures in Retrospectives: Helping a large team focus!

I’m a tester on a (to me) relatively large team. Recently I was asked to facilitate an all-hands retro for our entire team. I’d like to share this interesting and rewarding experience. It’s not easy for a large team to enjoy a productive retrospective. I hope you’ll share your experiences, too.

At the time of this retro, our ever-growing team had about 30 people, including programmers, testers, designers, product owners, marketing experts, and content managers. While we all collaborate continually, we’re subdivided into smaller teams to work on different parts of our products.

I work mainly on the “Frontend” team. Our focus is our SaaS web app’s UI. We have weekly retros. The other big sub-team is the “Platform” team, further divided into “pods” that take care of our web server, API, reports and analytics, and other areas. This team has biweekly retros. The “Engineering” team (everyone in development, leaving out designers and marketing) has monthly “process retros”. But all-hands retros had become rare, due to logistics. Several of our team members are based in other cities. We hadn’t had an all-hands retro for more than six months.

Preparation

The team’s director asked me a few days in advance to facilitate the retro. I accepted the challenge gladly but I felt a bit panicked. Our team usually follows the same standard retro format. We spend some time gathering “happys”, “puzzlers” and “sads”. Then we discuss them – mainly the puzzlers and sads – and come up with action items, with a person responsible for taking the lead on each action item. Over the years this has produced continual improvement. However, I think it is good to “shake up” the retro format to generate some new thinking. Also, retros tend to be dominated by people who aren’t shy about speaking up. I wanted to find a way for everyone to contribute.

Thanks to my frequent conference and agile community participation, I have a great network of expert practitioners who like to help. I contacted the co-authors of two of my favorite books on retrospectives: Tom Roden, co-author with Ben Williams of 50 Quick Ideas to Improve Your Retrospectives , and Luis Gonçalves, co-author with Ben Linders of Getting Value out of Agile Retrospectives. (I’ve also depended for years on Agile Retrospectives: Making Good Teams Great  by Esther Derby and Diana Larsen.) I used their great advice and ideas to come up with a plan.

Food is a great idea for any meeting, so my teammates Jo and Nate helped me shop for and assemble a delicious platter of artisanal cheese and fresh berries (paid for by our employer, though I would have been willing to donate it.)

Pick a problem

Around 30 of us squeezed into a conference room. We had started a few minutes early so that our Marketing team could hand out new team hoodie sweatshirt jackets for everyone! That set a festive mood. Also, it is a tradition that people who are so inclined enjoy a beer, wine or other adult beverage during retros. For this reason, retros are typically scheduled at the end of the day. And of course, we had cheese and fruit to enjoy.

We had just over an hour for the retro, so I had to keep things moving. I gave a brief intro and said that we would choose one problem to focus on instead of our usual retro format.

I asked that they divide into their usual “pods”. Their task: choose the biggest problem that can’t be solved within their own pod that they’d like to see solved, or at least made better, in the next three months. In other words, the most compelling problem that needs to be addressed by the whole team. They should come back to the big group with this problem written on a sticky note.

As I expected, designers, testers and customer support specialists joined the pods they work with the most. Contrary to my expectations, the “Platform” team decided not to further subdivide into pods for the activity.  Together with the Marketing/content team and Frontend team, we only had three groups. I made a quick change of plan: I asked each group to pick their top *two* problems, so we’d have more to choose from. I gave them 10 minutes for this activity.

One group stayed in the conference room and the other two found their own place to work. They wrote ideas on sticky notes and dot voted to choose their highest priority problem areas. I walked around to each team to answer questions and let them know how much time they had left.

After 10 minutes, I called everyone back to the conference room. A spokesmodel from each team explained their top two problem areas and why those needed help from the whole team. We dot voted to choose the top topic, everyone got two votes. I would have preferred to use a process such as the Championship Game from Johanna Rothman’s Manage Your Product Portfolio  which would have been more fair, but we didn’t have time. Everyone seemed happy with the results anyway.

The winning problem area was getting more visibility into our company’s core values and technical practices, and how to integrate better with the company’s “ecosystem”. I don’t want to get into too much detail, because what I want to share is our process, rather than the specific problem.

Design experiments

Now that we had a problem for the whole team to solve, I explained that we wanted to design experiments, and we could use hypotheses for this. I explained Jason Little’s template for experiments:

We hypothesize by <implementing this>
We will <improve on this problem>
Which will <benefits>
As measured by <measurements>

I asked the groups to think about options to test the hypothesis. Who is affected? Who can help or hinder the experiment? I emphasized that we should focus on “minimum viable changes” rather than try to solve the whole problem at once. I gave an example using a problem that our Frontend team had identified in a previous retro.

I had three colors of index cards and we handed those out randomly around the large group. Then we divided up by index card color, so that we had three groups but each had different people than before. Again, each group found a place to work. Each designed an experiment to help address the problem area. I told them they had 10 minutes, but that wasn’t enough time, I ended up letting them have 15. I walked from group to group to help with questions and keep them informed of the time.

Then, we got back together in the conference room. A spokesmodel for each group explained their hypothesis and experiment. We had three viable experiments to work towards our goal.

Wrap-up

At this point, we had experiments including hypotheses, benefits, and ways to measuring progress. We only had about 10 minutes left in the retro now, and I wasn’t sure of the best way to proceed. How could we commit to trying these experiments? I asked the team what they’d like to do next. I was concerned about making sure the discussion wasn’t dominated by one or two people.

The directors and managers put forward some ideas, since they knew of resources that could help the team address the problem area. There were videos about the company’s core values and practices. We also discussed the idea of having someone within our team or outside of our team come in and do presentations about it. There were several good ideas, including coming up with games to help us learn.

Again, the experiments we decided to try aren’t the point, but the point is we came up with an action plan that included a way to measure progress. The managers agreed to schedule a series of weekly all-hands meetings to watch videos about company core development values and practices.

Immediately after the meeting, the marketing director and the overall director got together to put together a short survey to gauge how much team members currently know about this topic, and everyone took the survey. After watching and discussing all the videos, we can all take it again and see what we’ve learned.

I had hoped to wrap the retro up by doing appreciations, but there wasn’t time. With such a big group, I think sticking to a time box is important. We can try different techniques in future retros.

Outcomes

I was surprised and pleased to get lots of positive feedback from teammates, both in person and via email. My favorite comment, from one of the marketing specialists, was: “It’s the best retro by far I’ve been to in four years here. I felt productive!”

The initial survey has been done, and we’ve had three meetings so far to watch the videos. We watch right before lunch so that people can talk about it during lunch. Having 30 people in an hour-long meeting every week is expensive, which shows a real commitment to making real progress on our chosen problem area.

I think the key to success was that by dividing into groups, everyone had a better chance of participating in discussing and prioritizing problems, and in designing experiments to address them. The giveaway hoodies along with food and drink made the meeting fun. We stuck to our time frame, though we did vote to extend it by a few minutes at the end. Most importantly, we chose ONE problem to work on, and designed experiments that included ways to measure progress in addressing that one problem.

The team’s directors have decided they’d like to do an all hands retro every six weeks, and they’ve asked if I could facilitate these. I think it’s a great idea to do the all hands retro more often. I’m not sure I should facilitate them all, but I’ll do what I can to help our team keep identifying the biggest problem and designing experiments to chip away at it.

Do you work on a large team? How do you nurture continual learning and improvement?