“No need for a retrospective, we are so good at dealing with problems on the fly”

I get the above sentence in the face over and over again. And how true it is, isn’t it? Well, no! What? How could it not? Why not?
No, because retrospective is not the way to solve problems. Now get your chin off the ground and read on, I’ll explain why.

Photo by Kyle Glenn on Unsplash

Let’s look at the twelfth of the twelve principles that accompany the Agile Manifesto:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

Did you notice that the word problem does not appear once in the sentence? Retrospective is one of the most common ways to support the above principle, by discussing how we can do better. Of course, having problems with operations is by definition a barrier to working effectively, so solving them is a prerequisite for continuous improvement. A prerequisite, not an end.

It is very right, even obligatory, to deal with problems on the fly, or rather to wait until retrospectively to fix a pressing problem is a huge mistake. But why do we have to deal with continuous improvement in a separate ceremony, why not just do it on the fly? The key word is focus.

We need to keep an eye out for repair opportunities on the go, but unless there is a dedicated timeframe and location, they will get lost in the sea of urgency. Under time pressure, we try to get things done as quickly as possible. This entails thinking in terms of short-term solutions and producing as much value as we can in the minimal time available, precisely because of the urgency. At the same time, if we think about our options in a focused way, taking our time, we create the maximum value we can for our knowledge and creativity. Moreover, we are more likely to plan for the long term, so the time spent is dwarfed by the length of time we can enjoy the benefits we generate. It is not difficult to see that maximum value delivered over the long term has a huge advantage over short-term, hasty solutions that we implement as our first idea.

To sum up, we have to keep solving problems, but this activity does not trigger a retrospective. With minor, less troublesome problems, we can wait for this ceremony, but keep in mind that the state of having no problems should be the beginning, not the end, of the mechanism of continuous improvement.

Think about it: do you hold retrospectives with the above approach? Do you do it at all? If you don’t, are you aware that if you don’t have a retrospective, you have gone against the definition of agility, of rapid and continuous adaptation?

If you want to know more about effective retrospectives, have a look online or sign up for our Advanced Scrum Master or Agile Leadership training, where we cover the topic in more detail.

Written by: Gábor Erényi, Sprint Consulting