Do Scrum Teams Meet Too Much?
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.
An Experiment
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.
I'd love to hear your thoughts where this post was originally published, on the Mountain Goat Software blog. There, you can also download a free copy of my guide, Situational Scrum Mastering: Leading an Agile Team.
If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them.
Software Craftsman / Engineering Leader
6 年Individuals and interactions over processes and tools.
Director, Product Concierge at Aha! — The world's #1 product development software
6 年Ultimately its all about the organisation, and how it is being managed. But the key here is to remember to listen to the team. I have seen teams beg to not "have to stand around and meet for the sake of meeting" - the team is clear on what work needs to be done and simply do not need to meet to talk about it *again*. What frustrates a team is when they are being forced to meet *for the sake of meeting*, because that is process, and that is what the "boss" is telling them to do. That is a total failure of agile - and highlights a lack of understanding of how the development process works. Communication is key - so listen to your teams when they communicate to you as a delivery or programme lead / scrum master - and balance the need to communicate and have visibility with the inherent needs of a development team to build product and get busy without interruption.
Director of Software Engineering at DeepSig Inc.
6 年For any software development process to work you have to use common sense. Think out of the box. Do not use Agile where it does not fit. Time is relative. Adjust your time scale to fit the project needs. Finally, never use a shovel to dump your code into the machine. Do it incrementally (!) but do it all. Pipeline the design, implementation, testing, refactoring, ... in a loop. Sometimes it pays to think before you open your mouth or you type a next line of your code (which features plenty of comments). Call it "Agile" but do not use it as a "hammer" indiscriminantly. It was not supposed to become a Dogma. It was supposed to be an Adventure!
Author, Coach and organizational Consultant for mindful and co-created change for the better!
6 年I feel that there are actually some more reasons behind the pure number of standard Scrum meetings why they feel so: e.g. adding wrong, additional meetings to Scrum or doing the meetings wrong (not disciplined or poorly facilitated)
Programmer / Senior Web & Mobile Developer
6 年https://www.dhirubhai.net/feed/update/urn:li:activity:6347085215789248512