Inneficient Sprint Retrospective Reports

Question

Does anyone know references in literature that explore the issue of inefficient Sprint Retrospectives? I think that almost everyone had already experienced it, but I can´t find reports of experiences in literature regarding that.

Answer 1

I'm not aware of any reports or research on this. But doing many retrospectives over the years I've recognized smells or antipatterns that cause retrospectives to become ineffective.

A retrospective smell is a signal that something might be going wrong in your retrospective. It’s a warning that problems might happen that will impact the retrospective result. An anti-pattern describes the behavior that most likely follows if the smell is not properly recognized or dealt with.

For example Recurring Actions is a smell when the same actions keep coming back. When you are the one who usually facilitates the retrospective (as the team’s Scrum master or as an external facilitator) then you will probably see the pattern of repeating actions in consecutive retrospectives.Often the deeper problem behind recurring actions is that somehow actions don’t get done or aren’t effective.

Some of the things that you can do to deal with this are:

Do a Root Cause Analysis to find out why the team can’t get actions done or why actions aren’t effective.

If actions often aren’t picked up after the retrospective meeting, then ask the team before ending the meeting who will be doing the actions.

Ask people to pair up and two persons take care of an action.

Monitor actions after the retrospective, for instance during a daily stand-up or any other occasion when the team meets.

Limit the number of actions that come out of the retrospective. Focus on the vital few actions.

I wrote a series of articles on retrospectives smell and dealing with them: https://www.benlinders.com/2018/retrospective-smells/

Does this help you?

Answer 2

I've worked with quite a few teams and know that your experience is not uncommon. The retrospective is challenging for a number of reasons. I can list a set of common challenges I see here, but this is by no means exhaustive. If some of these don't lead you to an improvement, I'd consider consulting a local agile coach.

Challenge #1 - Fixed vs Growth Mindset

These terms are actually from education, but the retrospective only works if it is approached with a growth mindset and this is one of the most common reasons that retrospectives don't change anything. The very short definition of these terms is that people in a fixed mindset think of their ability to do something as a characteristic of themselves. If they miss a requirement, it is because they aren't observant or they are tired. This results in two things: 1) any question of if things went well is a judgement on them as a person 2) because we all think we are good people, we start justifying anything that didn't go well. A growth mindset, on the other hand, looks at skill as a combination of the person and their circumstances. A person exhibiting a growth mindset who misses a requirement may acknowledge that it was at the end of the sprint and they felt rushed, so they didn't ask someone to check their work. They still feel accountable, but they also know that by changing the situation and context, they can change their own actions. It's important to know that people are not one or the other of these. We all exhibit both of these at different times. Opening up a retrospective that encourages a growth mindset can set a good tone for the meeting. Alternately, forced changes in word choice like changing "I can't" to "I can't yet" and "you made the wrong choice" to "it was the wrong choice that time" can reenforce this approach.

Challenge #2 - Change Us, not Others

You can't change others. At best, you can convince them to change themselves. Too often, actions from retrospectives demand that someone outside of the team changes their behavior. It's fine to surface these concerns and start a discussion with others, but you can't commit to that change. Most, if not all, action items from a retro should be something that is within the team's power to control. Of course, there are usually two sides to an interaction, so the team may have the power to control their side. For example, turning an action item of "People need to give us all the right information" into "When requests come in that are missing information, we will set up a meeting or call to clarify it before we take the work on."

Challenge #3 - Psychological Safety

Most of us aren't used to digging into our flaws every few weeks and actively changing them. If you've been doing this for a while, you can easily forget how hard it was at first. Early retros will be very superficial and will miss the elephants in the room. A good facilitator knows that you good push them to dig deeper, but you can do more damage than good. The team should feel just a little bit uncomfortable - that means they're improving - but pushing too far leads to people locking down. A common mistake coaches and scrum masters make is they aren't patient with their teams.

Specifically in regards to action items, I sometimes see teams take some really deep action item because the Scrum Master pushed them to recognize it, but the psychological safety isn't there to take action on it, so it just sits. Following through on a simple action item like "rotate who fills the candy bowl" is better than no action on a powerful change.

#3b - Some teams are OK with the details of their retro being shared. Most teams aren't - and for most of them, they don't feel comfortable saying so. A good policy is to share only the action item and everything else is private to the team. This frees them up to say things and raise concerns they might not otherwise want to.

Challenge #4 - Make the Time

Improvement takes time and there are still only a limited number of hours in a day. If the team doesn't set aside time for the action items, they won't get done. Especially early on, it's good to make this explicit. Maybe we cut our capacity by 10% for a particular improvement. Others may be 5% and others may be 20%. Have the conversation and follow through. This also speaks to psychological safety. If the organization's leaders explicitly say "We want you to take 10-20% of your time each sprint to improve how you operate. You pick your own number, it just can't be 0%" that's a bit step in creating that safety.

Challenge #5 - Boooooooooring

Anything you repeat over and over again becomes tedious and boring. My first scrum team used "What went well, what went poorly, what do we want to change." for 2 years! It was horrible. Of course, we didn't know better, which is why most teams do this. Change up the retro sometimes. Keeping the same format for a few sprints can't help build consistency, but after 3 or 4, try something different. My recommendation is always to look at retromat.org. They have over 100 different activities. Find one you like. I also recently discovered Recess Kit that sends you a retro in a box every month. Retros will often be uncomfortable, but they should never be boring.

Challenge #6 (last one for my list) - It's the team's retro, not the Scrum Master's

The retrospective is most valuable when the team reflects and improves. The Scrum Master should be a facilitator here, not the person who will list off what the team does wrong. If there are things you've seen in the sprint, share your observations, not your judgements or opinions. This will sometimes mean that the path is so obvious to you is one they choose not to follow. That's part of learning. It is deeply frustrating, but it won't stick if you force them. Again, share your observations and help them see what you are seeing, but you can't make them chose to take that on.

Again, this is far from comprehensive, but these are the biggest things I've seen.

Answer 3

Although I'm not aware of any formal research, I can recommend a few books on retrospectives and coaching that are likely to be useful - Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, Agile Coaching by Rachel Davies and Liz Sedley, and Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins.

I can also add a specific suggestion. Based on your comment, it seems like the team is able to identify impediments that came up and develop suggestions for improving the team's way of working. The problem, however, is mostly in executing those resolutions and improvements. My suggestion, which is also specifically called out in the Scrum Guide, is to place "at least one high priority process improvement identified in the previous Retrospective meeting" into the next Sprint's Sprint Backlog. Doing so will make the improvement visible - you should be centering your Daily Scrum around the Sprint Goal and Sprint Backlog, so this process improvement should be visible to the team every single day of the Sprint. You can also reflect on this at the Sprint Review and Sprint Retrospective to see if the change was fully made and assess its effectiveness.