Is Scrum a Heavy Meeting Machine

If someone gave me a dime every time a developer complained about Scrum Events, I’d be a billionaire. Recently, I noticed an increased resistance towards Scrum; developers challenge whether the framework helps them get their work done or gets in the way.

^{Some developers urge to abandon Scrum.}

You may have already experienced awful outcomes of Scrum Events. Some examples are:

• Team members leave Sprint Planning's with a huge burden to carry during Sprints, and pressure is all they feel.
• Refinement sessions exhaust everyone, and they feel lost after the exchange.
• Stakeholders couldn’t care less about Sprint Reviews, and Scrum Teams leave the event disappointed and feeling they wasted their time.
• Retrospectives become mechanical: the same questions are asked every time and nothing changes; external factors trap teams and they become powerless.

Why would developers want to attend such pointless meetings? How would that help them get their work done?

When developers see no value in Scrum Events, they will find excuses to skip it. But does it have to be like that?

Let me walk you through my perspective on the Scrum framework for meeting routines and how it contributes to negative or positive outcomes. By the end of this post, I hope you gain some insights into handling your Scrum Events fruitfully.

Scrum Events

Before I jump to my experience, let’s understand the events that Scrum entails. Feel free to skip this part if you’re familiar with them. Otherwise, it will help you know the reason behind each event and how they connect.

The following image gives you an overview of the Scrum framework:

Scrum has five events and frequent refinement sessions that teams often treat as another event. Described in brief, they are:

• Sprint: The core of Scrum lies in its cadence. Every cycle, the team produces value. The Sprint is consistent in length, lasting no more than four weeks. Two weeks is the most common Sprint length, but teams should decide what best works for them.
• Sprint Planning: This event focuses on three questions: why is this Sprint valuable? What can be done during the Sprint? How will the selected work be executed? In short, the team crafts the Sprint Goal, agree on what they can do, and clarify how they will make it possible.
• Daily Scrum: Every day, the Scrum team gets together to inspect their progress towards the Sprint Goal. They identify what hinders them and define actions to overcome their challenges and ensure they can meet their Sprint Goal.
• Sprint Review: The Scrum Team presents what they have accomplished on the Sprint's end. The objective is to inspect and identify future changes. Stakeholders are part of the review, and it should be a working session instead of a boring presentation.
• Sprint Retrospective: As the Sprint comes to a close, the Scrum Team stops to reflect on how they could improve as a team. They search for opportunities to increase their work quality, effectiveness, and collaboration. Every Sprint Retrospective should end with action items for the upcoming Sprint.
• Refinement Session: By definition, it’s not an event, but rather a continuous exchange with team members to refine their upcoming work. Its purpose is to build a shared understanding of future work and enrich the Product Backlog with valuable information.

In a nutshell, each Scrum Event makes space for important aspects that lead to creating value sooner. It gives the team a chance to focus work on critical topics. That’s the theory, but things don’t always work out that way in practice.

In terms of time, a two-week sprint should include ten hours for events . Depending on how events unfold, they can be tiring or inspiring. This brings me to the second part of this piece.

Why Developers Perceive Scrum as a Meeting-Heavy Machine

Do you perceive meetings and Events to be the same? Think about it.

If someone invites me to a meeting, I reflect and feel uneasy about it. I’m afraid of wasting my time on something pointless. But when I get invited to an event, I’m curious about it; I’d be open to it because I expect to gain something. That’s how I feel about meetings and events.

I know meetings aren’t supposed to be bad, but given our cumbersome hybrid work, an exhaustive meeting routine tends to frustrate people. An Event, on the other hand, triggers another train of thought.

When developers say to me, “Scrum is a heavy meeting machine,” I immediately think something went wrong. From my experience, developers love coding and solving problems, and they hate anything that gets in the way of doing that. Meetings become an obstacle for them; they feel that their time could be better spent coding instead of being trapped in a place where they barely say a word. Still, they do enjoy collaborating with other developers to create valuable solutions – so why do they perceive Scrum events as pointless meetings?

My perspective is simple; the problem is who drives the car and not the vehicle itself.

Scrum defines what should happen, when, and why that is important but as for how teams handle it, well, that’s their business. It’s not different from a car; you can have a smooth road trip and be amazed by the landscape around you and the joy of  traveling. However, if the driver is careless, you will spend the entire time wishing the trip ends immediately, and you will never travel with that person again.

Now, let me walk you through why I perceive Scrum Events descend into meetings nobody wants to attend.

• Sprint Planning: When Product Owners focus on the output, planning will focus on capacity and features and ignore the Sprint Goal or be uninspiring. The result is a packed Sprint Backlog with unrelated items, and the outcome is pressure.
• Daily Scrum: Without a Sprint Goal, developers divide and conquer. Everyone takes care of something that has nothing to do with each other's work. Developers talk about what they did, what they will do, and maybe ask for help – but nobody talks about the Sprint Goal. The outcome is a fragmented team running in different directions.
• Refinement Sessions: The session derails when attention shifts to evaluating effort and how to tackle a predefined solution. Developers feel powerless. They’ve got to work on something that was defined by someone else. It’s about implementing solutions,  not solving problems.
• Sprint Review: When Sprints focus on delivering features, stakeholders pressure the team to produce more output, and no matter what they do, it’s never enough. Stakeholders dictate whether the output meets deadlines while keeping a service provider relationship with Scrum Teams. The meeting is dull and heartless. Nobody cares.
• Sprint Retrospective: The team feels trapped in a vicious circle. All they do is keep the feature factory at full speed. Retrospectives become a time to complain about external forces and fall victim. The outcome is often horrible, with a feeling of “we cannot change the situation.”

If you’ve experienced something similar to the points I’ve mentioned, there’s something you have to know: This is not Scrum! If I were you, I’d run away from these meetings. However, I’d like to show you a way out of this trap. Please stick with me.

From a Meeting Machine to Energising Events

When you have inexperienced drivers, trips are cumbersome. The same happens with Scrum. The events can be frustrating, but when you’re mindful of critical aspects, you will enjoy the journey and see value in it. Let me give you an example of meaningful Scrum Events:

• Sprint Planning: The session starts with the Sprint Goal. The team crafts together an inspiring goal, then evaluates what they can do to reach the goal and how to organize their work. The outcome is an inspiring challenge that the team feels motivated to overcome.
• Daily Scrum: Each team member shares what they are doing to reach the Sprint Goal. The team evaluates whether the goal is endangered and if so, they act to ensure they can achieve it. The outcome is confidence in reaching the goal and clarity on what everyone is doing.
• Sprint Review: Stakeholders are curious to know what the team has created, and the team is eager to learn how their work resonates with them. The session unfolds as a working session: Business stakeholders and the Scrum team collaborate to uncover ways of creating value.
• Sprint Retrospective: The Scrum Team evaluates the previously agreed-upon actions and decides to conclude, keep, or drop them. Mindfully, the team evaluates how the previous Sprint went and how they could take action to improve their work quality and effectiveness. The outcome is clarity on how to become a better team than before.
• Refinement Sessions: Conversations start with problems that need solving, and the team builds a shared understanding of problems and what would lead to success. The outcome is clarity on the problem and potential solutions for it.

Final Thought

If your team complains about Scrum being a meeting-heavy machine, it’s because it’s too much for them. Explaining the theory behind each event won’t help you to change their perspective.

Don’t try denying reality. It’s better to learn from it and adapt.

Helping your team benefit from Scrum Events will require action. In my experience, you first need to understand, and only then be understood. You will need to understand whatever puts the exchange down and change that.

Actions speak louder than words.

‍