After Inspection, Comes Adaptation: How to Do Action-Based Retrospectives Right
This article will dive into the value of action-based retrospectives, the importance of creating action items, and how to ensure your team follows through.
Join the DZone community and get the full member experience.Join For Free
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” — Agile Manifesto
Self-reflection within teams is fundamental to enabling Agile ways of working. Let’s take the most common Agile methodology, Scrum. This framework prescribes five events, one of which is the retrospective.
A retrospective exists to serve the three pillars of Scrum: transparency, inspection, and adaptation. At the end of each sprint, it happens as an occasion for team members to discuss the last iteration, identifying aspects that went well and others that need to be improved.
At the end of a retrospective, a team should have identified improvements to implement in the following weeks. In a 2017 survey, 97% of respondents from the Agile community reported creating action items at the end of their retrospectives. But only 12% stated they always assign deadlines to these action items.
Without deadlines, there is no timeline to follow through, and without them, most action points will fail to be implemented. Therefore, the inspection part of Scrum that happens in the retrospective is not followed by the next logical step: adaptation.
This article will dive into the value of holding action-based retrospectives. We will see the importance of creating action items and how to make sure your team follows through.
Retrospectives Benefit Your Business: Here’s Why
When done correctly, retrospectives put into practice the 5 Scrum values: commitment, courage, focus, openness, and respect. In addition, the very nature of retrospectives makes them an opportunity for inspection and adaptation. Failing to have them is missing out on that opportunity, compromising the constant improvement that teams should strive for in an Agile environment.
It doesn’t make sense to do the same thing and expect a different outcome repeatedly. Therefore, having a retrospective gives your team a time and place to discuss together a way to change the way they work. Moreover, it does so without hierarchies, putting everyone in the team at the same level and giving them the same power to open up and share their views.
Finally, retrospectives are a way to celebrate the team’s wins which, science shows, is an effective way to reinforce the learning experience and strengthen our sense of connection to those we work with.
You want to think of your retrospectives as “action-based.” They are not only a moment to reflect but also the birthplace of action items. Then, these should be implemented, benefiting the team’s performance and work.
Action-based retrospectives usually follow the structure defined by Esther Derby and Diana Larsen in their book “Agile Retrospectives”:
Set the Stage: Remind the team that the goal of the meeting is to reflect on the past week’s work and determine specific actions for moving forward.
Gather Data: Ask team members to share their thoughts, perhaps writing them on sticky notes.
Generate Insights: Usually with affinity grouping and dot voting.
Decide What to Do: Take time to come up with action items.
Wrap Up: Take time to confirm that your team has a shared understanding of the defined action items.
Most Common Reasons Why Retrospectives Go Wrong and How to Overcome Them
Retrospectives are essential, but they are not always done right. Especially teams that are Agile immature encounter difficulties that compromise the retrospective’s value. Let’s look at some of the most common issues.
1. Team Members Can’t Agree on Action Items
Often, team members’ opinions on how to fix issues vary. When opinions are too distant, consensus might be hard to attain. If this is something you struggle with, provide your team with Agile training and your Scrum Master with knowledge on how to be a better facilitator.
2. Nobody Feels Responsible for Action Items
An action item must be assigned to someone; otherwise, it will never get done. If the responsibility should be split between team members, write all their names, but don’t let an action item go by unassigned. If nobody wants to take responsibility, scrap it, it means it’s not that important for the team.
3. Action Items are too Vague
Action items should be SMART: Specific, Measurable, Attainable, Relevant, and Time Based. Goals formulated like this use a specific set of criteria to help ensure that objectives are clearly defined and attainable within a certain timeframe, thus improving their chances of being implemented.
4. Team Members Blame Each Other Instead of Taking Responsibility
Some people focus on what others did wrong and don’t take the time to perform a self-analysis. This leads to not-so-productive retrospectives. In these cases, the facilitator should emphasize the “you” of this member rather than the team: “What can you do about it?”
5. The Team Already has a Rule for a Certain Issue
Sometimes, topics come up only to be dismissed by “we already have a rule for that.” This implies that if everyone followed the established rules, the issue wouldn’t emerge again. However, if it did, most likely, it’s because the existing rule doesn’t work.
Treat this as a new problem and discuss it within the team to assess what can be improved about the existing solution.
6. The Team Discusses the Same Topics Over and Over Again
Always using the same retrospective format might kill people’s creativity. If you manage to unblock team members’ inhibitions, they will feel freer and more open to exposing themselves and their feelings.
Try using different formats for the meeting and do distinct exercises. For inspiration, Fun Retrospectives is a good place to check.
How to Increase Follow-Through on Action Items
As we have seen above, only 12% of Agilists always assign deadlines to action items. We have also understood the importance of defining such items. But how can we make sure they are followed through? Here are some tips.
1. Quality Over Quantity
A lot of issues come up in retrospectives. Some concern the whole team, while others are specific to only a few people. We are not saying that individual-specific issues are not worth being looked at, but issues that concern more people should be prioritized. And when you get to the more specific action items, if possible, create them in a way that benefits the whole team.
2. Separate Concerns
Consider creating two separate moments in your retrospectives: one for inspection and one for defining action. In the first one, the team discusses all the issues that arose during the sprint without establishing any action point.
In the second, the team thinks about solutions for the problems discussed earlier. Often, there are linking issues that will be missed if you immediately create an action item for each point you discuss.
Furthermore, when defining action items, consider separating the goal and the actual action item. Team members can usually agree on the goal but have different ways to go about it. If you have a common understanding of what the goal is first, the discussion on how to do it is more accessible.
3. Create a Moment to Review Action Items in Your Action-based Retrospectives
You create action items in your retrospectives and attribute a deadline to them — so far, so good. But if you never check whether they were completed, how do you know the team is improving?
Consider creating a section in your retrospectives to review action items from previous meetings. This doesn’t need to take long: simply go over the list of action items and, out of those whose deadline expired, check with your team members if they are implemented or not. If not, ask about possible impediments and check again later on.
4. Define Actionable Action Items
Many teams fall into the error of creating action items that are not specific or measurable. Items like “improve communication within the team” should be rewritten following the SMART structure we mentioned above and always be Specific, Measurable, Achievable, Relevant, and Time-bound.
5. Create Enough Time for the Team to Come up with Action Items
If you leave the moment of creating action items to the end of the retrospective, as we suggest above, make sure that there is enough time for the team to brainstorm solutions.
If you let the previous sections take up too much time and then, pressed by the deadline, leave only 5 minutes for the team to come up with action items, this will most likely be far from ideal. Instead, consider time framing every section of the retrospective to allow enough time for everything.
6. Don’t Create a Backlog of Action Items
What is important for the team will come back at a later retro if the issue persists. Sometimes, it gets fixed on its own: maybe it was specific to that sprint, or it only concerned a couple of people, and they found a way to fix it together. But don’t create a backlog of issues, as this only creates an overhead you will never get to resolve.
Corinna Baldauf, author of the blog post Retrospective fatigue? How to increase follow-through on action items, mentions why having action-based retrospectives is important:
The whole point is to inspect and adapt, i.e., change something. If few of the retrospectives’ action items ever get implemented and bear fruit, it’s frustrating. Ultimately it leads to retrospective fatigue where teams are unwilling to participate in the retro anymore because “What’s the point anyways? Nothing ever changes.”
Retrospectives are supposed to contribute to your team’s continuous improvement. Therefore, you need action items that emerge from these meetings and are implemented, leading to change and improvement.
One Final Tip: When creating action items, always include the “why.” Author Daniel Pink, who wrote about motivation, states that “employees who find purpose in their work unlock the highest level of motivational potential. Joining a cause that is ‘bigger’ than yourself drives the deepest motivation possible.”
Published at DZone with permission of Søren Pedersen. See the original article here.
Opinions expressed by DZone contributors are their own.