One of the most frequent criticisms I hear of Scrum when teaching Certified Scrum Master courses is “Scrum teams have too many meetings.”
With daily scrums, sprint planning meetings, sprint reviews, retrospectives and possibly even product backlog refinement meetings, it’s easy to understand the basis for this concern.
But let’s see if it’s true.
Here’s an experiment I’d like you to try, especially if you think Scrum has too many meetings.
Pick a random number from 5-10. Then think back to when your team first began working in an agile way or perhaps when they first started to get good at it.
Go to that month on your work calendar, whether in Outlook, Google, Apple Calendar or some other program. Now, remember the random number you picked in the previous paragraph? Back up the number of months that corresponds to your random number.
So, for example, suppose your team started to get the hang of agile in October and you picked 5. In that case you’d back up five months from October and look at May.
Next, look through that month, making note of all meetings you had during the month. If you’re like those I’ve had do this before, you will likely find that you had as many or more meetings before becoming agile–they were just different meetings.
You probably had occasional meetings with stakeholders. You had the weekly update with your boss. You might have been on a couple of task forces. Then there were design reviews—whether design, technical, database, or other. You might have had a weekly status meeting. Perhaps there were code inspections or reviews. There were one-off design discussions at the whiteboard. Add a couple of conference calls. And realize you probably had some meetings that were scheduled but never made it onto your calendar so you don’t see them now.
It is entirely possible you had more meetings pre-agile than after.
This definitely won’t be true for everyone. But, for about half the people I’ve done this with in-person, they had more meetings before starting Scrum. Those most likely to have had more meetings pre-agile are team members who need to coordinate their work with others.
Why We Feel Like Scrum Has too Many Meetings
So, why is the feeling that Scrum has too many meetings so prevalent?
It’s because the meetings have names. When we give something a name, it can become a target for criticism. People will complain about “those darn sprint planning meetings” and that “pesky daily scrum.” (They may use more colorful language.)
Many of the meetings on your calendar pre-Scrum did not have names and did not recur regularly. They were more like “Discuss design with Mary,” “Code review with Ashish,” or “Janet – test cases.”
You may have had many design discussion meetings, but they weren’t all with Mary and definitely didn’t have the official name of “Discuss design with Mary.”
When a meeting recurs regularly and is named, it becomes far easier to criticize.
Scrum Done Well Feels Helpful Rather than Burdensome
Scrum’s meetings definitely have the potential to become burdensome. And many teams do spend too long in meetings. For every team I advise to spend more time in a given meeting, I must tell 20 or 30 teams to spent less time. (Overdoing sprint planning and product backlog refinement are particularly common.)
But when done well, Scrum should be a help rather than a hindrance in developing products quickly. Each meeting should feel like it was held
- at the right time
- for the right length
- with the right people
- and at the right level of detail
The Scrum framework is setup to make this possible. If a team doesn’t feel this way about its meetings, the Scrum Master should look carefully at how each is being conducted.
In all likelihood, the meetings should continue but be made more efficient rather than abandoned.
There will always be some team members who criticize any meeting. One meeting a decade is one too many for certain people. But, when meetings are conducted well, many Scrum team members will find they spend less time in meetings than before adopting Scrum.This post was originally published on this site