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 are things you can do to improve the maturity level of your team - in this context and in general? Here are 7 thoughts, 7 tips that will 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 is the following: “The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.”

In theory, this means that the retrospective should be a core event of the Scrum Master, as the core purpose of the retrospective is to help the team continuously improve. In practice, the team might not have the maturity level to make use of a retrospective or it does not see its value. This is why, on an abstract level, I personally interpret the statement “make the team more efficient” as “increase the maturity level of the team”. How do you do that in this context? Well, we will get to our tips in a minute - one more thing before we start 🙂

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 the agile maturity level – then you should use the quality of retrospectives as an indicator. I believe that the following image is the typical connection between the “perceived quality of the retrospective” and the “agile maturity level” of a team over time.

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”, which might help you with other drivers of agile maturity.

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.

Oftentimes, it is one “opinion leader” in the team who has a big influence on the team. Especially work with this person, understand his or her view and even develop countermeasures (see below) in collaboration with him or her.

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 have the retrospective under all circumstances. Let’s say the team simply needs more time to deliver on their sprint goal - and that one hour of coding instead of a retrospective might be crucial. In that case, it is okay to postpone the retro for 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

You cannot change what you are not measuring. A simple and quick routine that helps you to continuously evaluate how the team perceives your retrospectives is to measure the ROTI score: The “Return on time invest” score. Ask this question after every retro, maybe as the check-out: “On a scale from 0 to 10, how well invested was the time for this retro?”. Measure the average over time - hopefully you can identify a positive trend time!

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 isn’t necessary - what should a Scrum Master do?

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, over the last retrospectives, apparently they learned that the ROTI of a retrospective - ROTI equals “Return on time invested” - is rather bad. Accordingly, a quite straightforward approach to change this - is to simply invest less time with the same output.

This might be the best tip when the team considers the sprint retrospective isn’t necessary. Say to your team: Okay, we will keep it as short as possible (more on this in our blog post “Short retrospective - better quick 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 are shortening the retrospective (from for example 60 minutes to 30 minutes) because this way, the team learns how important it can be to spend this time. And to let the length of the retrospective grow organically, by a “pull” from the team Because some day, it will want more time for the retro. How do you do that? 

You simply ask the most important question:

“Why did we not manage to complete all user stories set 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.

 

Now, as an example, what if you leave out a few Dailies? You know what would happen if you do that? On the one hand, maybe it will have no effect - perfect, keep it like this 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

One approach that could be complemented with the other approaches is to review the “retrospective history” of the team over a longer period. The precondition for doing this is that some of your recent 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 realize how much you improved during the meantime. Apparently, this “continuously improving” approach might work?! And the retrospectives might have played a big role in this, indeed.

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.