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
The easiest argument is that by waiting for the Retro, overall the team will spend less time in 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:
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
Looking at the exemplary schedule above, you can easily spot another problem: What if out of the four meetings and the Retro there are at least five different improvements to be implemented by the team during the next Sprint? Does that sound realistic? Absolutely not so. The average Scrum team I have encountered, in a good Sprint, manages one visible improvement to their way of work, and maybe a few minor ones. And that is already quite good, if you extrapolate this to a full year.
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
The typical ad-hoc problem meeting is usually not very inclusive, and typically only consists of those people affected by the problem. However, if the problem should really be used to improve the way the team works, the whole team has got to decide. And maybe the discussion has to be broadened away from the narrow perspective on just the one problem.
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
Setting up a meeting whenever a problem occurs feels very Lean and Agile, like pulling the Andon cord to stop the production on a Toyota assembly belt. And sometimes it is really necessary. But very often the situation in a software development team is different to the situation at the car factory. If the problem at hand will not make the whole Sprint pointless, it is maybe not warranted to interrupt the whole team’s precious flow. It is better to wait until the dust has settled, and the problem’s relevance and impact can be assessed in a calm manner in the Retro.
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.
If the issue is a controversial one, such as a technical decision that people are very opinionated about, it is good to use a well-known meeting format, and decision mechanisms known to all participants. It is even better if you have a good moderator, such as maybe your Scrum Master. All this you already should have: your already scheduled Sprint Retrospective!
A word of caution
A permanent “stream” of small adaptions is a sign for a healthy Scrum team. These are for example a refactoring on the fly, a small improvement to the build pipeline quickly agreed upon in the Daily, or a new test case introduced into the regression test suite. This is a very good thing, and it should not be postponed until the Retro. The Retro is for those adaptions that need to be discussed and decided upon, and where all team members should be heard.
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!
There should be even more reasons to reserve the most interesting discussions for the Sprint Retrospective. If you have one, please leave it as a comment! There might be someone out there needing just that argument.