Scrum smells, pt. 8: Scrum has too many meetings

Countless times I've heard from developers that scrum makes them waste time by assigning too many meetings. I've heard that from people who have used scrum, or shall I say people who have attempted scrum adoption.

So let's get this straight today. Why do developers often feel there's too much talking and too little real work? Is that really what scrum is supposed to address?

What does the scrum guide say?

Let's have a look at the scrum guide. It says that the following events should take place:

• Daily scrum (maximum 15 mins per day)
• Sprint planning (maximum 8 hrs per month)
• Sprint review (maximum 4 hrs per month)
• Sprint retrospective (maximum 3 hrs per month)

On top of that, the guide tells us to perform backlog refinement, but it does not specify a particular meeting or event for it. Scrum guide says to allocate approximately 10% of the time for refinement activities. That makes for 4 hrs a week or 12 hrs a month.

So it all adds up to one whole work-day being occupied by not working, right?

Developer role perception

New scrum adopters usually come from a world where software developers are a narrowly defined role. Such developers get a requirement from a business analyst and documentation from a solution architect. They get UI components from a designer. They take it, do their coding part, and hand the stuff over to someone else to integrate and test it. The responsibility for preparation, planning, and verification is not their responsibility and out of their competence.

The Agile approach believes this is not very efficient. It strives to create small development teams where everyone is a developer, contributing to the creative process from the thinking phase up to the verification and deployment. This development team has much more deciding power, can choose its own strategy and course of action, and (in the ideal world) the stakeholders rely on its honest judgments.

That's what makes it more effective. A group of experts communicating with each other will usually come up with better ideas and solutions than a single person. So the team has the freedom to choose their way when tackling a problem. But in order to do that the team also needs to have the means to understand the problem fully. It needs space to coordinate effectively and choose a course of action and necessary tools. It also needs to make sure they work on meaningful things.

The blind flight

We intuitively feel that some sort of the so-called overhead is necessary so that the team can figure out what it needs in order to work effectively. Without any communication or preparation, efficiency could hardly ever be achieved.

And that is essentially why scrum prescribes the events it does. The sole purpose is to facilitate the team's ability to work effectively on relevant and valuable items. It is the imperative that gives meaning to all the single events that happen within the team. It's not a bunch of random separate meetings. It's a concept.

One of the principles of Agile development is to constantly remove activities that are not useful. So let's try to apply this to the key overhead activities that happen within scrum. Let's view the ceremonies without their labels for a moment. What would happen if we removed:

1. Operative team synchronization. The on-the-go chance for the team to synchronize on its progress, make short-term plans and decisions. Removing team synchronization altogether would create a bunch of individuals working alongside each other, not a team. Such individuals would not adapt and help each other out to achieve a common goal. Removing such activity would destroy effectiveness.
2. Making a plan - both, a long and short-term one. A chance to look a few weeks or months ahead and to decide what to work on. To prepare a strategy on how to distribute the work, realize what to beware of, and get some distance from daily work. Removing planning activities would cause an inability to work on relevant stuff, to use the team's resources effectively, and foremost any ability to see the context of what the team is working on. A releasable product increment at the end of the sprint would become a coincidence, not an intentional act. Development becomes a blind flight.
3. Improving the way the group works. A review of what works and is useful and what are the painful points. Any system that lacks a self-feedback loop can't improve and adapt to changes. Removing attempts to change the way of work prevents any improvement from happening, which leads (among other things) to a drop in team member motivation and involvement.
4. Keeping the stakeholders in the loop. Not only do we need to gather feedback if we're on the right path. But more importantly, we need to manage the expectations of people around the team to keep them aligned with reality. The more these expectations drift away, the more troublesome the whole environment becomes. Angry people who have the power to influence the project in a negative way are the last thing we need.
5. Deciding on what to actually do. Preparing the backlog into a state, where developers know they can actually deliver it. And that it is worthwhile doing. Dropping such activity leads to a situation, where we invest efforts into irrelevant things.

Where is the culprit?

We see that the activities above are all necessary to have a working project or product development. They need to happen, somewhere, sometime, invisibly, organically along the way. They always happen, regardless of what we call the project or product management approach. It's just that the scrum guide tries to concentrate them into an organized scheme so that it is easy to follow. It makes it visible. So why not use the concept and rather reinvent the wheel?

From my experience, the distaste for scrum events usually stems from the team not fully understanding the implications of omitting some of the five key overhead activities I mentioned above. Especially the role of refinement activities is often completely misunderstood and the implications of letting the backlog rot are not sufficiently feared. I wrote on this topic previously.

In addition, a narrow perception of a developer's competencies and responsibilities is another key factor. The mind shift required to view people as an active element in the product design, planning, and decision making usually takes some time. The goal is to finish stuff as a team, not to be just a cog in a machine which does not have any power to change things. And to achieve that, the activities of a developer must not be limited just to coding.

Thirdly, an ineffective way of leading scrum events. The ceremony is held just because the team is supposed to hold it. The meeting should be done, but no one actually has a clue as to why they gathered and what the purpose of the meeting is. It has no clear guidance, no clear gist. Meetings serve just for a single person (often a product owner or a scrum master) to communicate direction to the developers. The developers feel that they don't have the power to change things anyway - that the organizer is just trying to make an illusion they have the freedom to decide things, but in the end, someone else's decision is superior. That makes the developers feel cheated. It genuinely feels like a waste of time.

The way out

From my experience, the process of fully understanding and appreciating scrum activities (and the ceremonies supporting them) comes with the team's maturity and guidance. If led well, the team will sooner or later learn from the painful implications of omitting them.

It would, however, be a mistake to enforce a particular correct way of doing them. I find it is usually better to offer experience and practices that have worked for other teams, but let the team find their own taste for how to perform it.

The development team is a self-organized unit that has the right (and obligation) to decide on the best way to solve problems. Let's take it also into the exact form of how the scrum events are held. If there's something to be made otherwise to foster the effectiveness and the goal of the meeting itself - why not do it?

Let the team give them space to learn from it. That is, I believe, the best way to keep teams running and becoming effective in the long run. Agile principles are empirically oriented after all.

Written by: Otakar Krus