Sprint retrospective isn’t necessary? Yes, it is: 7 tips

Many say that the retrospective is the most important ceremony in Agile. Woody Zuill puts it this way: 

If you adopt only one #agile practice, let it be retrospectives. Everything else will follow.

Woody Zuill

So why is it even possible that a development team considers the sprint retrospective isn’t necessary? How does so much “retrospective fatigue” even arise? Well, in my experience as a Scrum Master and psychologist, most of the time this has to do with the maturity level of the team.

So what can you do to improve your team’s maturity - in this context and in general? Here are 7 thoughts, 7 tips to help you with this challenge.

The development team considers the sprint retrospective isn’t necessary - what should a Scrum Master do?

The official answer, according to the Scrum certification test: The Scrum Master would work on the team to make it more efficient. But what do they mean by that?

The Scrum Master should work on the team to make it more efficient

The official role of a Scrum Master, looking at the Scrum Guide looks at: “The Scrum Master encourages the Scrum Team to improve its development process and practices within the Scrum process to make it more effective and enjoyable for the next Sprint.”

In theory, this means that the retrospective should be a central event for the Scrum Master, as the main purpose of the retrospective is to help the team continuously improve. In practice, however, the team may not have the maturity to really use a retrospective and therefore does not see its value. For this reason, I personally interpret the statement “make the team more efficient” on an abstract level as “increasing the team’s maturity.” How can you do that in this context? Before we start with the tips, here’s another explanation 🙂

The retro is then considered valuable if it really helps to continuously improve. It is as simple as that. This way, the feeling of autonomy, self-organization, self-efficacy is high. Which leads to the hypothesis: The perceived quality of retrospectives is one of the best indicators of a team’s (agile) maturity level. 

If you want to measure agile maturity - then you should use the quality of retrospectives as an indicator. This is the typical correlation over time between “perceived quality of the retrospective” and “Agile Maturity” of a team.

This process comes about as follows: 

1. The first retros are carried out, action items are written down. The feeling arises: finally, we are doing something about our challenges! 
2. The action items are not being implemented. There is a lot of talk, but little happens. 
3. After some time, frustration or what is called “retro-fatigue” arises. It is the phenomenon of this post: the development team considers the sprint retrospective isn’t necessary. But the team sees itself as pretty mature - and sees no internal challenges.
4. This point or agile maturity level is only reached by a few teams. Namely, when the quality of the retrospective increases and ultimately leads to noticeable improvements - the feeling of self-efficacy slowly matures. 

Hopefully, the tips in this text will help you take a few steps in this direction of agile maturity. However, I can also highly recommend our text on “ 7 tips for great action items %E2%80%9D, who play another role in this topic.

1. Understand why the team considers a retrospective to be unnecessary

As a Scrum Master, you might have an hypothesis why the team considers the sprint retrospective is not necessary. But please test that hypothesis. Make sure to ask the team explicitly why they think the sprint retrospective isn’t necessary.

Often there is a “opinion leader” in the team who has a great influence on the team. Try to pick out this person, understand their point of view and, at best, work with them to design the countermeasures (see below).

The better you understand the team, the better you can come up with a plan to increase the maturity level of the team and select from the best suitable tips below.

2. Have the retrospective

You should always do the retrospective. Let’s assume the team just needs more time to achieve its sprint goal - and an hour of coding instead of the retro could be crucial. In this case, it’s okay to postpone the retrospective by a few days.

You might also change the nature of the retrospective, keep it shorter etc.. But the only way to show the value of a retrospective to the team - is to simply have a really good retrospective. Thus, please reserve a time slot for the retrospective.

3. Measure the ROTI score

What you can’t measure, you can’t change. A simple and quick habit that helps you continuously assess how the team perceives the retros is measuring the ROTI score: The “Return on time invest” value. Simply ask the following question after each retrospective, perhaps as a check-out: “On a scale of 0 to 10, how well was the time invested for this retrospective?”. Measure the average over time - hopefully you’ll see a positive trend soon!

The average “Return-on-time-invest” score on a scale of 0 to 10 per month in the Echometer Tool - are the retros worth it? It seems so!

4. Keep your sprint retrospective bloody short

So the development team considers the sprint retrospective to be superfluous - what should you do as a Scrum Master now?

As I said in the beginning, probably the team considers that a sprint retrospective isn’t necessary because they believe that would be a waste of time.

In other words, in the last retrospectives they have apparently “learned” that the ROTI of a retrospective - i.e. the quality of the time invested, see above - is rather poor. There is a fairly simple approach to change this: simply invest less time for the same output 🙂

This may be the best tip if the team thinks the sprint retrospective is superfluous. Tell your team: Okay, we’ll keep it as short as possible (more on this in our blog post “ Short retrospective - better fast than not at all ”). 

