5 reasons for your Scrum team to wait for the Sprint Retrospective

Your team complains about too many meetings and a useless Sprint Retrospective at the same time? Time to take a stand for the Retro!

If you had boring, listless Sprint Retrospective meetings while at the same time multiple relevant topics are already being taken care of in special meetings and groups, the problem might be the way the Retro is conducted. But sometimes it is just that there are no good topics left for the Retro. Here are some arguments to help you convince your teammates to bring their topics into the Retro instead of convening the next ad-hoc meeting.

#1 Less meetings

You can easily explain this by showing the team an exemplary schedule such as this, where at least four topics look like they should be at least decided upon in the Retro:

A team that talks too much. The four marked meetings are candidates to be folded into the Retro.

The decision whether move a topic into the Retro or not could be taken in the Daily Scrum.

This of course only works if the team prefers working on the Sprint to having lots of meetings. If that is not the case, you already have a relevant Retro topic…

Another anti-pattern that fits into this line of argument is a boundless Daily Scrum. If it slips into long inspect&adapt discussions regularly, the Retro will suffer.

#2 Improvement overload

Jeff Sutherland and Ken Schwaber in the Scrum Guide call the Retro “a formal opportunity to focus on inspection and adaptation”. Most experienced Scrum Masters I know use this opportunity also to have the team pick the most relevant adaptions, and then get those right. They do this because it increases the likelihood of the team successfully implementing these adaptions. This in turn strengthens the inspect&adapt loop. In the end, every adaption is an experiment, and you need some time to inspect their results.

#3 Whole team participation

And if finally it turns out that a solution is best worked out by just a few team members, at least this is a conscious decision — the team then delegates working out a proposal to these team members. And when they come back, the whole team decides. A self-organizing Scrum team is a grass-roots democracy in such matters, and thus the whole electorate should be present when decisions on big adaptions are made.

#4 Take out the drama

Just proceeding with an ad-hoc meeting yields a high chance of over-reacting to a one-time issue.

A good way of tackling such a problem is to first discuss it with another team member (pair programming comes in handy here), and then maybe write down an “impediment card” or something similar for the Retro. Or, if you both see this as absolutely necessary, ring the alarm bell and get all hands on deck for the dramatic ad-hoc meeting. Which could also be a made a bit less dramatic by using something like the instant retrospective format.

#5 Moderation

A word of caution

Besides inspecting known problems in the Retro, it can and should also be used to uncover new topics, that have been festering under the surface. If you collect a lot of known problems encountered during the Sprint, make sure there is still time for this aspect in the Retro!

More reasons?

software developer & agile coach based in Cologne, Germany

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store