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 acknowledges 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 we're time boxed, but for example our daily Scrum takes at least 30 minutes and afterwards we still don't have a solid plan as a team."

The Scrum Guide states 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 1 month are:

• Daily Scrum: 15 minutes


• Sprint Planning: max 8 hours


• Sprint Review: max 4 hours


• Sprint Retrospective: max 3 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 what is it, this feeling often does arise?

[caption id="attachment_22645" align="aligncenter" width="648"] Collaborative, fun and energising Scrum Events at Schiphol![/caption]

Reasons I can think of:

• Scrum events aren't kept to their prescribed time-box. More time than prescribed in the Scrum Guide shouldn't be necessary. But I've seen daily Scrum's that last for 45 minutes...


• Scrum events lack a clear structure. If a clear structure and agenda is 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 to become really productive. Task switching is one of the largest causes of waste in productivity.

How to prevent Scrum to be characterised as "meeting heavy"?

Possible solution are:

1. Scrum events aren't meetings but opportunities for a conversation. Tobias Mayer describes this perfectly in his book 'The Peoples 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)."


2. Stick to the prescribed time-box. Take for example the daily Scrum; I think this event exceeds its time-box the most often. While the daily Scrum in particular is an event that you only learn to do well when you respect the time-box of 15 minutes. Longer shouldn't be necessary to synchronize as a team and create a plan for the upcoming day. Sticking to the time-box, although the goal of the meeting hasn't been achieved, forces to 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.


3. 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-/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 expected outcome of the Scrum events is provided by Crisp with the Agile Meeting Cube.


4. 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 as a meeting but an activity to collaborate as a team with the goal of reviewing and revising Product Backlog Items. The advise is to spend on average 10% of the capacity of the Development Team to refinement, the way it is done isn't prescribed and is up to the team.


5. 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 on achieving the necessary focus should be a reasonable goal.


6. Ensure the fun factor is present. The Scrum events or 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 not using a beamer with lots of PowerPoint slides, put the chairs in a circle and minimize the use of laptops. And again: don't consider meetings as a ceremony with all the 'smells' attached, but as an opportunity to collaborate, learn and have fun!


7. 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- en daily plan. Sometimes the team feels they have got lots of meetings, 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.


8. 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 offer some solutions to prevent a meeting culture, or put differently, prevent the feeling of Scrum as meeting culture enabler.

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