Scrum: Failure By Design?

Are we witnessing the first signs of a post-Scrum era?

Last week, I read the ‘Scrum Is Cancer’ post on LinkedIn and today I watched the video by Maria Chec on ‘Shall We Stop Doing Scrum?’

While I disapprove of comparing Scrum to cancer, there was something in the post that resonated with me. I definitely recognize the sentiment of developers not being too happy with Scrum.

I don’t have hard numbers, but my hunch is that there are more developers who dislike Scrum than like it. Here is some common (anecdotal) evidence of developers not being fond of Scrum:

“Scrum works if executed well. I've just never seen it executed well in multiple companies.”

“Scrum is a great way of creating jobs for non-technical people and for making non-technical managers feel very involved at the expense of productivity.”

“When people say they're running scrum, they aren't — but think they are, because they have a bad definition of what scrum is. I personally do not like scrum, but I've yet to find a team who actually runs it, so IDK maybe I'd be surprised.” - Reddit Thread I hate SCRUM, is it only me or other programmers as well?

The final comment fits with my personal experience. I’ve never arrived anywhere where they were doing Scrum right, even if they believed they were doing Scrum properly.

Please keep in mind that many of the companies I work with are in the Netherlands. The Netherlands is one of the leading countries in Scrum adoption globally. We have the highest number of Scrum Masters per capita. If anything, I should have had more positive experiences than most other people. It’s still anecdotal evidence, but it does feel fishy to me that witnessing an excellent Scrum implementation is so incredibly rare. I’ve never seen one.

I’m writing this article to share some of my current thoughts on the struggles organizations are having with Scrum. I don’t claim to have all the answers, but as the years pass, I’m becoming increasingly worried that Scrum is flawed by design.

Scrum: Meetings, Meetings and More Meetings

For many developers, working with Scrum feels like spending time in way too many meetings and being forced to work in a way they don’t want to.

To me, this Scrum criticism is incredibly strange. Scrum is supposed to be a framework that revolves around empowered teams that discover and devise their own way of working. How can the very thing that’s supposed to help with empowering them feel so disempowering? It’s extremely ironic.

The common complaints I hear are too many meetings together with an obsessive focus on User Stories and Story Points. All these things are not part of Scrum, but for some reason, they often seem to go hand in hand.

To make things worse, whenever someone says they don’t like Scrum and that it feels like a lot of bureaucracy and rules, then their criticism will be simply dismissed by the community with: you’re doing it wrong.

But when so many are doing it wrong, isn’t some self-reflection by the community warranted?

What if they are right, and there’s something we can learn from the inability to roll out Scrum perfectly?

Scrum Is a Team Level Framework That Expects Your Organization to Change

Scrum consists of events, artifacts, accountabilities, values, and the rules that bind them together. All of these are described from the perspective of the Scrum Team.

This makes Scrum a team-level framework. It expects your organization to change to accommodate the Scrum Team and wrap itself around their needs. No matter how hostile your organization is to empowered teams that discover better ways of working.

Scrum doesn't tell you how your organization has to change, only how Scrum is supposed to work. Scrum describes how the Scrum Team should work together to produce at least one Product Increment per Sprint that meets the Definition of Done and the Sprint Goal.

Scrum is incredibly prescriptive on how you can best achieve that goal. Whether your organization supports the kind of team and conditions that make it possible to work in that way is not a consideration. You’re supposed to adapt your organization to make Scrum work.

What if this is simply the wrong approach that leads to dogma and teams trying to follow rules that won’t work in their current context? What if we would take a different approach? Instead of being prescriptive on the team level and clinging to how the team should be working, why not be prescriptive on the organizational level instead?

Why not do it the other way around and describe how the organization should change to accommodate empowered teams?

What Would An Organization-level Scrum Framework Look Like?

Instead of making a team-level framework that focuses on how the team should work together, why not make an organization-level framework that focuses on the conditions necessary for empowered teams?

Shouldn’t concepts like psychological safety, humble planning, and intent-based leadership be a prerequisite to be provided by the organization for empowered teams to succeed? The hard part is having the right conditions for empowered teams. Not having an empowered team knows how to follow Scrum.

Why is a framework for empowered teams micro-managing how the team has to work inside the framework? If we trust them to figure out better ways of working outside the framework, then why not inside the framework, too?

What would happen if we shifted our attention toward what the organization has to provide for empowered teams to work? Imagine that we would describe the conditions that should be created instead of describing how the teams should exactly be working. Could that possibly produce far better results?

Perhaps the Scrum Guide took the wrong approach. It could be that a team-level framework is doomed to bump into the walls of an organization that cannot accommodate the particular and finicky needs of Scrum.

Maybe we’ve got it all backward. Instead of describing how a Scrum Team should work, we should describe how an organization can provide the conditions for an empowered team to succeed.

I can tell you one thing for sure: whatever I write will be dismissed by some in the community with “It’s their fault because they are doing Scrum wrong.”

And that’s exactly the problem in the Scrum community and why we’re being referred to as ‘Process People’.

As a Dutch saying goes:

“The beam of a lighthouse does not illuminate the ground directly underneath it.”

This blind spot definitely applies to the Scrum community: in the Scrum Guide we trust and the developers are the ones suffering.