Scrum Myths: Scrum Is Meeting-Heavy

When Scrum is introduced in a company, most of the time, the development team embraces it with lots of enthusiasm. Scrum embodies self-organizing, autonomous, multidisciplinary teams that acknowledge individual qualities and reinforces the strengths of the team as a whole. Who doesn’t want to be part of a Scrum team?

Quite often, however, after the Scrum honeymoon period, I start to hear comments like:

• “Since the introduction of Scrum, all I do is attend meetings. I didn’t become a developer to attend meetings all day long.”
• “With Scrum, I hoped we would get a team culture, but instead, it feels more like a meeting culture.”
• “I thought Scrum meetings were time-boxed, but for example, our daily Scrum takes at least 30 minutes and afterward, we still don’t have a solid plan as a team.”

The Scrum Guide states that the prescribed Scrum events (they are explicitly not called meetings) are used to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed, such that every event has a maximum duration. The prescribed time-boxes based on a sprint of one month are:

• Daily Scrum: 15 minutes.
• Sprint planning: max eight hours.
• Sprint review: max four hours.
• Sprint retrospective: max three hours.
• Product Backlog refinement: On average, 10% of the capacity of the development team.

Considering these time-boxes, Scrum doesn’t seem a framework that should result in a meeting culture. So, why this feeling often does arise?

• Scrum events aren’t kept to their prescribed time-box. More time than prescribed in the Scrum Guide shouldn’t be necessary. However, I’ve seen daily Scrums that last for 45 minutes…
• Scrum events lack a clear structure. If a clear structure and agenda are missing, it’s difficult to respect the time-box and achieve the desired outcome.
• The team isn’t properly prepared. Every Scrum event requires a decent preparation by the team. To me, this isn’t only a characteristic of a true professional but also an indication of respect towards your team members.
• Meetings not defined in Scrum aren’t minimized. Most likely, the team has to attend other meetings besides the regular Scrum events (for example, company-wide presentations, knowledge sharing sessions or a meeting with a customer). This is sometimes insuperable, but it should be limited as much as possible.
• Meetings aren’t fit into the schedule of a developer. For most managers, attending meetings all day long is their presumed job. They are used to go from one meeting to another. For a developer, this is different. Doing some programming requires a high amount of focus and concentration. Having lots of meetings during the day (and it doesn’t matter if these last only a few minutes) prevents a developer from being really productive. Task switching is one of the largest causes of waste in productivity.

Preventing Scrum From Being Characterized as Meeting-Heavy

Scrum events aren’t meetings, but opportunities for a conversation. Tobias Mayer describes this perfectly in his book The People's Scrum:

“Scrum is centered on people, and people have conversations. There are conversations to plan, align, and to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations, we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection).”

Stick to the prescribed time-box. Take, for example, the daily Scrum. I think this event exceeds its time-box the most often. The daily Scrum is an event that you only learn to do well when you respect the time-box of 15 minutes. More time shouldn’t be necessary to synchronize as a team and create a plan for the upcoming day. Sticking to the time-box even when the goal of the meeting hasn’t been achieved forces the team to find a solution for the next time. If you don’t stick to the time-box, there isn’t a sense of urgency to fix it.

Prepare the schedule for the Scrum events upfront and ensure the goal is clear. Communicate the agenda early. This gives every team member the opportunity to prepare him or herself properly. Also, clarify what kind of preparation you expect from the team given the goal of the session. If someone has to demo a feature during the Sprint review, communicate this as soon as possible and reserve some time during the Sprint. A nice tool to help the team understand the purpose and the expected outcome of the Scrum events is provided by Crisp with the Agile Meeting Cube.

Don’t consider backlog refinement as a meeting. The Scrum Guide describes Backlog Refinement as the act of adding detail, estimates, and order to items in the Product Backlog. Backlog refinement isn’t a formal component of the Scrum framework but an ongoing process to improve the Product Backlog. It shouldn’t be considered a meeting but an activity to collaborate as a team with the goal of reviewing and revising Product Backlog items. The advice is to spend, on average, 10% of the capacity of the Development Team to refinement. The way it is done isn’t prescribed; it is up to the team.

Use “Do Not Disturb” time slots. During these time slots, the Development Team doesn’t have any meetings and will only get disturbed (by someone outside the team) when it’s really urgent. Sure, this shouldn’t interfere with the intention of collaboration and transparent communication that the team wants to achieve, but a healthy balance with the aim of achieving the necessary focus should be a reasonable goal.

Ensure that the fun factor is present. The Scrum events and other non-Scrum meetings don’t have to be boring, tedious, and energy-draining. My intention is always to foster fun, energy, interaction, and collaboration in every session. Tricks to enable this are putting the chairs in a circle, minimizing the use of laptops, and not using a beamer with lots of PowerPoint slides. Again: don’t consider meetings as a ceremony with all the smells attached, but as an opportunity to collaborate, learn, and have fun!

Create a Sprint calendar. Providing transparency by creating a Sprint calendar that contains all the Scrum events and other meetings can be very valuable. It gives the team the insight on what they can expect during a Sprint and helps with creating a Sprint. Sometimes, the team feels they have lots of meetings, and the Sprint calendar transfers the feeling into facts. Based on these facts, the team can decide if the feeling is justified and sometimes has to change.

Embrace meetings with the customer. Considering the Agile mindset, customer collaboration is a vital part of successful product development. Their shouldn’t be a cold customer-supplier relationship, but a partnership where the customer is part a the team, with the desire to create astonishing products. Meetings with the customer therefore should be seen as an opportunity to understand the ‘why’ and ‘what’ of the product and increase the chance of building the right product.

To me, Scrum doesn’t equal a meeting-heavy culture. I can, however, understand the arguments people often use to address this comparison. In this blog post, I've offered some solutions to prevent meeting culture and to prevent Scrum from feeling like a meeting culture enabler.

If you have any other tips, tricks, or experiences, I would like to hear them!