Taking the scrum retrospective to the next level | David Tzemach
Updated: Mar 2, 2022
The sprint retrospective meeting is one of the most important meetings in the scrum framework and should be treated responsibly. However, planning and running an effective scrum retrospective is easier said than done. Over the years, I’ve learned that some essential tips can help increase the effectiveness of these meetings.
A few words about retrospectives
Retrospectives are essential because they allow the team to concentrate on the things that keep them from fulfilling their full potential in the agile environment and share the things that are working for them and that they want to preserve. During the meeting, the team has a safe space to discuss problems. But that is not all: the meeting also allows the team to feel empowered and share their achievements, celebrate successes and increase their morale.
So what can go wrong?
It is easy to understand why retrospectives are essential as (what I love to call) the “engine” of improvement. However, there is a considerable gap between using a preliminarily written script and having a retrospective. It can work maybe once or twice, but it usually starts to negatively impact the team to the point where they begin treating the retrospective like another meeting that they are forced to participate in because of its 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 thoroughly excited to share their problems in the retro meeting, but one week later, the scrum master presents the impediment board with the same issues without any real change. How do you think it will influence the team’s willingness to share their thoughts? Why would they share them if they knew that nothing would change? As I mentioned, retrospectives are critical for the team and probably the most efficient way to improve the process and team motivation and teamwork. Therefore, the big question is 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 that I hope will help you.
Tips
A safe environment is critical.
Retrospectives allow team members to share impediments that hold them from achieving their full potential. As such, team members must feel safe to share their insights about any problem that 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 choose not to share. This makes it impossible to mitigate problems and achieve continuous improvement.
A few things that can help:
Once you recognize that a team member has nothing to say, have a 1:1 conversation post-meeting to understand the actual cause. Team members that do not share information are most 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 personal blame.
Do not cancel the meeting.
Although retrospectives are very important for the team, the team will often cancel the meeting because they do not have the time, power, or motivation to have it. In addition, in many cases, there is an external crisis such as a critical bug in production, customer issues, etc., that forces the team to cancel the meeting. The basic rule is that you must ensure that there is room for retrospectives no matter what. If you cannot conduct it at the ordinary time (usually the last day of the sprint after the review meeting), ensure the team finds the time to run 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 meeting were implemented. This shows the team that there is a remedy for their problems. Will team members want to participate if there are no real answers or improvements for their items? To provide suitable solutions, we must start from the basics.
What do I mean by basics?
Start with documenting those problems that allow tracking (an impediment backlog is a good start).
Make sure to 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 to show the team the improvement from the previous sprint
By following these simple steps, I can assure you that your retrospectives will become much more efficient and increase collaboration from the team.
Break the Ice if needed
The best retrospectives that I have taken part in were ones in which every team member had the confidence to say whatever they wanted to without being judged by the 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 scrum master 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 scrum master should start with their thoughts about the previous sprint if no team members volunteer to break the ice. If you do this, the chances are that the rest of the team will feel confident enough to share as well.
Another option for breaking the ice is by asking the team a simple question, such as “How do you feel today?” or “Does anyone want to start to share their thoughts?” or “It was a great sprint for us; what do you think?”
Facilitation is the foundation of every great retrospective.
The facilitation process is relevant to all scrum meetings but is particularly relevant to retrospectives. Why is that, you may ask. What is the difference between this and other meetings? Well, besides the obvious differences, there is one thing that pops out. The team strictly owns retrospectives; external stakeholders are not allowed in (which they are in all other meetings as contributors or silent observers).
A few things that can help:
Don’t invite any stakeholder who could influence the team’s freedom to speak. Ensure that external stakeholders that arrive without notice do not take part.
Ensure that all team members are familiar with what is expected from them during the meeting.
If the team wants to add external stakeholders (which is possible with the approval of all team members), make sure that they know the meeting rules and what is expected of them.
Make sure all team members arrive prepared for the meeting.
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 since the last retrospective. The team will be more motivated to participate if they see that their ideas, complaints, and words mean something and were not made in vain. As part of each retrospective, the team can share many items they want to improve that require more minor changes or share only a few items requiring more effort of one or more sprints. Now, what matters here is that you show some progress, even when you do not have the complete solution for their problems. Keep in mind that each item is prioritized, and you, therefore, need 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 that focus on their problems forget to talk about what went well and what they want to keep. 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 always are positive aspects. My suggestion is to always create a balance and discuss both the positive and negative aspects. During this time, you 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 scrum master is usually responsible for facilitating Scrum events. However, 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 scrum master to remain the meeting facilitator. In my opinion, it is a good idea that the meeting facilitator is changed each retrospective. By following this practice, the team will gain more ownership of the process and want to participate because they know they can impact the team’s empowerment. Once you decide to follow this practice, you must let each member conduct the meeting following their own personal approach and agenda (under the clear boundaries of the meeting), which will help 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 that I usually use during retrospectives are:
Do you think that our retrospective is efficient enough?
Is there anything that you want to change in the process of the next retrospective?
At the end of the meeting, can you share feedback on the meeting?
Retrospectives in a different location
One thing that I’ve found to be very helpful in boosting creativity, brainstorming, and motivation is to conduct retrospectives in different locations once in a while. Running the same meeting in the exact location creates a routine that we do not want to see 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, there is a significant rule that I always make sure to keep: to understand the root cause of any item and not just its symptoms, which is usually what is provided in the original input.
The best example for this issue is if there is similar input every sprint. There are many reasons for this, and it’s 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 I will share in subsequent posts, but one approach that always works is RCA using the five whys (search for it, and you will see why).