Retrospectives help a team to continually improve their processes so that they are happier and more productive. I think retros are definitely the first thing I would introduce at companies where agile development practices are not often used. Regularly scheduled retrospective discussions are a great first step to introducing change. Ask what’s going wrong and what suggestions people have, and then try to make a change. Maybe it gets better or maybe it’s not the right fix. But there needs to be a scheduled ritual to ask for the input in the first place (and act on it).
But then again sometimes retrospectives can get stale. In the agile software development projects I’ve worked on we usually operate on a two week rhythm. Every two weeks we hold a retrospective to discuss how the development process is going, along with a planning meeting to discuss what we’ve actually accomplished and what we plan to do during the next one to three 2-week sprints. A demo may be held at these 2-week boundaries if product owners aren’t constantly involved in the project. These bi-weekly rituals of retrospective and planning meetings are usually performed in 2-3 hours, with the retrospective usually lasting for about an hour.
Our ‘Usual’ Retrospective Pattern
In our one hour long retrospectives, we usually silently write items on sticky notes with the following categories: “Things that went well”, “Things we could do better”, and “Things that puzzle us” (+, -, ?). We then silently group the items, circle each logical grouping, and then dot vote to select which grouped topic the team would like to talk about the most. Usually there are 25-40 idea notes that result in 6-8 groups and we use three dot votes per person. The sticky note groups usually end up being 1-3 code or product-specific groups, one for infrastructure or build environment, one for team process, and sometimes a group for team personnel availability or changeover. After dot voting, we discuss the groupings of notes which received the most votes (usually 2-3 groups) and identify action items for investigation or follow up. These actions are written on a sticky note and handed to the issue owner as a reminder. No other documentation than that.
When I worked on a project where the team was distributed and couldn’t meet face-to-face for retros, we used online presentations with color-coded sticky notes so that everyone could simultaneously edit it. An interesting thing with color-coded notes is that you can see from one sprint to another whether there are more negative (red) or positive (green) items that sprint.
After 2-4 sprint retrospectives, newly formed teams seem to understand and easily follow this repeatable pattern of jotting down comments, grouping them, voting, and discussing. However, by sprint 10-12, complacency starts to settle in. The topic groupings seem to repeat every retro, the team feels like they are simply going through the motions, and they may start to suggest that retrospectives are only held every other sprint instead of every sprint. That boredom and loss of focus or creativity is the problem I’m looking for solutions to. If a team is simply going through the motions, I don’t think their retrospectives will be as effective. The retros won’t bring issues to the surface as early and the team won’t have the same drive to brainstorm solutions or decide on experiments to improve the development process.
Alternative Retro Styles to Add Variety
Researching alternatives, I found lots of resources online. Funretrospectives.com and tastycupcakes.org have some ideas, and retrospectivewiki.org has an interesting meta-retrospective idea. My favourite was the way the various retrospective ideas are grouped and visualised on the Retromat website.
I chose to run my next retrospective with the activities 82-69-12-23. A few of our team members don’t usually talk as much, so I tried to draw them in with the Three Word Opening Comment activity. After the “What Could Go Wrong” activity, the team said that they didn’t like it because it seemed too easy to just list all the opposites of agile philosophy. But the Start-Stop-Reuse activity ended up being a useful substitute for our normal good/bad/question note format and actually caused several “ideal scenario” ideas to surface for the first time. This helped me realize that it’s important to use an ideal scenario activity every once in a while to bring up those larger-change ideas. With my distributed team the quick “scores on the doors” activity seemed to go quickly enough and for the first time provided concrete feedback on how our retrospectives were going. I think I’ll do this in the future to force team members to give feedback. We could even do feedback votes on individual activities to decide which ones to use again in the future.
An example “Sail Boat” retrospective, which helps bring up “ideal scenario” ideas:
I also found that the Coggle.it mind mapping tool was quite useful for Fishbone or 5-Why exercises digging into the root causes of a particular issue. An example from our project is shown here:
Retrospective Ailments and Cures
At our week-long company camp this June, I held a session on Retrospective Variety and we did the “Retrospective Surgery – Ailments and Cures” activity to discuss common issues we’ve seen and actions that we can take to improve our retrospectives. Our conclusions about possible solutions are summarized below:
|Retro comments are the same every time. Did anything change?||Capture action items, follow up during sprint, and start with those at the next Retro. Try different retrospective activities. Let dot voting navigate discussions to different topics.|
|Retro style is the same every time.||Try different activities to introduce a little variety.|
|Runaway discussion, dominated by a few members.||Facilitator turns their back to that individual and asks the rest of the team for input (non-verbal feedback).|
|Lean Coffee – use a 5 minute timer during topic discussion. When timer rings, thumbs-up/down vote on whether to continue or move to the next topic.|
|Retrospective Action Items are forgotten.||Assign an owner for each action item. Publish the action items. At next retro, review resolution of actions from previous retro.|
|Clients don’t value Retrospectives.||Explain that a re-occurring process improvement discussion helps surface conflicts/issues earlier. Changes/Experiments for improvement are proposed and acted upon. Make team issues visible to client/management as a group. (Try “Why Retrospectives?”)|
|Client is present at retrospectives and team is reluctant to express some issues.||Interleave team-only with team-plus-client retrospectives (team-only every 2nd or 3rd retro) so that team has some private time to discuss all internal issues. Also emphasize client attendance sometimes when they are involved in a problem or can champion a resolution.|
|Retro style tends to focus on Extroverts.||Use sticky notes and silent brainstorming and note grouping to encourage everyone to participate. Introverts may not jump into a verbal discussion.|
|Too many people in a retrospective – not enough time for each person to talk.||Use “Open Space Technologies” method. People propose topics to discuss, then everyone joins the discussion topic that they are most interested in. Small group discussions are more focused and results are shared with the whole group at the end.|
|Retro only focuses on activity in the last few days of the sprint.||Use a physical “mail box” where issues/topics can be dropped off throughout the sprint so that team can remember what occurred.|
|No real feedback about whether team members find the retrospectives useful.||Use a quick feedback mechanism such as sheet of paper at the door where people can mark a 1-5 score of whether they liked it or felt that it should be repeated.|
It takes some effort to choose alternative activities and break out of our normal pattern, but the ROI is a more engaged team and a more enjoyable process. I don’t usually like playing games during retrospectives (just to make it more fun) because it doesn’t seem to add business value, but choosing different formats of questions will provide some variety and help your teams take a different perspective on how to improve your workplace and processes. So which retrospective activities are you going to hold at the end of your next iteration?