Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9 and 10).
Myth: In Scrum, we spend too much time in meetings
When Scrum is introduced, Development Teams tend to enthusiastically embrace it. Scrum promotes self-organization, autonomous, multidisciplinary teams and acknowledges individual qualities and contributions to a team effort. Who doesn’t want to be part of a Scrum Team?
Quite often however, after the Scrum honeymoon, people start raising issues:
- “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 our daily Scrum takes at least 30 minutes and afterwards we still don’t have a solid plan as a team.”
These frustrations drive some Scrum Teams to abandon Scrum altogether. Today, we’re going to bust the idea that Scrum is an enabler of a meeting culture. A culture in which Scrum teams are stuck in too many unproductive meetings that prevent them from creating a valuable product for their customers.
Busting the myth
The Scrum Guide describes five Scrum events (not ‘meetings’) that create regularity and minimize the need for meetings not defined in Scrum. Every event has a clear purpose and plays an important role in the inspect-and-adapt cycle of Scrum. The events are time-boxed, which means they have a maximum duration.
Let’s address two of the issues behind this myth separately:
- Factually, how time-consuming are the Scrum events?
- Should we spend (this much) time on these events?
Factually, how time-consuming are the Scrum events?
The prescribed time-boxes are based on a sprint of 1 month. For shorter Sprints, the event is generally shorter. The time-boxes are:
- Daily Scrum: 15 minutes;
- Sprint Planning: at most 8 hours;
- Sprint Review: at most 4 hours;
- Sprint Retrospective: at most 3 hours;
The activity of refining the Product Backlog requires 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.
For a full-time developer in a 4-week Sprint, the Scrum events take at most 22,5% of the time:
- Full-time: 160 hours per Sprint
- Scrum events: 20 hours
- Backlog refinement: at most 16 hours
If we visualize the Scrum events for a 2-week Sprint it doesn’t look too bad right?
Should we spend (this much) time on these events?
Scrum is built on the observation that software development is a very complex endeavour. As we work together, our understanding of both the problem and the solution grows. This requires collaboration between the people that are doing the work. By bringing in our individual perspective, expertise, creativity and wisdom, we have a better chance of making sense of this complex problem we’re trying to solve. Central to this collaboration are conversations, as Tobias Meyer puts it in his book ‘The People’s Scrum’. Conversations about what has been done, what should be done next and whether or not that actually worked.
Scrum provides a minimal set of boundaries (five events, three roles, three artifacts) to have the appropriate conversations at the appropriate time with the appropriate people. It focusses our conversations on what is important at that point in time, as part of the empirical process of Scrum.
“Scrum provides a minimal set of boundaries (five events, three roles, three artifacts) to have the appropriate conversations at the appropriate time with the appropriate people.”
Spending time on the Scrum events is incredibly valuable as it helps us plan the work, align our work with the problem that we’re trying to solve and to continuously improve our process through timely reflection. Within the complex domain of software development, this is not a luxury but a necessity.
The origins of this myth
So where does this myth come from? We think there are a couple of reasons:
1. The meeting culture was already there
The visualisation of the 2-week Sprint with the Scrum events probably isn’t the reality for many Scrum Teams. The Scrum Guide states that the Scrum events should be used to create regularity and to minimize the need for meetings not defined in Scrum.
“The Scrum events should be used to minimize the need for meetings not defined in Scrum.”
But Scrum Teams often have to attend meetings outside of the regular Scrum events. For example: company wide presentations, knowledge sharing sessions, progress updates to management, one-on-ones, action review meetings, governance cadence meetings, idea generations meetings, workshops, problem solving sessions, decision making meetings, information gathering meetings, bilaterals with the team manager, introductions, issue resolution meetings, community of practice meetings, training sessions etc. Meetings, meetings, meetings and yet more meetings.
This makes our tidy Sprint schedule a bit more convoluted:
Are the Scrum events really the problem here, or does Scrum simply make the existing meeting culture transparent? Are all these other meetings really necessary? Or are they merely the result of non-optimal implementations of Scrum, with people being part of multiple teams, teams that are not really cross-functional (and have lots of dependencies) and Product Owners without actual mandate. This is where the role of the Scrum Master becomes important; help identify those meetings that aren’t necessary, and eliminate them from the schedule. Help the organisation find other ways to organize work that aligns better with Scrum, so that the need for additional meetings can be minimized.
“Are Scrum events really the problem, or does Scrum simply make the existing meeting culture transparent?”
2. Poor facilitation of the Scrum events
If we decide to spend time on a Scrum event, it should be facilitated in a way that is respectful of that investment. In reality, most Scrum events are facilitated in a way that is quite boring. The Sprint Review is a lengthy presentation of new features, without opportunities for interaction and exploration. The Sprint Planning has the team sitting around a table for a good four hours, listening to the two people that do most of the talking. The Daily Scrum devolves into in-depth discussions between a handful of people, running up to 30 minutes or more. And because no refinement is done during the Sprint, Sprint Planning tends to drag on and on as work is identified and broken down.
Good facilitation requires focus on the purpose of the event and respect for the time-box. What should we have conversations about? How can we have these conversations in ways that are more effective than just sitting around a table, listening to a couple of people? The role of the facilitator is to keep the conversations on-topic, to create a safe atmosphere and to promote open discussion. Without proper preparation and facilitation the Scrum events will be (and feel like) a waste of time.
“Without proper preparation and facilitation the Scrum events will be a waste of time.”
3. Part-time team members or people that are part of multiple teams
For part-time members of Scrum Teams, the Scrum events will obviously consume a larger part of their workweek. This happens when people are part of multiple teams, or do a lot of work outside of their team. Some people possess a scarce skill that is needed by several Scrum Teams - like database administration or a ‘rockstar’ developer. If that person has to join every Scrum event, it will certainly feel like a 5-headed meeting monster.
Is Scrum really the problem here? Or is Scrum simply surfacing existing organizational dysfunctions - like the idea that putting people in as many teams as possible is ‘more efficient’ or that organizations depend on individuals with critical skills.
“Is Scrum simply surfacing existing organizational dysfunctions?”
4. ‘Only sitting behind my laptop is work’ (or efficiency over effectiveness)
In many organizations, there is a strong implicit belief that ‘only sitting behind your laptop is work’. For developers, this is akin to saying that ‘only coding is work’. These beliefs are often reinforced by classifying ‘laptop work’ as billable work, whereas meetings are non-billable. The core assumption here is that we generate value only when sitting behind our laptops, and that we should maximize this time.
The idea that ‘only sitting behind my laptop is work’ is an old-fashioned idea. Product development is not routine work. We frequently need to have conversations about where we stand, to make sense of what is happening and to think about what next step makes sense. These conversations are necessary and valuable. Although it may feel inefficient to spend time with the entire team in a room (‘that’s 3 hours with 6 people; 18 hours of non-billable work!’), it will be more effective in the outcomes that it generates. After all, everyone’s creativity, wisdom and expertise was used to arrive at a shared understanding that is carried by all. We don’t have to spend time after the meeting building consensus, bringing members up-to-speed on what was decided or restarting the conversation as members that didn’t attend bring up good points.
“Although it may feel inefficient to spend time with the entire team in a room, it will be more effective in the outcomes that it generates.”
Tips
What can you do to improve the effectiveness of your Scrum Events? How can you make them more enjoyable? Here are some tips, based on our own experiences:
1. Don’t have meetings. Have workshops that promote conversations
‘Meetings’ have the smell of being boring, tedious and energy draining - a group of people sitting around the table waiting for the clock to signal the end of the meeting. Instead, make your Scrum events into something that is fun to do, keeps the energy up and promotes interaction and conversations.
Facilitate the events as workshops rather than meetings. Start with a clear goal and design a series of formats and facilitation techniques that help achieve that goal. Use energizers to keep the energy up and to create a good atmosphere. Allow everyone to be engaged by using a diverge-converge pattern that breaks down large groups into pairs or triplets and have them join up again to share insights. Close the event by asking what stood out for participants; what did they observe? What did they learn? What can be improved to make the event more effective?
“Facilitate the Scrum events as workshops rather than meetings.”
2. Fit meetings into the schedule of the Development Team
For most managers, attending meetings all day long is pretty much their job. They are used to go from one meeting to another. For a developer this is different. Writing software requires incredible focus and concentration. Having many (ad hoc) meetings throughout the day - even if they’re only a minute - breaks concentration and requires a developer to rebuild this focus. This can take 30 minutes or more, even for experienced developers.
Paul Graham wrote an excellent blog post about this problem in “Maker’s Schedule, Manager’s Schedule”. The Scrum events should already minimize the need for meetings not defined in Scrum. The ones that remain should be planned in such a way that they offer the Development Team as much focus as possible and prevent unnecessary task switching.
“Having many (ad hoc) meetings throughout the day breaks concentration and requires a developer to rebuild this focus.”
3. Try Liberating Structures
Liberating Structures are 33 microstructures that allow you to involve everyone in a group – from extroverted to introverted and from leaders to followers. You can use Liberating Structures to spice up your Scrum events. Move away from the stickies and the whiteboards for a moment, and explore these novel facilitation techniques.
“Use Liberating Structures to spice up your Scrum events.”
4. Respect time-boxes
The Scrum events offer the opportunity for transparency, inspection and adaptation. These events are time-boxed, such that every event has a maximum duration. Time-boxes create focus and minimize waste. Sticking to the time-box, although the goal of the Scrum event hasn’t been achieved, forces the team to find a solution for the next time. If you don’t respect the time-box, there isn’t a sense of urgency to fix it.
“Time-boxes create focus and minimize waste.”
5. Prepare the Scrum events.
As a Scrum Team, reserve time to properly prepare every Scrum event. Agree upon the agenda, structure and desired outcome. For example: what structure do we want to use for the Daily Scrum? Will you use the “three questions” or discuss the Sprint Backlog as a starting point? Hold each other accountable on the shown behaviour. If someone isn’t prepared, it’s the teams responsibility to act on it. 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.
“Hold each other accountable on the shown behaviour. If someone isn’t prepared, it’s the teams responsibility to act on it.”
6. Get the most out of the Scrum events
The Scrum events have clear goals:
- Use the Sprint Planning to set a goal for the Sprint and select and identify the work that is needed to achieve that goal;
- Use the Sprint Review to gather feedback from stakeholders and (together with them) determine what next steps makes most sense based on what was learned during the Sprint;
- Use the Sprint Retrospective to reflect on the past Sprint and identify at least one actionable improvement during the next Sprint;
- Use the Daily Scrum to create a daily plan on how the team will work together to achieve the Sprint Goal;
- Use Refinement sessions to break down large chunks of work and clarify what might be needed;
If the Scrum events are done in a way to achieve these goals, the need for meetings outside of these events should significantly decrease. Progress updates, action review meetings, idea generations meetings, problem solving, decision making, information gathering; this can all be part of the Scrum events and create space in the Scrum Teams agenda.
If the Scrum Team has to attend a different meeting, they should ask themselves:
- Why wasn’t it part of a Scrum event?
- How can we make this meeting part of the Scrum events in the future?
- Are the Scrum events delivering their intended value?
To allow Development Teams to work with focus and concentration, additional meetings should be aggressively minimized, except for what is necessary to help the team achieve their Sprint Goal. The entire purpose of the Scrum events is to offer a clear cadence, rhythm and focus that prevent unnecessary task switching.
“The entire purpose of the Scrum events is to offer a clear cadence, rhythm and focus that prevent unnecessary task switching.”
Closing
In this blog post we’ve busted the myth that in Scrum too much time is spend in meetings. We’ve not only described how time-consuming the Scrum events factually are, but also clarified the purpose and importance. After explaining the origins of this myth, we’ve offered some practical tips to prevent or resolve the symptoms.
What do you think about this myth? Do you think in Scrum too much time is spend in meetings? What are your lessons learned?
Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9 and 10).