The last Agile Manifesto principle states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” For Scrum teams, the sprint retrospective is therefore a key meeting for continuous improvement. The results are however not always satisfying. In his book “Essential Scrum“, Kenneth Rubin discusses the most common issues in sprint retrospectives that he has noticed in his Agile coaching experience.
Sprint retrospectives are not without issues. Having worked with many organizations using Scrum, I have noticed a number of common issues.
An unfortunate issue is when teams simply don’t do the sprint retrospective, or when they do, attendance is low. The reasons for both tend to be similar. If people are assigned to multiple teams, scheduling conflicts could prevent them from attending. This is an organizational dysfunction that managers need to address. Or perhaps team members are just bored or disengaged, or they have not really bought into using Scrum. Others might think that doing anything other than their particular work isn’t worth their time (for example, they believe that anything other than coding or testing is just wasteful). Often these issues stem from naiveté regarding Scrum and its focus on continuous improvement. Other times it’s just the opposite – team members believe they have reached the pinnacle of Scrum usage and therefore have nothing further to learn from the sprint they just performed, from their teammates, or from their own success or failure. If people don’t see the value of doing a retrospective or of their attendance, consider dedicating some of or the entire next retrospective meeting to exploring this value issue.
Sometimes low attendance happens because it is inconvenient for remote participants to join by phone or video conferencing. If remote participants find attending the retrospective inconvenient because of when it is scheduled, consider changing or rotating the time so that no single location is always inconvenienced. If it is inconvenient because it is just hard to participate remotely, reconsider the current telecom infrastructure and how the exercises are being conducted to better incorporate remote participants.
Some retrospectives are very busy but really don’t achieve anything actionable. I call these the all fluff, no stuff retrospectives. If all we get is fluff, we’re wasting our time. Consider bringing in an outside, experienced retrospective facilitator to help the participants get to the real stuff.
Other retrospectives are fascinating to observe. There is clearly a critical issue that is having a dramatic effect on the team, but nobody will even bring it up. To reuse the old adage, the participants are ignoring the elephant in the room. There is probably a safety issue that is preventing people from discussing the elephant. The ScrumMaster should take a leadership role in helping the team and organization address the safety impediment first.
Other times the retrospective is just poorly facilitated. The facilitator, perhaps a new ScrumMaster, is trying her best but it’s clearly not working. Perhaps an outside facilitator should be used for a few retrospectives. Some retrospectives are downright depressing and energy draining. Perhaps the sprints are not going well and people view the retrospective as an activity that just compounds the misery by making them relive it. Consider spending a bit more time to set the appropriate atmosphere at the start of the retrospective. Also, an outside facilitator might be more effective at helping people stay focused on positive improvements.
Frequently retrospectives are depressing because people start playing the blame game and finger-pointing. The facilitator must extinguish this behavior as soon as it occurs to prevent a cascade of finger-pointing.
Other times a retrospective can degrade into a complaint session. Perhaps some people view it as therapeutic to just come and complain about the way things are (or at least how they perceive things to be). They have no desire to improve, just the desire to complain. Consider inviting people to the retrospective who can actually effect real change. Then have a face-to-face dialogue with them instead of complaining in their absence.
Another unfortunate situation is where participants consider the retrospective to be the time to do process improvement, thereby diminishing ad hoc process improvement during the sprints. A retrospective is a great time for the team to reflect on a period of work and discuss how to make things better, but it was never intended to be the replacement for ad hoc process improvement. The ScrumMaster should proactively promote healthy ad hoc process improvements throughout the sprint.
Sometimes our desires are bigger than our abilities. New teams that are energized and focused on really getting better can frequently become overly ambitious and set improvement goals that are totally unrealistic. Doing so will only lead to a big letdown when the team fails to meet its ambitious goals. The ScrumMaster should be vigilant and remind the participants of their available capacity to do improvements and help them moderate their ambitions.
Perhaps the biggest issue of them all is when there is no follow-through to actually work on the improvement actions identified during the retrospective. If we’re not going to follow through, there’s no need to waste our time on retrospectives. The ScrumMaster has a leadership role in helping the team constantly improve its process. If there is no follow-through, the ScrumMaster needs to be aggressive about working with the team to identify the root cause and helping team members address the impediment.
Source: Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin, Addison-Wesley
This list of retrospectives issues remind us that if the Scrum practices and activities seems deceptively simple, it is their effective implementation that can bring to software development teams all the benefits of an Agile project management approaches that are mainly based on the continuous adaptation of the team activity to its context.
Further resources on Scrum sprint retrospectives issues
24 Common Scrum Pitfalls Summarized
Common retrospectives ailments & cures
9 Agile Retrospectives AntiPatterns
Big thanks for including my blog post: “9 Agile Retrospectives AntiPatterns” if you allow me I am leaving a program here that you might find interesting: https://oikosofyseries.com/agile-retrospectives please do not think this is spam, but is super aligned with the topic. :)
Thanks
Luis
Earlier our book Getting Value out of Agile Retrospectives was covered on ScrumExpert. It’s a great resource when you’re looking for exercises to spice up your retrospectives.