The Good, the Bad and the Ugly of Scrum
When I started with Scrum, I was a fanboy, fawning over the promise of a better way of working. Back then, I was a QA and painfully aware of all the limitations of Waterfall. With testing being one of the last phases, all the problems of others ultimately ended up on my plate. I always was short on time and often had to work overtime to make up for the time lost by others. I believed Scrum offered a far better alternative than the way I was used to working.
As I gained more experience, my view of Scrum has become more balanced. After 7 years of working with Scrum, I start to see the Good, the Bad, and the Ugly of Scrum.
Over time, the amount of things I dislike about Scrum has grown. I’ve written many articles on the things I like about Scrum, now the time is ripe to provide a more balanced perspective.
This article will focus more on the Bad and Ugly parts, since I have written so much about the Good already.
We just finished a Sprint, everyone is exuberant and happy that we met the Sprint Goal. And then, the next Sprint starts, and a new goal is crafted. Then, the cycle begins again. Sprint after Sprint after Sprint: Wash, rinse, repeat.
Every Sprint, a Sprint Goal is looming over your head. And you can do whatever you want, chill, do pair programming or try some fancy Liberating Structures, as long as you meet the Sprint Goal. And then, there will be a new one waiting for you, ad infinitum.
But the Sprint Goal isn’t the only goal you are aiming for each Sprint. Every day you need to create a new sub-goal. At the Daily Scrum, the Development Team creates a plan for the next 24 hours. And at the subsequent Daily Scrum, progress towards this plan is reviewed, and a new plan is created for the upcoming 24 hours.
All this focus on following daily plans and reaching Sprint Goals stresses people out. Scrum Teams become prone to enter Feature Factory mode, where the only thing that matters is delivering what was promised. It prevents Scrum Teams from taking a step back and reflecting on what we can do to make an actual difference.
And if you weren’t stressed enough already, it’s called a Sprint and not a Stroll.
The Product Owner is responsible for maximizing the value of the product. One Product, one Product Backlog, one Product Owner. Break this rule, and you’re not doing Scrum. It doesn’t matter if you are running a start-up or a 300 million dollar business. That’s putting a lot of responsibility and faith in a single person!
Companies are not willing to give so much responsibility to a single person. And even if they are willing, the moment you have to deal with more than 2 Development Teams as a Product Owner, you will become overwhelmed. You will be so occupied keeping the Scrum train chugging along that you won’t have time to think about your Product Vision, Product Strategy, or participate in discovery.
I’ve never worked at a company where they had Product Owners as intended by Scrum. Every Product Owner was a Feature Owner, working together with many other Feature Owners on the same Product. This is not how it is supposed to be, but it is how many companies try to make the demanding Product Owner role scalable.
It’s easy to find articles where people describe that Scrum doesn’t work for them. When you read comments on these articles, you will always find someone that says:“But you weren’t doing Scrum. Of course it didn’t work out, duh!”
I am guilty as charged, as I’ve said this many times before as well. Recently someone wrote an article about Scrum not working out that went viral: Scrum Is Dead. All Hail Kanban, the New King. I even wrote a response to show how the team of the author wasn’t doing Scrum. However, the fact of the matter is, many people loved the original article. Even though it was utterly inaccurate about both Scrum and Kanban. What can we conclude from an article receiving so much praise yet nothing about it was even remotely true?
My conclusion is that most people and companies don’t get Scrum. Scrum is explained the wrong way to them. Scrum seems deceptively simple, yet it is hard to understand and implement the right way. Every company I have joined, I can easily point all the things they are doing wrong in the realm of Scrum and the problems this leads to. The question then becomes: whose interpretation of Scrum is correct? And why are so few able to get it right?
A troubling weakness of Scrum is that few companies get it and can implement it with success. You can blame it on the people, but if many companies suck with Scrum, part of the blame should shift to the framework itself. Apparently, Scrum’s simplicity and the fact you need to connect and add many of the dots yourself makes Scrum confusing and difficult to roll-out successfully.
Scrum requires a deep understanding and willingness to change the status quo to work out. Few companies are motivated enough to dive in the deep end and do the hard work necessary to pull through with it. Much easier to put on a Scrum facade or roll out SAFe instead.
Most Scrum Masters are ill-equipped to succeed in their role. Being a Scrum Master is demanding and challenging. It requires a deep understanding of Scrum, excellent soft skills, situational leadership, and the ability to make others understand Scrum. Many Development Team members get assigned the role of Scrum Master without adequate training, sufficient soft skills, or even knowledge of Scrum.
These Scrum Masters struggle, and fall back pointing to the rules without understanding why these rules matter. The end result is a dogmatic, inflexible interpretation of Scrum that totally misses the point. Scrum is never the point, delivering products of the highest possible value is.
Luckily, as Scrum is becoming more popular, we’re seeing more and more capable and skilled Scrum Masters available in the job market. Companies should take the role seriously and stop believing that any Development Team member or Project Manager is capable of fulfilling the role. That doesn’t do justice to the complexity of the Scrum Master role, and how different it is compared to being a member of the Development Team. A good Development Team member isn’t necessarily a good Scrum Master and vice versa.
Many companies struggle to apply Scrum in an environment where many Scrum Teams need to work together in the same product. If you aren’t convinced of this fact, just realize how many scaling frameworks exist to help companies scale Scrum:
And there are many more approaches I didn’t even mention. Companies are looking for a boilerplate solution to make Scrum scale with many teams working on the same product. The fact so many approaches exist seems to suggest that vanilla Scrum just isn’t cutting it with many teams. This is a shame, as most companies with successful products work with multiple teams on the same product.
Scrum is a process framework. It is purposefully incomplete. Scrum leaves it up to the people who do the work to enrich Scrum with the additional process necessary to deliver valuable products. This is part of the reason why Scrum is so simple and seems to be implemented differently at each company. It is also why there are so many ineffective adaptations out there.
The Scrum Guide isn’t enough to use Scrum to deliver valuable products. The parts that you add are what makes it a success or a failure. I hope that in the future, there will be many more patterns and anti-patterns available to help Scrum Teams figure out better ways of working depending on their context.
Scrum doesn’t tell you what to do but shows you what is going on. However, sometimes even when you know what is going on, you have no clue what to do next to make things better. This is where many Scrum Teams need more help than Scrum Masters, Product Owners, or the Scrum Guide can provide.
The strongest and weakest link of Scrum is how the people working are empowered to implement and complement the process framework. But do they have the knowledge and capabilities to carry that burden? Companies need to be able to handle the weight of that great responsibility. Most companies unfortunately aren’t up for the difficult job of enriching Scrum so it can deliver on its promise of making products of the highest possible value. These companies end up doing what they did before, with a slight twist.
I still love Scrum, like a favorite mug where the porcelain is starting to show some cracks. But I can understand why many companies are struggling with Scrum. We need to do a better job as Scrum practitioners to bridge the gap between theory and practice.
We need rum fewer Scrum fanatics and less Scrum bureaucracy. If you are doing Scrum for more than a year and your main focus is still talking about the rules of Scrum, then you’re definitely doing something wrong. We need more people who understand and adapt Scrum based on what is required to make it a success in the organisation.
We need to meet people where they are, not where we want them to be. We need to gently hold their hand and nudge them to embark together on an Agile journey in the right direction.