Dealing with the "too many meetings" problem
Dealing with the "too many meetings" problem
Do you or your team feel meeting fatigued when using Scrum?
Nearly every team that I have introduced Scrum to has complained at some point about the duration of meetings in Scrum. I get comments like
“Scrum has far too many meetings”
“What? A four-hour planning meeting for a two-week sprint!”
“We have so many meetings here, and now you are killing us with more meetings”.
“I cannot have my team spend so many hours in meetings”.
“I am too busy”.
“&(#* off, this is &$%# @#!&”
Let us inspect
Let’s step back, get the facts, and inspect what is happening; you know that Scrum empirical thing😉?
The Scrum Guide recommends these times for monthly sprints but proportionately shorter for shorter sprints.
Sprint Planning: 8 hours
Daily Scrum: 15 minutes every day
Sprint Review: 4 hours
Sprint Retrospective: 3 hours
Although the above times are for monthly sprints, they are proportionately shorter for shorter sprints, for example, a two-week sprint :
Sprint Planning: 4 hours
Daily Scrum: 15 minutes every day
Sprint Review: 2 hours
Sprint Retrospective: 1.5 hours
You can crunch the hours per sprint versus hours in meetings. When you crunch the numbers, you will see
5% Sprint Planning - Planning, Solutioning and Design – If I look at traditional ways of working, the amount of time spent in planning, excluding analysis and design, is significantly higher than Scrum’s five per cent. There is a massive gain in using Scrum in cutting context switching and unnecessary documentation.
3% Daily Scrum – Replanning and coordinating the plan for the day. Most teams I coach finish this quickly within 5-8 minutes.
2.5% Sprint Review – This event is beyond just a “demo”, and when done properly, it consolidates many different meetings such as priorities meetings, risk meetings, product strategy meetings, release planning meetings, status reporting meetings and more. Doing it this way, you get it over and done with in one long meeting, but freeing dairies for the rest of the sprint. This is ideal for time-poor management and teams.
2% Retrospection – Spending time to improve inefficiencies is priceless.
2% - 10% Refinement [– but this depends on the team's maturity. Most teams I coach are normally around 2% for the sprint, but novice teams that have not let go of waterfall analysis and design may take up to 10%. Please note that refinement is not an event but an activity.
If you total all the Scrum events, you will see that team members spend only 12.5% of their time in meetings. Let's put that in a different perspective; in an 8-hour workday, you will spend an average of 1 hour in meetings per day. That means 87.5% of your time can be spent at your desk doing the work and building products.
1 hour of meetings for every 7 hours of work
Here is the kicker
Most people who complain about too many meetings are likely spending 80% plus time in meetings with very little time left to do the work. It’s highly inefficient and needs to be addressed.
But here is the hardest pill to swallow. When I hear “there are too many meetings”, I am 99% certain they are applying scrum mechanically. If scrum was really applied correctly, this is what should have happened.
Reveal the fact that there are too many meetings, thus making it transparent.
Those involved would have had a deep professional-to-professional conversation with and looked at the impact, root causes, options to address the problem, and the inspection.
Finally, they would have made a change to reduce the meetings to uncover better ways to adapt.
They would have repeated this over several sprints until the too-many-meetings problem was removed and was no longer an issue.
The Math
For those interested in math, here it is. I will assume an average 9 AM to 5 PM job with an 8-hour workday. I will also assume a Monday to Friday-job as this is common in all teams I work with.
Common mistakes
Here are some common mistakes made that cause additional meetings.
Too much time is spent in refinement, where detailed analysis and design are done. Mature scrum teams defer that discussion to either sprint planning or in the sprint. There is a lot to this, and it is out of the scope of this article.
Daily Scrum is prolonged status update meetings that last up to an hour, and people get low value from it but attend because it is the Scrum Thing to do.
Sprint Reviews are limited to a demonstration only. This event is more of a product planning and strategy that consolidates many meetings. Many stakeholders don’t attend because other meetings cover the topics that should be in the sprint review.
Sprint Retrospectives are superficial level, and real change has been made. Most discussions are about doing Scrum and Agile and not focusing on improving what is slowing the team down. The result is people get low value from the event.
Spending too much time refining future work and not focusing on the current sprint goal.
Interruptions, production incidents and live support will lower the focus and cause an overhead of more meetings.
Changing sprint work and not having a goal requires additional meetings to replan; this, too, adds unnecessary work due to the lack of focus.
Scrum events are treated like additional meetings and not there to replace existing meetings.
Think like a PSM III
When someone is complaining about too many meetings, ask yourself if they are applying empirical process control to remedy that situation. 99.9% of the time, they do not make the issue transparent, they do not inspect it and explore different ways to solve the problem, and they do not adapt by making changes. This reveals deeper issues around Scrum's understanding, lack of ownership, self-management, support, or something unique to that time.
Act like a Scrum Master and reveal the problem in an empathetic way. For example, “Hey, team, I see and feel your pain with being overburdened with too many meetings. It does not seem to work, and we should chat about it. <answer> Chat now or in sprint retro?
Then, prepare a plan for a thorough inspection and explore ways to improve. In the inspection, get to real pains and time wasters. Find the root causes and explore options to do things differently so the pain disappears.
This may open big cans of worms that need to be addressed with business leaders. Again, reveal it and ask the leaders for assistance in helping solve this. I will get the involved parties into a single retro and not split team and management; after all, they are all on the same side.
Please look at the Scrum events as placeholder events where existing meetings should be reorganised into the Scrum events. The entire point of these “placeholders” is to create an opportunity for empirical process control to assess the efficacy of the events. [This is a big topic and I will write future posts on it]
Finally, do an experiment, make a change, and then continually focus on it until no one feels the pain of too many meetings.
Wrap Up
Taking your team through this is liberating for them and you. It shows the power of taking ownership of the problem and improving the situation. If anything, get on top of this problem early, as throughput is destroyed when people spend more time in meetings than building and delivering products. Remember, the real value is more about creating valuable “Done” increments and getting things through the door. Actively address all the impediments that slow getting “done” down.