When the output is all that matters, doing REAL Scrum becomes nearly impossible.
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 teams will never reach the actual 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 itself (rules, roles, artifacts, and events) guide the interactions to play it. Yet, what matters is how we play.
Sadly, companies tend to play the game way different 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 each element of the Scrum Framework, and share what I’ve seen in the real world.
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.
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. Many times, teams 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 the Sprint Planning:
- The Sprint Goal is either absent or related to delivering all features by the end of the Sprint.
- Focus on the output instead of the outcome.
- No room for creativity. Instead of defining a problem to solve, the team must focus on implementing a set of features.
On the contrary to these points, Sprint Plannings have to answer what to achieve and why that is important. My humble opinion is:
What matters most during the Sprint Planning is setting a compelling goal to pursue! Without that, we are lost!
Daily Scrum = Daily Status Report
It’s 09:15, the Daily Scrum starts. The team looks apprehensive as the Product Owner is about to say something.
Product Owner: “John, where is my new feature? I need that today!”
John looks perplexed and says, “I couldn’t get that done because I had to support Peter with his task.”
Product Owner: “That’s not good. You should have told me that before. Now, I have a problem with my stakeholders. Can you do it today?”
John: “Maybe I can, but I need support from Julia, and she is working on the other feature you asked her to do it.”
Julia: “I can support John if it’s fine to finish my feature tomorrow by the end of the day.”
Product Owner: “You’re making my life harder. But I can handle that with my stakeholders. Now let’s get back to work!”
The Daily Scrum is a moment for developers to organize their work and get closer to the Sprint Goal. Although everyone is welcome to attend, the event belongs to developers, and any other participant should be only a listener.
The problem is that many Product Owners receive unbearable pressure from stakeholders, and often they transport the pressure to developers. And ultimately, the Daily Scrum becomes a Daily Status Report.
Sprint Review = Bi-weekly Status Report
What’s the Sprint Review? Here is what the Scrum Guide says. In bold, you can read the essential parts.
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. The Scrum Guide, November 2020
The reality of Sprint Reviews is generally different from what the Scrum Guide suggests. I’ve come across the following issues:
- Stakeholders are unwilling to attend the Sprint Review as they don’t see value in it.
- When Stakeholders attend, they barely provide feedback that helps the Scrum Team discover future adaptions.
- Often, the Sprint output relates to a bigger waterfall plan. That’s why the Sprint Review focuses on presenting the output instead of talking about how that would change the end-users lives for the better.
I’ve noticed Sprint Reviews tend to become another status report moment. A typical scenario I’ve seen is the following:
- The Product Owner opens Jira and asks each team member where they stand with the task.
- Each team member provides a detailed status report to the Product Owner on the task status.
That situation is far from the Sprint Review defined on the Scrum Guide, and yet it’s how many teams do it.
Sprint Retrospective = Mechanical Review
For me, the Sprint Retrospective is a critical moment for the Scrum Team. They have the chance to step back from the daily business and identify opportunities to become a better version of themselves. Yet, many teams don’t see value in retrospectives and often prefer skipping it. But why?
What I observed is shocking. The Scrum Team mechanically uses the retrospectives, and the event ends up with no action for the upcoming Sprint.
The retrospective often becomes a room to complain about people who are not in the room. Although the exchange may be rich, the outcome is low. For example, the Scrum Team complains DevOps team is slowing them down. When the retrospective becomes a place for complaints, the Scrum Team falls into victim mode and gives up trying to change anything because they feel powerless.
A meaningful retrospective starts with the agreed actions of the previous one, and the team navigates on what they did with them. Great retrospectives help Scrum Teams identify opportunities to become a better team!
The Scrum Team = Feature Factory
Most teams I have seen are not Scrum Teams; they are feature factory teams. It’s unfair to say we do Scrum when the focus is on maximizing the team’s output.
The incapacity of embracing the unknown blocks teams from doing Scrum.
The reality of Scrum Teams is sad when they become Feature Factory Teams; the roles shift to weird mutations. Here is what I’ve observed.
- Product Owner, the Stakeholders Pleaser: the responsibility isn’t maximizing the value but ensuring influential stakeholders get their wishes into the upcoming Sprints.
- Scrum Master, the Team’s Assistant: instead of helping the organization benefit from Scrum as defined on the Scrum Guide. Scrum Masters become a kind of assistant to the team, helping them with scheduling events, ensuring everyone has what they need to produce their features, and gatherings metrics for the management (output, story points, etc.).
- Developers, Feature Factory Workers: with a faulty Scrum in place, developers cannot bring their creativity to the game because they are trapped in a world where they only have to produce what stakeholders want. Sprint in, Sprint out, they keep the machine running. Features, features, and more features. That’s all they are allowed to do.
A Faulty Scrum Version Cannot Be Called Scrum
I don’t claim all companies should do Scrum by the book. Each company can work the way they want. However, if the game becomes mechanical and lacks the intention of improving it frequently, it’s unfair to call this faulty version Scrum. It’s frustrating to be locked in the feature factory trap; this limiting version is not Scrum. The real Scrum empowers us to figure out how to find faster ways of delivering value.
Don’t insult Scrum with a misinterpretation of it!
If you want to lock developers into a feature factory, don’t say you work with an Agile framework. Honesty helps everyone. I know many people who prefer being told what to do, and they would be happy to work in a place like that. Yet, I also know many people who cannot deal with the feature factory working style.
The real Scrum is for the brave ones. Those who have the guts to embrace the unknown!
Thanks, Maarten Dalmijn, Matt DiBerardino, Sjoerd Nijland, for helping me make this a better piece.