Important: You do not want to signal that it will be like this forever. You are still planning to show the team that retrospectives are really important. Sooner or later, your retrospectives won’t be short anymore.

But you shorten the retrospective (e.g. from 60 minutes to 30 minutes) because this is how the team learns how important it can be to invest the time. And you let the length of the retrospective grow “organically”, through a “pull” or “wish” from the team, because at some point it will want more time for the retrospective. How do you do that? 

You simply ask the most important question:

“Why weren’t we able to complete all the user stories defined for the last iteration?”

This will lead to some intense discussions and probably also ideas for action items in a short amount of time. It might even lead to longer discussions. And there you go - the team indicates that it needs more time for a retrospective (of course it is your role to keep the discussion constructive).

To put it in a nutshell, another option is to keep the retrospective really short, asking one question only. Ask the question that you believe triggers good thoughts. And you should have the goal to put down one experiment, one thing you try out in the next sprint (aka action item).

5. Suggest to also leave out other routines

So the team thinks that a retrospective is a waste of time. Fine. As a Scrum Master, you should never view your core goal as the person that implements Scrum. No, it is not about Scrum. 

It is about making the team successful in delivering value to your customer and your stakeholders. Scrum is supposed to help you do so. But it is just one framework (a pretty good one) from many possible approaches to deliver value.

So if the team rebels, you might underline that you generally view Scrum from the perspective I just outlined. And then you add that you believe that actually, some of the other routines you have are less important than the retrospective. 

The retrospective is the motor for continuous improvement. It is there to help team members raise what worked well and what didn’t. If you cut this part of the continuous loop out, you risk putting the continuous improvement loop to a halt.

For example, what if you left out a few dailies? Do you know what would happen? Maybe it won’t have any impact - perfect, then you can keep it that way and save time. 

On the other hand, this might lead to miss-communication. The team will encounter some new challenges. In the end, there will be an organic need for more dailies. But this time, it is not based on you pushing it - but based on the pain of the team. Thus, there will be a lot more acceptance for this ceremony. You can obviously use this approach for all your agile ceremonies.

6. Look at past retrospectives and show their value

An approach that can complement the other approaches is to look at the team’s “retrospective history” over a longer period of time. The prerequisite for this is that some of the last retrospectives were successful.

You might look into the retrospective one year ago realizing how much struggle these challenges have been last year. And then you understand that today, it would be so much easier to solve these same challenges, given all the knowledge and experience you acquired.

In other words, you recognize how much you have improved in the meantime. Maybe this “continuous improvement” approach could actually work?! And the retrospectives could actually have played a major role in this. Used correctly, this can definitely lead to an aha moment in the team.

Additionally, you might have a look at the ROTI score (Return on time investment) of your recent retrospectives (see above): If you can prove that the retrospective has a ROTI of 8 to 10, obviously the time is well spent. Our Echometer retrospective tool for example asks for the ROTI after every retrospective and thus gives you a continuous indication of your Scrum Master performance regarding this .

7. Bring more variety to your retrospective

One of the typical answers to the question “The development team considers the sprint retrospective to be superfluous - what should the Scrum Master do?” is to make the retrospective more productive and exciting by bringing more variety to your methods and making them more fun. I always emphasize that “fun” is not that important, the focus should still be on making them productive. Nevertheless, fun can of course trigger a certain creativity and motivation. 

On the one hand, this means that you can use creative retrospective methods - see e.g. our article about 32 kickass retrospective ideas for beginners and professionals. - , i.e., open question metaphors that trigger new thoughts and ideas.

On the other hand, you might also use methods that go beyond the typical retro but still have the goal to improve the team. For example, you might do a retrospective / team workshop that is focused on psychological safety improved in the team - one of the core prerequisites for successful teams. 

Or you can use our Retro Tool Echometer, which continuously supplements your retrospective with scientifically based questions. They help the team to reflect on the extent to which it fulfills the core characteristics of successful teams. Here is an example of one of the questions from our tool, another prerequisite for successful teams - a healthy feedback culture:

I regularly receive useful feedback on how good my performance is and how I can improve.

Example of a science-based question that you discuss through the Echometer retrospective tool.

There are many other approaches to bring variety to your retros - feel free to be creative. 

As I said, depending on “why” the team thinks the sprint retrospective is superfluous, more variety should probably not be the only measure to solve the problem.

Conclusion on “superfluous retros”

As you have seen, the 7 tips and measurements tackle the given problem on different levels. If I would have to recommend one thing, it would be to shorten the retrospective in a smart way, as I outlined above. If you combine all of them, I am sure you will see results very soon. 

Have fun improving your team!