A Retrospective Retro
At a client today I facilitated a retrospective for the dev team. I've done a few of these in the past, both for agile software teams and also After Action Reviews (AARs) in the US Army. For AARs, the usual format is to discuss what was supposed to happen, what really happened, what went well, and what didn't go well. Then, identify any changes or controls that should be added to improve for next time. In software development teams, there are many different approaches to retrospectives. Today I tried the Liked, Lacked, Learned approach, to which I added Try to cover ideas for new things the team wanted to focus on. There's probably an L-word I could use instead but Try worked...
[caption id="attachment_2046" align="aligncenter" width="600"]
Retrospective board, with vote stickers[/caption]
Overall, this worked well and seemed to collect a good mix of ideas and facilitate discussion (which is often the most important part). The whole meeting didn't drag on and nobody seemed bored or disengaged. We had the team participate in the meeting without the budget-controlling higher management present, but then we brought them in at the very end.
In terms of conducting the meeting, I drew three areas on the whiteboard and labeled them Liked, Lacked, and Learned. Later I added 'Try' so next time I would probably use 4 quadrants instead of 3 triadrants (sic) + 1 added section at the end...
We went through each section, and I had everybody write down their ideas on Post-It notes that I walked around, gathered, and added to the board (the room didn't make it easy for everybody to get to the board themselves all at once, and this seemed to work well since individuals could focus on their own thoughts during this stage). I prompted the group with categories to think about for their ideas.
"What did you like during the last period about your physical work environment? Furniture, office, hardware?"
"What did you like about the software processes and tools the team is using? IDEs, source control, etc.?"
"What did you like about the people you work with? How teams are organized? Company culture and events?"
I repeated these prompts for each of the categories. As I added the notes to the board, I would group duplicates and read them aloud to help give team members more ideas. We didn't use a timer, but just kept going until the ideas stopped flowing.
Voting
Once the board had ideas on it, grouped, I distributed sheets of 1" round stickers to the team members. Each one got 12 stickers with instructions to add stickers to the notes (or groups of similar notes) they thought were the most important or should be given the highest priority to take action on. I told them they could add up to 3 stickers to any one topic, if they felt really strongly about something, or they could choose to spread them out. Everybody was told to use all of their stickers.
When this was done, the board looked a little like it had taken a lot of hits from a paintball gun. There were colored circles all over it, applied to the notes. To make it a little easier to identify the high-priority items, I shuffled around the notes so that the ones with the most stickers moved toward the center of the board. In this way, everything in the center was the highest priority, with lower priority items spread out around the outside.
Once this was done, we discussed the most popular, highest voted items, and brought in the senior manager with the budget approval authority. Some (but very few in this case) of the items were things that could be solved relatively easily with a credit card. Some of the items seemed like they would be relatively easy to accomplish, like technologies the team wanted to explore that were already on the roadmap and could be a good fit for projects that were already in the pipeline. Others might require more work to try and fit into the team's priorities and existing commitments. The most important parts of a retrospective, though, are for the team and their leadership to demonstrate that they aren't a complete waste of time. There needs to be follow-up, and even if the high-priority items can't all be achieved overnight, the team should understand they're being heard and best efforts are being made to address their concerns and make progress. Of course it's too early to say whether that'll happen in this case, but I'm hopeful.
Future retrospectives should ideally happen on a regular cadence. It's not a bad idea to start these meetings by discussing the most popular, highest priority ideas from the previous one, and to review any progress that's been made toward these items. They can go back on the board if they're not resolved (minus any previous votes), so the team can reassess whether they're still important.
Retrospective format - Liked Lacked Learned Try from Steven Smith
About Ardalis
Software Engineer
Steve is an experienced software architect and trainer, focusing currently on ASP.NET Core and Domain-Driven Design.
