Taking the Scrum Retrospective to the Next Level | David Tzemach
Updated: Mar 2, 2022
It is easy to understand why retrospectives are important as the improvement engine of the team. However, there is a difference between using a preliminary written script and having a retrospective. It can work once or twice, but as it progresses, it starts to negatively impact the team, to the point where they begin treating the retrospective like another meeting they are forced to participate in because “it is part of the Scrum framework.”
Another crucial issue is impediments that are not handled and monitored by the Scrum Master. Think about a team that is excited to share their problems in the retro meeting, but one week later, the Scrum Master presents the impediment board with the same problems and no real change. How do you think it will influence the team’s willingness to share their thoughts? Why would they share them if they feel nothing will change?
Retrospectives are critical for a team and probably the most efficient way to improve not only the process but also the team’s motivation and teamwork. Therefore, the question remains: how to make each retrospective better than the previous one? To answer this question, I’ve created a list of tips that helped me throughout the years and that I hope will help you.
A safe environment is critical.
Team members must feel safe to share their insights about any problem they see. If the meeting environment does not allow them to feel comfortable and safe to share those insights, the chances are that they will not share them. This makes it impossible to mitigate problems and achieve continuous improvement.
A few things that can help:
Once you recognize a team member has nothing to say, have a one-to-one conversation after the meeting to understand the real cause. Team members who do not share information are often the ones that have the most significant contribution.
Ensure that the meeting is conducted in a comfortable physical environment agreed upon by all team members.
Avoid finger-pointing during the meeting. Retrospectives are not about blame.
Do not cancel the meeting.
Although retrospectives are essential for the team, there are often occasions when the team will cancel the meeting because they do not have the time, strength or motivation to have it. Sometimes there is an external crisis such as a critical bug in production, a customer issue or something else that forces the team to cancel the meeting.
The basic rule is that, no matter what, you must make sure that there is room for retrospectives. If you cannot conduct it at the regular time (usually the last day of the sprint after the review meeting), make sure the team finds the time to conduct it the following week, before the planning meeting. If you still cannot find the time, at the very least, provide a platform for the team to share their inputs and discuss them as early as possible during the next sprint.
Are the meeting outcomes actionable?
The value of retrospectives can be measured by a simple test of how many of the items raised during the previous meeting were implemented. This shows the team that there is a remedy for their problems. To provide suitable solutions, we must make sure we start from the basics:
Start by documenting the problems to allow tracking (an impediment backlog is a good start).
Make sure you prioritize the items that provide the most ROI for the team, and always let the team decide which items are most important to them.
Make sure that each item can be mitigated with a practical action plan; items that cannot be mitigated with an action plan must be re-discussed and broken into smaller items.
Set the goals, and do not commit to items you cannot handle.
Make sure you show the team the improvements from the previous sprint.
By following the above, your retrospectives will become much more efficient and result in increased collaboration from the team.
Break the ice if needed
The best retrospectives I took part in were when every team member had the confidence to say whatever they wanted to, without being judged by other team members. Retrospectives will never be as good as they can be when team members do not feel comfortable, confident, and in a safe place.
A few things that can help:
The SM should start the meeting with general clarifications about the meeting’s rules of engagement and ensure that every member feels safe enough to speak.
The SM should start with his thoughts about the previous sprint if no other team member volunteers to break the ice. If you do this, the chances are high that the rest of the team will feel confident enough to share.
Another option for breaking the ice is to ask the team a simple question, such as “How do you feel today?” or “Does anyone want to start sharing their thoughts?” or “It was a great sprint for us; what do you think?”
Review progress from the last retrospective
The main target of a retrospective is to help the team flourish while removing the impediments that hold them back. One of the keys to increasing collaboration and team motivation is to show them their progress from the last retrospective. The team will be more motivated to participate if they see that their ideas and complaints mean something and were not made in vain.
As part of each retrospective, the team can share many items they want to improve that requires more minor changes or share only a few items requiring the efforts of one or more sprints. What matters here is that you show some progress, even when you do not have the complete solution to their problems.
Remember to address the essential items first. If the top items are blocked, do not wait but start mitigating the other less prioritized items and move back to the top prioritized items when possible.
Make sure you cover the positive aspects.
Unfortunately, many teams focus on their problems and forget to talk about the things that went well. Talking about what went well motivates the team by showing them the things that helped them succeed and maintains the team's good collaboration and hard work habits.
Talking about the positive aspects also allows the team to see that there are always positive aspects. My suggestion is to create a balance and discuss both the positive and negative. One should show the team how the negative items (that were mitigated) became strengths and not weaknesses. Tracking will provide the best platform for the team to understand the importance of the meeting and its benefits.
Rotate the meeting facilitator
The SM is usually responsible for facilitating Scrum events. However, I believe this may be more relevant to new teams that just started an Agile transformation and are still not self-organized. Once the team becomes self-organized, there is no reason for the SM to remain the meeting facilitator.
In my opinion, it is a good idea for the meeting facilitator to be changed every retrospective. By following this practice, the team gains more ownership of the process and will want to participate because they know they have real influence.
Once you decide to follow this practice, you must let each member conduct the meeting following their approach and agenda (within the boundaries of the meeting). This helps increase their motivation to succeed as meeting facilitators.
How efficient is your retrospective?
A common failure of Agile teams is their inability to determine how efficient their retrospective is. The team must include items on the retrospective itself to determine if they can improve it or not. Questions I usually use during retrospectives are:
Do you think that our retrospective is efficient enough?
Is there anything that you want to change for the next retrospective?
At the end of the meeting, can you share feedback on the meeting?
Retrospectives in a different location
Another thing that I have found to be very helpful in boosting creativity, brainstorming, and motivation is to conduct retrospectives in different locations once in a while. Performing the same meeting in the exact location creates a routine that we do not want in Agile teams. I suggest taking the meeting outside the office every two to three retrospectives, such as at a coffee shop or the beach. Just give it a try, and I assure you it will be worth it.
Root cause vs symptoms
Retrospectives are made to allow each team member to share the impediments that affected their ability to succeed. Therefore, when looking at what needs to be improved, it is essential to understand the root cause of any item, not just its symptoms, which are usually provided in the original input.
The best example is when there are similar inputs during every sprint. There are many reasons for this, and it is essential to correlate between the items to see that you cannot fix the issue without understanding its root cause.
You can use many techniques for root-cause analysis (RCA), which are described in later chapters, but one approach that always works is using the five whys.