How we canceled retrospectives

Once, for our team, retrospectives stopped working.

On retro, we discussed eternal topics: we need to better decompose tasks, we need to better evaluate tasks, we must stop carrying debts between sprints, etc. Someone coded in parallel, someone answered messages, someone just stuck to the phone. Sounds familiar?

These were my first sprints as a scrum master, and I felt the team had no confidence in retrospectives. Yes, and there is no need either – there are complaints about the “scrum-day” clogged with meetings. And when to work?

I decided something terrible for the scrum master: I suggested that the team cancel the retrospectives – and this is what came of it.

I’m trying to do a boring retrospective

Hello! My name is Pavel, I do frontend and scrum in the Wrike team. We work on Scrum, now we have about 30 teams, in one of which I am a scrum master. I became them more than a year ago and I want to share my experience. This time about retrospectives.

Our retrospectives looked like a cargo cult

For complete immersion – a few words about cargo cults. You know, the islanders during the Second World War realized that all the planes (military) that flew to them on the island (military base), in fact, brought a lot of wonderful objects of civilization specifically for them, islanders. When the war ended and the planes stopped arriving, there was no limit to their disappointment.

An inquiring mind suggested: to return the planes, it is worth trying to make an airfield. For example, organize a runway in a field, lay fires along it, build a radio tower from a palm tree, and, of course, put a dispatcher in a hut. Everything was done – but the planes with the gifts never arrived.

So we have the same story with retrospectives. They inherited from the previous scrum master, and all external signs were still observed: at the end of each sprint, the team gathered, inspected themselves, discussed the improvement plan and followed it in the next sprint. Only in practice, we discussed the same thing in the same format, it is not clear why, it is not clear why. The guys were not involved, then everyone forgot about the plan in the sprint, and the Scrum master (I) still galloped positively around the board every retrospective. Worst of all, nothing has changed as a result.

What have we done

The golden rule of the scrum master is not to cause scrum to the team.

Okay: retrospectives are boring, useless, and you are all stuck in laptops. Let’s get it legal and cancel the next retrospective!

With this promise, I came to the team. It was important for me to understand whether the guys themselves needed retrospectives and why. If there is no problem, then there is no need to artificially “treat” it. And if there is no need, it is necessary to work on its healthy formation.

My hypothesis was that with such a radical change, the team itself will tell you why it needs a canceled retrospective. It was quite risky – letting go of the team then, I might not see it at all in the next retro. But the team did everything right.

What happened when we canceled retrospectives

I’m figuring out why the retrospective team

More than half of the guys supported me with pleasure and with the wording “of course, we’ll work better” uncovered their tasks for the free time. But three people rebelled and brought such arguments:

Every sprint should end in retrospect (but as we have already found out, this is a regular cargo cult).
The team needs some time to discuss specific issues from the past sprint (already better).
Retrospectives do not work due to the boring format and lack of purpose of the rally, and we need to work on it, and not cancel the retrospectives (valid).

The main thing I wanted to hear was that the team needed it. And the team suggested the topic of the nearest retrospective – “Why do we need retrospectives”. It turned out that they are needed to talk, bomb, discuss the past sprint, try to influence something, change something.

What conclusions have we made

It is necessary to verify the result. To restore team confidence in retrospectives, you need to show that they are beneficial. The team did not see the changes after retrospectives and therefore stopped investing in them. What is the use of offering something if it is clear from experience that we are not realizing it? If I want the team to start decomposing the tasks better, I will do it anyway, and the rest will not start anyway (and the scrum master will not control it). The guys thought so, because we hadn’t changed anything for a long time, didn’t improve it.

A big step was the fact that we began to start each Action Item as a separate task, take it in a sprint, track its implementation and verify the result on the next retro. A long work began to prove to the team: retro work, here are 10 closed action items that you proposed, that’s what we changed.

It is necessary to diversify the formats. The classic pluses and minuses that came from the past of the Scrum master have already become boring to everyone. After all, retro is not just about the past sprint, it’s about improvements. When a team is sure that everything is fine with it, you can build a balance wheel and see what it really is not (and understand what to work on). You can draw a boat and discuss your strengths and weaknesses in a playful way. For teams in the forming stage, the pros and cons should rather be replaced by synchronization of expectations.

There are tons of ideas suitable for different purposes. They allow you to make the event more driveable and involve the team instead of tormenting everyone with questions: “Well, what were the advantages in the sprint? What should we continue to do? ” After restarting the retro, we tried different formats, it became fun, productive, we avoided monotonous discussions in which only 1-2 people participate, and were able to involve even remote participants.

Eternal topics are best discussed separately. “How to close a sprint without debts”, “how to deal with big stories” – you can do bingo, they pop up for all teams. Instead of constantly procrastinating them under the guise of “minuses of the sprint”, we reserved separate retrospectives for them – the rest became cleaner, livelier and more productive.

Define the topic and purpose of the retrospective in advance. If the guys are bombing – they are not up to my balance wheels, we need to deal with current problems. It is better to find out in advance, especially if during the gathering of topics during the rally it begins: “Oh, I had something last week, but I already forgot” (there, in bingo).

We discussed that it’s better to write down such things during the sprint. Someone jokingly suggested making a complaints book.

No jokes, but the next day I got it and hung it on the board

The guys checked out, but, of course, no one wrote anything. But the book of complaints in electronic form has taken root – we will create a separate retro-task in advance and in the description we will fix all the points that we need to remember to discuss. It is important that the guys fill it, the idea has taken root and has been working for a whole year.

For example, it may look like this if you paint over everything that should remain on the retro itself

What benefit did the “updated” retrospectives bring us?

Over the year since that moment, we have closed dozens of action items, from the understandable “equip a room” and “go to a team building” to the difficult ones “transfer the scope to another team”, “clearly state the release plan”. We take them in the sprint and verify at the beginning of the next retrospective to confirm confidence.

Over the year, we have accumulated about 50 team agreements, which we came to through our own experience and mistakes:

about flow development: do a review code no later than in a day, from the very beginning of the sprint, integrate the front and back at least on the plugs to agree on a contract;
about processes: when decomposing, do not leave tasks with an assessment of more than 3 days, cut minor bug fixes into separate branches, when evaluating, lay a buffer for changes in the scope of another command;
about product development: where and how functional requirements should be spelled out in the task hierarchy.

These agreements came in retrospect and are related to triggers – as we agreed to do in certain situations, if they happen again. Now most of these proposals are carried out on a regular basis, which also confirms the growth of the team.

And how are you?

Each team has its own history of retrospectives and its relationship with the scrum master. For example, my friends do not understand why the scrum master is needed in their team – he only makes unnecessary rallies and drinks coffee all day. Does this really help the team grow? Is this exactly what the scrum master himself sees?

Everyone has their own positive or negative experiences. Share yours in the comments – and good luck in developing your team!