Why are Scrum Retrospectives a waste of time?

Asad Safari
3 min readJul 24, 2022

As an agile practitioner and after almost 15 years in software development, I want to say Scrum Retrospectives are a waste of time in most cases, but why? what is the fact?

https://www.youtube.com/watch?v=dBR_0FUMzGs&t=1s

Scrum teams fall into the random problem discovering and fixing trap; although the team solves problems, it seems that the team stagnates.

The idea of Scrum Retrospectives is a tremendous, continuous improvement, but it can turn into a random problem fixing without any direction.

Let's see what is going on with a scrum team: After 2 or 3 weeks, The Scrum Team gets together to inspect how the last Sprint went. They discuss what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

You are a great facilitator; at the end of the day, you will have a prioritized list of problems/improvements and a bunch of actions to solve/fix/improve problems.

But the main question is, "Are we Solving the Right Problem now?" "What is the next Right thing?" Scrum teams fall into the random problem-solving trap; Although the team solves problems, it seems that the team stagnates and never experiences agility. Note that the problem is not the prioritization technique; in any case, without Direction, you will fall into this trap. Ask this question before the next retrospective session "Ok, we have a list of problems/improvements; which one should we focus on?

Let's do a dot voting and will find the answer, hmmm?!?!? But this is random problem-fixing. Sometimes the last problem can be the highest priority problem, but why?

https://axispraxis.wordpress.com/2016/03/24/the-streetlight-effect-a-metaphor-for-knowledge-and-ignorance/

Remember, As a scrum master/Agile coach, you are not there only to facilitate an event but to create a focus and ask the right questions to create a new insight.

Toyota Kata has a good approach that can be mixed with a scrum retrospective. So, before deciding on problems, we need to know the Direction. So, let's see a retro based on Direction:

So, our goal is not to fix or discover as many as possible problems, we are trying to reach our next target condition and will only focus on discovering and fixing the obstacles that are on our way to the next target condition.

Let's see a real-world Case study; I was an agile coach for a fast-growing startup. Our Challenge for the next two years was "Zero bug level", and our next target condition for the next quarter was "Decrease the weekly reported bugs on production under 5". So, as an agile coach, I no longer asked them what our problem was? Instead, I asked them what prevents us from reaching our next goal.

If you are interested, I will go into more detail about this method in the next post.

One important thing, I do not want to say that Scrum Retrospectives are always a waste of time, the idea of continuous improvement is great, but we need to consider the possibility of a random problem-fixing trap.

Regards

Asad Safari

--

--