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 Perficient Latin America 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 Perficient Latin America, we’re constantly learning.
General Retrospective Tips to Follow
- Teams should be in charge of making the retrospective work. While we as a company try to clearly illustrate the value of retrospectives to our teams, we have clients that don’t require them. For this reason, it is important that each team remain responsible for their own retrospectives. Autonomous teams need to be able to manage the process of completing the retrospective and realizing its benefits on their own, rather than by following a process dictated by Perficient Latin America, which could hinder team evolution or innovation.
- Leaders need to understand the makeup and characteristics of the various team members in order to schedule and run effective meetings. Are people working remotely? Do you have a large team that needs more time to discuss or make more pointed questions? Does X person always share their opinions? Is Y more likely to avoid speaking?
- Create a culture of understanding, respect and growth. Your team will not improve if you avoid talking about mistakes or painful failures. We do our best to create a company-wide culture that views mistakes as an opportunity to improve, but team members also need to champion this ideal in every situation, including retrospectives.
- Keep an open retrospective board for people to write their notes during the Sprint. Team members can’t be expected to remember everything that happened, good or bad. It’s much better if you can all make notes or comments and use that information to drive the retrospective the next time. This also helps to clear the air quickly when things need to be addressed immediately and not later in the retrospective.
Strategic Retrospective Planning for New and Experienced Teams
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!]
Change Up Your Retrospective with Diverse Activities
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 | Perficient Latin America Wins Spot on IAOP Global Outsourcing 100 List for 2020!]
Retrospectives for the Win
With retrospectives, teams can start to identify problems and propose solutions by themselves, creating truly autonomous teams. When teams stumble upon a wall or blocker, it is better for those teams to collaboratively find a solution by themselves, strengthening the notion of team commitment and autonomy, which are essential components of high-performance teams in both DevOps and Agile scenarios.
When software development teams avoid retrospectives, it’s like they’re saying “we’re already perfect; there’s nothing we can do to improve,” which is generally far from the truth. There are always ways that teams can improve, pursue excellence, and stay on the path of continuous improvement—a retrospective meeting is one of the best methods to achieve this consistently.
—-
Retrospectives aren’t the only agile ceremony we are conducting. Contact us to talk about how we use agile methodologies and a DevOps mindset to deliver high-quality, nearshore software development services.
