Is Scrum a Heavy Meeting Machine?
Originally published in GoRetro
Originally published in GoRetro
I’d be a billionaire if I’d get a dime every time a developer complained about Scrum events. 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 Plannings with a huge burden to carry during Sprints. 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 need to be like that?
Let me walk you through my perspective on the Scrum framework regarding meeting routines and how that contributes to negative or positive outcomes. By the end of this post, I hope you gain insights into handling your Scrum events fruitfully.
Scrum Events
Before I jump to my experience, let’s understand the events Scrum entails. Feel free to skip this part if you’re familiar with that. 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. In summary, they are:
Sprint: the core of Scrum lies in its cadence. Every cycle, the team produces value. It’s consistent in its length, no more than four weeks. Two weeks is the most used Sprint length, but teams should decide what fits them better.
Sprint Planning: this event focuses on three questions, why is this Sprint valuable? What can be done? How will the chosen work be done? In short, they craft 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 reach their Sprint Goal.
Sprint Review: The Scrum Team presents what they have achieved 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 finishes, 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 actions for the upcoming Sprint.
Refinement session: by definition, it’s not an event, but it’s 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 creates space for important aspects that lead to creating value sooner. It gives the team the chance to focus work on critical topics. That’s the theory, but the practice may happen differently.
In terms of time, in a two-week sprint, the team would invest ten hours into events. Depending on how events unfold, they can be tiring or inspiring. This connects me to the second part of this piece.
Why Developers Perceive Scrum as a Heavy Meeting Machine
Do you perceive meetings and events the same? Think about it.
If someone invites me for a meeting, I reflect and feel uneasy about it. I’m afraid of wasting my time on something pointless. Yet, when I get an invitation 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 frustrates people. An event, on the other hand, triggers another train of thought.
When developers tell me, “Scrum is a heavy meeting machine,” I immediately think something wrong is going on. 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 their time could be better used for coding instead of being trapped in a place where they barely say a word. Yet, 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 how teams handle it; well, that’s their business. It’s the same as a car; you can have a smooth road trip and be amazed by the landscape around you and the joy you had while traveling. However, if the driver is careless, you will only wish 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, the 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 no connection to 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 the attention goes to evaluating effort and how to tackle a predefined solution. Developers feel powerless. They’ve got to work on something defined by someone else. It’s about implementing solutions and 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 manage 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 have to do is keep the feature factory at full speed. Retrospectives become a moment to complain about external forces and fall victim. The outcome is often horrible, “we cannot change the situation.”
If you’ve experienced something similar to the mentioned points, I need to say something: 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 the outlook of meaningful Scrum events:
Sprint Planning: the session starts with the Sprint Goal. The team crafts together an inspiring goal. Then, they evaluate what they can do to reach the goal and how to organize their work. The outcome is an inspiring challenge the team feels motivated to overcome.
Daily Scrum: every team member shares what they are doing to reach the Sprint Goal. The team evaluates if 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 of what everyone is doing.
Sprint Review: stakeholders are curious to know what the team 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 actions and decides where 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: hope to become a better team than before.
Refinement sessions: conversations start with problems they want to solve, 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 Thoughts
If your team complains about Scrum being a heavy meeting machine, it’s because it’s too heavy for them. Explaining the theory behind each event won’t help you 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. From my experience, first, you need to understand, then be understood. You will need to understand whatever puts the exchange down and change that.
Actions speak louder than words.
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