One of the most common complaints you may hear about Scrum is that it introduces too many meetings. Let’s have a closer look at this problem.
Summary of Scrum meetings
Scrum framework defines several meetings that are designed to address 3 pillars of every implementation of empirical process control: transparency, inspection, and adaptation.
All Scrum meetings are time-boxed and for a 2-weeks sprint these meetings last accordingly:
- Sprint Planning – up to 4 hrs
- Daily Scrum – up to 15 mins per day, roughly 2 hrs per 2-weeks sprint
- Sprint Review – up to 2 hrs
- Sprint Retrospective – up to 1,5 hrs
- Backlog refinement – usually around 4 hrs
It all sums up to around 2 days which gives about 20% of the total team’s capacity.
At first sight, it may sound a lot, but if you consider it’s all you need to deliver a high-quality product valued by its stakeholders it doesn’t look that overwhelming, does it?
Times before Scrum
One may say that in traditional software development developers weren’t spending that much time in meetings. But let’s be fair here – when comparing the total time of meetings, all project’s phases and all meetings should be considered, including activities that many people tend to forget about like discovery workshops with a client, various status meetings, endless calls with stakeholders, architecture and design reviews, etc.
Of course, in many cases, not all team members attended all meetings, but it was at the cost of having to create a lot of documentation and do a lot of formal handovers that, let’s face it, also consumed time (but it wasn’t called a meeting, was it?).
And that’s a key difference. Scrum focuses on conversations and provides a minimal set of rules to have productive conversations at the right time with the right people at the right level of detail.
Other meetings
In many, especially larger, organizations, Scrum ceremonies are not the only meetings that people are expected to attend.
Unfortunately, Scrum events and various all-hands, company-wide presentations, one-on-ones, workshops, etc. usually land in the same bucket which blurs the whole picture.
While I can understand the pain, those 2 types of meetings need to be differentiated and addressed separately. Scrum is known for pointing out many problems organizations have and having too many non-productive meeting that is not related to your daily job may be actually one of them.
Named meetings
One of the reasons why so many people blame Scrum for enforcing too many meetings is that those meetings have names and predefined cadence/schedule.
It’s much easier to forget about three hour-and-a-half long ad-hoc catch-ups with chief architect than a sprint planning that happens every other Monday and last four hours.
Basically, regular meetings that have names are much easier to criticize.
Meeting is not work
One of the reasons why meetings are so criticized and avoid may be that they are not considered as real work. For many people, especially developers, anything but coding is classified as a distraction that prevents them from generating value.
I must say that nowadays, in fast-paced environments most of us work at, such a perception if pretty old-fashioned and requires mindset change.
Meetings are not bad per se. Product development is not a routine work and meaningful conversations are crucial and valuable. Meetings are not about a number of man-hours dedicated to them, but about outcomes they can generate. After all, everyone’s creativity, wisdom and expertise were used to arrive at a shared understanding that is carried by all.
Poor facilitation / non-productive meetings
We’re finally getting to the most common root cause of the whole problem – the upsetting reality is that many meetings are basically non-productive and perceived as a waste of time.
I can fully understand anybody who complains about having to spend 2 hrs in a meeting that doesn’t address any problem or need that person has and is concluded with no meaningful outcomes or action points. It’s irritating, isn’t it? But it also sounds familiar, doesn’t it?
So, what can be done about it? Most probably we can’t change all the meetings, but we definitely have an influence on how the team’s Scrum ceremonies are held. The key is good preparation and facilitation that focuses on the purpose of the event and respect for the time-box. It’s critical that everyone feels safe and is encouraged to take an active part in the conversation which is productive and on-topic.
For other meetings, making sure that 1) an agenda is provided, 2) only impacted/interested stakeholders are invited and 3) discussion is kept to the point (and doesn’t derail) should do the job.
Finally, please have a look at your personal attitude towards various meetings. Are you always prepared? Do you actively participate in the discussion or do you do your stuff on your laptop? Please bear in mind that nothing will change if you don’t.
