Over the past couple of years, I’ve had the opportunity to facilitate retrospectives for several software development teams within Perficient Latin America and gained some insights and lessons learned that I would like to share.
One of the most common issues for the teams which I’ve facilitated retrospectives is that they did not schedule retrospective activities as part of their software process. Other teams had a share of their own problems when facilitating retrospectives, while others made their retrospectives for a couple of times and then stopped since they didn’t find them very useful… well… you can see that a dramatic change of strategy was needed!
Among several books on the topic, I relied on the retrospective structure and strategies laid out in “Agile Retrospectives: Making good teams great” and other recommendations by a highly regarded coach in the region for planning the retrospectives. It includes the following key points or steps:
- 1.Set the stage: getting people focused on the objectives of the meeting, in the specified time and with a proactive attitude.
- 2. Review the commitments made in the last retrospective: if there was a previous retrospective meeting, it is important to review the commitments made and check on their status.
- 3. Gather data: achieving a common view of the situation to analyze both objective and subjective data and information. It lays out the common basis of facts, events, feelings that allow more effective development of the rest of the meeting.
- 4. Prioritize data: make sure the right information is presented and first.
- 5. Generate insights: understanding what went wrong and what went well during the last sprint. It is important for teams to go beyond what’s evident, and to find the root causes that need to remain, improve or change.
- 6. Decide what to do: taking a list of possible experiments and courses of action that the team can do to improve. It’s important to prioritize because not everything can be done for the next sprint.
- 7. Close the retrospective: ending the retrospective clearly, on an upbeat and positive note, and define next steps as noted above.
Points number 2 and 4 seem vital to me because, on one hand, it is not a good practice (or “retrospective anti-pattern”) to not review the commitments made in a previous retro. Also, a usual misstep, which is mitigated by these steps, is to try to extensively cover all the issues that come up in the retrospective meeting, which sometimes proves to be inefficient.
Sample activities that can be used in each of the retrospective’s steps
In each of the stages of a retrospective, I have used several fun activities that really facilitate and encourage the participation of the team members. Some of my favorites (that I can personally vouch for) include:
To set the stage: The “Satisfaction Histogram” activity is a good way to help during the setup process. Each participant selects his or her level of satisfaction during the last sprint from a general point of view and then proceeds to explain to the team. The levels are:
5– We are the best in the world! What a great team we are!
4– I am proud to be part of the team and how we work.
3– Quite satisfied, we work well together most of the time.
2– Sometimes I’m satisfied, but not so much.
1– I am unhappy and dissatisfied with the level of teamwork.
For this activity, it is important to have a 2-minute time box for each participant to explain what led him or her to choose their level, otherwise, it can quickly become an activity for the second retrospective key step, which is getting data.
You should review the team progress after 2 or 3 more iterations or sprints.
To gather data: the “Mad, Sad, Glad activity is very helpful in this regard. During this activity, each participant identifies, in 7 minutes, every moment or situation that caused those feelings to arise and writes it down in a post-it or sticky note and then they talk to the group about their feelings or ideas.
To generate insights: I found a couple of techniques useful for this step. First, the technique of the “5 Why’s” helps to find the real causes of a problem by repetitively asking the group “Why?” several times for a particular problem or issue. This technique assumes that after answering 5 times to “Why” questions, a team gains a deeper understanding of the problems on hand. While this technique may be useful for a retrospective, I feel that the fishbone technique (also known as the Ishikawa diagram), allows a causal analysis without losing sight of some aspects of the discussion that are potentially lost with the technique of the 5 Whys. It is very important that the team puts the percentage of contribution to the problem of each branch of the diagram.
To decide what to do: The best way I’ve seen to assist in this step is to perform a pair brainstorming activity. In a time box (around 7 minutes or so) the pair proposes specific activities that can be assigned to someone in the next sprint. After 7 minutes, each pair explains their proposals, which are then grouped by categories in which all of the different groups are included as well. Finally, each person is allowed to vote for the ideas they like best. Each participant is given 5 points, which can be distributed as they wish among the proposals. The 3 or 4 proposals with the most votes are the ones that will be assigned to the group.
It is very important that the activities that were selected, have a team member that is responsible that ensures them getting done.
To close the retrospective: A “Thank you” session works great, in which each team member picks another team member to thank and explains why he or she is doing so.
In my experience with retrospectives, these activities have been very successful, however, it is important to make them as diverse as possible. On the “Plans for Retrospective” website, there are hundreds of retrospective activities, which combined, can make up to a million different retrospective combinations. So there are no excuses on making your retrospectives as diverse as possible.
Summary
One advantage of using the proposed structure is that there are certain activities that encourage the participation of people who may have never participated before. On one retrospective which began using this structure, there was a consensus that the people were happy, including teammates that don’t actively participate by speaking, which is quite rewarding.
Another positive aspect is that the same team can identify problems and propose solutions by themselves. As a retrospective facilitator, I only participate when I see that there is a concept within the agile framework that is not entirely clear. I believe that when teams stumble upon a wall or blocker, it is better for those teams collaboratively find a solution by themselves, strengthening the notion of team commitment, which is an essential part of high-performance teams.
When a software development team does not do retrospectives it is a bit like saying: “We are perfect, there is nothing we can do to improve,” which generally not true. There are always ways to improve, to pursue excellence, and to stay on the path of continuous improvement. A retrospective meeting is one of them.
Want to know more about how good Agile practices can help your next outsourced software development project? Contact us!.
More on Perficient Latin America: Perficient Latin America specializes in outsourcing and nearshoring Agile software development, software maintenance, quality assurance, and staff augmentation. With offices in Colombia, Mexico, and the US, Perficient Latin America has customers all over Latin and North America, ranging from tech startups to Fortune 500 companies.
