Agile retrospectives are not usually the most exciting aspect of software development, but they can be far more engaging when seen as a platform to motivate teams.
Retrospective meetings provide a valuable opportunity for agile or DevOps teams to reflect on the ups and downs of each iteration, allowing them to identify actions for improvement going forward. However, the meetings can sometimes seem dull and pointless to developers, who just want to get back to coding.
Over the past couple of years, retrospectives have evolved at PSL and we consider them a very valuable part of the agile ceremonies. From that point of view, we've gathered insights into how to make retrospectives more engaging for all involved and what things to avoid. This is by no means an exhaustive list and, as with everything we do at PSL, we're constantly learning.
One of the most common issues we've noticed is teams failing to schedule retrospective activities altogether. Some teams might hold a couple of retrospectives at first but then drop the meetings soon afterward.
The core reason that teams either lose interest in retrospectives or avoid holding them is a lack of proper structure or strategy, so use the following steps to plan meetings and boost team engagement. This may be compounded by working within a staff augmentation model. If the client hasn't included retrospectives as part of their agile ceremonies, it can be especially tricky to get the team to do them outside of normal expectations.
For those that are not familiar with retrospectives, step one is to set the stage and get people focused on the objectives of the meeting, ensuring they know that the retrospective is held at a specific time. It's important that everybody brings a proactive attitude to the meeting, as that will lead to more valuable results. It's helpful if everyone understands the objective is not to point fingers or place blame, but to understand what went well, what the issues are, and what the team can do to improve.
Following previous retrospectives, it's vital that you start by reviewing the commitments made by the team in the last retrospective and check on their status. If you don't do this, you lose one of the main goals for having a retrospective in the first place; improvement.
A common misstep here is when teams go way too deep on all the issues that come up, which sometimes proves to be an inefficient approach and wastes time. It's good practice to prioritize each issue as it becomes apparent, as the team can focus on the main issues or problems they face instead of getting bogged down on everything at once.
Once this information has been prioritized, you can begin to generate insights and an understanding of what worked and what didn't during the last sprint. It's important for teams to go beyond what is evident here and find the aspects of the project that need to remain as they are, improve, or change completely.
When the issues are clear, decide what to do next. Make a list of the possible experiments or courses of action that the team can take that will lead to improvements. Again, it's important to prioritize these actions because not everything can be done in one sprint.
You can then close the retrospective on an upbeat, positive note, sending the team away with new levels of motivation and a clear strategy.
For further resources for those just starting out, the strategies laid out in Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen, are incredibly useful in retrospective planning.
[Looking for the most experienced providers in nearshore development? Let's talk!]
In each of these stages of a retrospective, it helps to introduce several fun activities that really facilitate and encourage the participation of team members.
When setting the stage, try the "Satisfaction Histogram" activity, which can be a good way of facilitating the setup process.
In this activity, each participant selects his or her level of satisfaction during the last sprint from a general point of view and then proceeds to explain it to the team.
For this activity, it is important to have a specific time frame for each participant to explain what led him or her to choose their level, otherwise, it can quickly bleed into the second stage of the retrospective.
After a few more iterations or sprints, you can use this information to review how the team has progressed, either giving them a reliable sense that the team is getting stronger or encouraging them to find issues and improve them.
When gathering data, the "Mad, Sad, Glad" activity is very helpful as it allows the team to share their feelings without judgment or reprisal.
During this activity, each participant has seven minutes to identify every moment or situation that caused certain feelings—mad, glad, or sad—to arise in the previous sprint. They then write them down on a post-it or sticky note and talk to the group about those feelings or ideas.
The idea is to embrace transparency and boost team camaraderie while highlighting any operational faults or strengths within the team. This is especially useful for DevOps teams as it expedites the time it takes for developers and operations engineers to learn about each other's respective roles.
When it comes to generating insights, there are a couple of useful techniques that can be used.
First, the technique of "Five Whys" helps to find the real causes of a problem by repeatedly asking the group "Why?" in relation to a particular problem or issue. This technique assumes that answering why five times will give the team a deeper understanding of the problems on hand. Also, it's fun to act like a five-year-old child every now and then.
The Fishbone technique, also known as the Ishikawa diagram, allows for a more causal analysis without losing sight of some aspects that could be lost with the Five Whys technique. It's useful in identifying the possible causes of a problem, revealing areas of weakness, preventing recurring issues, and ensuring corrective actions are put in place to resolve them.
It helps to label each branch of the problem with a percentage to highlight the level of contribution the problem has to the overall project.
To decide what to do, one of the most productive ways is often for pairs of team members to perform brainstorming activities.
In a window of around seven minutes, get each pair to write down specific activities that can be assigned to someone in the next sprint. After explaining them to the group, the proposals are grouped by category and voted on by the rest of the team. Each participant is given five votes that can be distributed as they wish among the proposals. The three or four proposals with the most votes then get assigned to the group.
To ensure this activity pays off, it is very important to assign a responsible team member to each proposal that can ensure that the team follows through.
When closing the retrospective, a "Thank You" session is a great way to finish things off. Each team member picks another team member to thank and explains why he or she is doing so, boosting solidarity and making everyone feel like they are participating on an impactful level.
If you're interested in more activities, a good resource is the "Plans for Retrospectives" website, where there are hundreds of retrospective activities available. When combined thoughtfully, you can end up with endless different retrospective meetings, so there are no excuses for not making your retrospectives as diverse as possible.
[TRENDING CONTENT | PSL Wins Spot on IAOP Global Outsourcing 100 Lis