How We Canceled the Sprint Retrospective
Hey, guys! I’m Pavel, Scrum Master and Development Lead at Wrike. This story is part of my “Experiments in the Team” series where I share my experiences of coaching the team and improving our culture.
The problem
You may be familiar with the cargo cult concept. It originated from the situation with Melanesia islanders, who obtained useful supplies from airplanes stationed on their island during WWII. When the soldiers eventually left after the war, the islanders tried to reproduce all the steps that the soldiers used to do in hopes that the supplies would keep coming. They made a landing strip, lighted fires, and even appointed someone to be a traffic controller, but although they replicated all the details, neither airplanes nor supplies came anymore.
It felt like we had something similar to a cargo cult in our team last year when we realized that our retrospectives just didn’t work. The Scrum Master (me) kept jumping around the whiteboard to try to keep the meeting alive. But my team members weren’t involved, we discussed the same topics several times in the same format, and nothing changed for us afterward.
So, our retrospectives were useless.
Sound familiar?
The hypothesis
I had to change something, so I hypothesized that if I tried to cancel the meeting, the team could tell me why they actually needed retrospectives.
I proposed the following to the team: If our retrospectives were useless, we could skip the next one and spend more time focusing on work.
Warning! Please keep in mind that it’s actually not always safe to propose canceling a retrospective to any team. They might support your proposal, and you’ll never see them again at any retrospective as soon as you say that it’s useless.
The result
More than half were definitely OK with it and supported me, but three people began a rebellion.
They gave me three reasons:
- Every sprint must be ended with a retrospective (as we all know, it’s not a real cause, but just a cargo cult).
- The team needed dedicated time to discuss certain problems from the current sprint (sounds better).
- Retrospectives didn’t work because of the format and wrong meeting goals, and we had to change it (valid thought).
What was changed
The next retrospective topic was “Why Do We Need a Sprint Retrospective?” to brainstorm a bunch of ideas. We realized the problem: We needed retrospectives to improve our processes, but we changed nothing afterward.
So our action items were:
- Collect feedback and complaints in advance during the sprint.
- Try different formats, not just the classic plus-minus-delta.
- Reserve some whole retrospectives for endless discussions like “sprint without debts,” “how to deal with huge stories” “what implicit problems do we have,” etc.
Since that meeting, we relaunched our retrospectives. We successfully tried a set of different formats, made sure everybody was involved (even our remote participants), and had a lot of fun during those meetings.
One of the major process changes was a Book of Complaints. We created a separate document, which is actually a task on the current sprint folder in Wrike, at the beginning of each sprint. Everybody was able to fill it out right after something happened and ensured that we wouldn’t forget to discuss those items during a future sprint retrospective.
And, of course, the most valuable result was that we completed a large number of action items during the last year, along with about 50 internal agreements (or team best practices) of how to manage certain cases related to development flow, product development, Scrum ceremonies, work processes, and more.
Make your retrospective interesting and effective! Good luck to you with your experiments!
Follow me for other cases and challenges I solved with my team. Check out the full video in Russian (~70 minutes) about experiments available at the Wrike Tech Club channel.
Leave your feedback, and share your experiences in the comments!
