Let's Stop Lying! Almost Nobody Does Scrum
When the output is all that matters, doing REAL Scrum becomes nearly impossible.
Sometimes I rant about things that disturb me. This is one of these moments, but I don’t aim to leave you powerless. I want to help you identify common dreadful traps so that you can act to foster change.
Accepting the status quo isn’t a choice for me, and I do my best to equip you to change the world for the better!
Scrum is the most used Agile framework in the world. Many companies claim to be Agile because they work with Scrum. Yet, I doubt they understand what doing Scrum means at all. From my experience, executives still misinterpret Agile, and therefore, no matter the framework you work with, delivering what stakeholders want is all that matters.
For more than a decade, I worked with Scrum, and despite the fact of companies claiming to use Scrum, here is what I stumbled upon:
Roadmaps determine what to do instead of what to achieve
Scrum teams focus on delivering features instead of solving problems
Product Owners put their energy into gathering requirements instead of identifying problems worth solving
Doing Scrum goes beyond producing a set of features per Sprint.
Let me go through the Scrum framework and critically compare expectations with reality. The content is based on my experience and observations in the digital industry. I hope you can benefit from it.
Many Places Have a Faulty Scrum Implementation!
A massive misconception of Scrum kills the chance of succeeding with it. I’ve often noticed companies use Scrum as a framework focused on execution. Executives want to maximize the output of teams. Inevitably, this faulty understanding of the framework ensures that teams will never reach the benefits of doing real Scrum.
For me, the game of Scrum is simple, and it can lead to success if we live the following:
Deliver every Sprint.
Empower teams to be self-managing.
Inspect & adapt every day.
The framework (rules, accountabilities, artifacts, and events) guides the interactions to play it. Yet, what matters is how we play.
Sadly, companies tend to play the game way differently than that. And Scrum descends into something really awkward. Yet, they pretend to do Scrum, and I think it’s time to stop lying about it.
The following image reflects what I perceive from Scrum in practice:
Let me elaborate on six elements that destroy any chance of thriving with Scrum.
Wish list instead of Product Backlog → All that matters is to have a full backlog
Feature planning → Delivering more features is what success looks like
Daily status report → Sharing something that nobody cares about
Bi-weekly status report → Opening Jira board and having a boring walkthrough
Mechanical review → Mechanically answering the same questions everyone is tired about
Feature factory teams → The art of creating double the features nobody needs
Now, let’s take a few minutes to go in-depth.
1. Product Backlog = Stakeholders’ Wish-list
How Product Owners manage the Product Backlog reveals a large portion of how Agile the organization is. However, most of the time, the Product Backlog expresses the wishes of stakeholders instead of the needs of end-users. The following traits help you identify when your backlog became a wish list:
Massive Product Backlog (hundreds or thousands of items)
Everything can go into the Product Backlog (no criteria, no Product Goal)
Backlog Items have eternal life. Once in, they never go out (deleting items cause conflicts)
Precise requirements to implement instead of problems to solve (wishes vs. needs).
When the focus is pleasing stakeholders, generating value becomes just a dream.
2. Sprint Planning = Feature Planning
How do you initiate your Sprint Planning? Do you first come up with a goal to pursue, or do you define a set of tasks to deliver?
Planning the Sprint can be either exciting or draining. Teams often use Sprints to define what they will deliver for the next cycle instead of agreeing on what to achieve during this time. However, this is far from doing Scrum. Here are some signs of misusing Sprint Planning: