A key part of an agile process is the retrospective. The purpose of retrospectives is to identify where you can improve and reinforce what you are doing well as a team.
They typically happen at the end of each sprint in Scrum, at regular intervals in kanban, or after something goes wrong in your organization. A popular retrospective format is SAMOLO—talking about what we should do Same As, More Of, Less Of. This assures we are discussing what’s working and what’s not.
Unfortunately, many retrospectives are not productive. It may be that the discussions are unfocused, not enough data was gathered to be helpful for analysis, or the team concentrates too much on issues they can’t control.
Here are five tips that I believe will help lead you to having valuable retrospectives.
1. Don’t Put Them Off
Retrospectives all too often get canceled, are usurped by a crisis, or are deprioritized. In Scrum, if a retrospective is set up as a part of the sprint wrap-up, it is important to hold it before the end of the sprint so improvements and feedback are incorporated in the next sprint.
If you are not able to have your sprint retrospective prior to the end of a sprint, make sure the team at least discusses its challenges during the next sprint planning meeting so that you keep in mind the issues that plagued you or helped you last sprint. Having retrospectives after releases in Scrum are valuable as well to make sure future releases are smoother.
If you are using kanban, it is important to decide how often you will do retrospectives and keep to that schedule. Two common options for holding kanban retrospectives are to have them each week (or two)—getting them on the calendar far in advance—or to have them after something goes wrong that affects a majority of the team. For example, a DevOps team may have retrospectives after a failed or difficult deployment to make sure the issues encountered don’t happen the next time.
2. Talk about What Went Well
Unfortunately, many teams tend to dwell only on the problems during retrospectives and they turn into venting sessions, rather than where and how to improve. Talking about what went well is important for reinforcing the team’s good habits and making sure teams recognize the value and hard work of everyone involved.
Another reason we want to talk about what went well is that dwelling on the negative can significantly decrease team morale and give the entire project a feeling of a “death march.” If your retrospective is an hour long and the whole hour is about what went wrong, no one is going to eagerly participate in them going forward. If you properly balance the discussion about what went well and what can be improved, you should start to see some of the “less of” items start to appear in your “more of” column, as initial pain points and weaknesses become strengths over time. Tracking this progress motivates the team to continue to hold retrospectives, too.
3. Look for Overarching Themes and Do a Root Cause Analysis
When looking at what needs to be improved, it is important that you don’t focus only on the specific problems that are mentioned, but instead try to look for overarching themes that these problems are symptoms of.
One example is the problem of work being carried over from previous sprints. There are many reasons that this could be the case, so it is important to go through each specific story that was not completed and try to get to the root of the problem. Perhaps testing isn’t integrated well throughout the entire sprint. Maybe regression testing is manual. Perhaps a feature had to be refactored numerous times because the user story wasn’t clear. Each of these root causes point to different action items the team should consider.
4. Make Sure the Outcomes Are Actionable
While we try to balance the discussion of what went well and what did not, a key component of any retrospective is making sure improvements the team wishes to focus on are implemented. Unfortunately, action items that arise out of retrospectives are often not documented or followed through on. Without a plan of action to fix root cause issues, expect to hear the same problems over and over again in retrospectives.
For large issues, it is important to identify small, attainable goals for ongoing improvement so the team can focus on iteratively improving and seeing short-term gains. This will encourage the team to continue seeking improvements as their efforts are showing a return. For example, if a team has identified that stand-ups are taking too long and are not focused enough due to lots of side conversations that are happening, the team could decide to implement a game to reward those who identify side conversations during stand-ups and get the team back on track the most. As the goal is to make the stand-up a quicker, more focused meeting, future retrospectives can review whether playing this game solves the problem or other measures are necessary.
5. Recap Previous Action Items
If there were action items that came out of the last retrospective, it is important to recap these action items to see what progress was made toward fixing the issue. This is a good way to start each retrospective, as it reminds everyone that our focus is to always improve. If no progress was made on previous action items, it is important to identify why progress didn’t happen and either make a more conscious effort going forward, redefine or clarify the action item, or even scrap it if the issue has disappeared by itself.
Note that someone on the team should be the lead for each action item so there is accountability to make progress. The lead does not necessarily have to do all the work to fix the issue, but they should be the person making sure the team is working toward improvement.
If you keep these five tips in mind while conducting or taking part in a retrospective, then you are on your way to making your retrospectives even more valuable.
This article is a repost of an Agile Connection article.
