To all Scrum Masters: please step up your game
A Product Owner’s perspective on what Scrum Masters can do better
Dear Scrum Masters,
Now that I’ve got your attention, I apologize for the spicy title. To be fair, you’ve been writing a lot of juicy articles on how we as Product Owners can do better. Recent ones that come to mind are ‘4 ways a Product Owner can destroy a Scrum Team’ and ‘A letter from a fake Product Owner’. But there are many more examples.
If you dish out, you should be able to receive as well. I decided to list the most important things Scrum Masters can do better from the perspective of a Product Owner. I promise to be more gentle and keep it constructive from now on.
So with that being said, let’s get started!
1. Get the whole team to obsess over delivering value
As a Product Owner, I obsess on building the right thing. I want to deliver as much value as possible to our customers and the business. I expect Scrum Masters to help make everyone care about delivering value as much as I do.
We’re not here to deliver features. I don’t care about increasing our velocity or increasing our completion rate. I don’t give a damn about leveling up in our Agile maturity model. Whoop-de-fucking-do!
We’re here to make life better for customers of our product, while making money.
Scrum Masters mainly fuss about building the thing right. Scrum Masters will happily talk about introducing:
Test Driven Development
Acceptance Test Driven Development or Behavior Driven Development
Domain Driven Design
Definition of Ready
Pair Programming
Swarming
While these practices can be useful, they mainly help building the thing right or speeding up time-to-market. If we consistently build the wrong things right with a fast time-to-market, then we will be out of business in no time. We would all lose our jobs, no longer able to build cool things.
Imagine we build the right thing wrong. We still have the opportunity to make it right later, even though it would be more costly. But if we know we built something valuable, then that is time I will happily spend. If you build the wrong thing right, then you wasted a lot of time polishing something that will be discarded.
If we can build the right thing in the right way, then of course that’s preferred. I just feel that with most Scrum Masters the balance is off. There is too much focus on building the thing right. Let’s at least have the same amount of worry and energy for building the right thing.
It all starts with delivering value. If what we deliver isn’t valuable, then it makes no sense to increase the quality or improve the time-to-market. The best thing would be to never have delivered it at all.
2. Help your teams to be flexible
Scrum has a bad rap among many Product Managers, because of all the rules and bureaucracy that can get introduced. Rules and bureaucracy slow the delivery of value down and we care about that a lot. When you’re being difficult and waving your wand of bureaucracy, please remember the following sentence in the Scrum Guide:
The individual Scrum Team is highly flexible and adaptive. — Scrum Guide
You can’t adapt if you’re not flexible. Adaptation is the core of Scrum as a process framework. The following situations are perfectly fine for a Scrum Team and can help deliver more value:
To work without a Definition of Ready.
Making changes during the Sprint. As long as we don’t endanger the Sprint Goal, changes are welcome. The Scrum Team commits to meeting the Sprint Goal. Changes in Sprint Backlog are up to Development Team, but that does not mean the PO cannot (re)negotiate changes.
To add something to the Sprint that did not pass through refinement. If what needs to happen is clear to everyone and the team believes it can fit in the Sprint without putting the Sprint Goal at risk, then go for it!
Definition of Ready, not allowing any changes during the Sprint and forcing refinement for every Sprint Backlog Item are working agreements. These working agreements are not part of Scrum. You need to carefully weigh if they help deliver value or obstruct the delivery of value.
In my experience, all these working agreements can obstruct the delivery of value, as it’s okay for details of the Sprint Backlog to emerge during the Sprint. A Sprint Backlog Item needs to be clear enough so you can decide whether it fits in a Sprint. Nothing more.
Get developers to talk directly to other developers to figure out details. Even better, get them to talk to business people and customers. Let your team collaborate directly with others to resolve unclarities. Instead of coming up with rules that allow you to throw things back over the fence.
Many teams are switching from Scrum to Kanban. There are plenty of articles about teams becoming much happier after doing so. This is not the fault of Scrum, it reflects the amount of dogmatic and bureaucratic Scrum Masters. Scrum is supposed to be flexible and adaptive, that’s why it is a process framework and not a process.
When you read stories about teams that switch to Kanban, you discover that these Scrum Teams were burdened with self-imposed and unnecessary bureaucracy. They got tired of it and decided to break free by using Kanban.
Scrum Masters: try to keep it light and flexible. Additional rules should only be added if they really add value. You are not there to keep yourself and the team busy, but to help deliver more valuable products. Being flexible is necessary for optimal collaboration, so don’t throw that away for the wrong reasons.
3. Scrum isn’t about doing Scrum, it’s about delivering more value
Scrum Masters just can’t seem to stop talking about Scrum. I’m not that interested in Scrum. I won’t be persuaded by you telling me we need to do it a certain way because the Scrum Guide says so. There are many different approaches you can use to build products successfully. Scrum may be one of the best ones, but that does not mean we need to be overzealous about it.
If you want to convince me to work a certain way, explain to me how it will help us deliver more value. Just saying it makes us better at Scrum won’t cut it. Scrum is not an end goal by itself. Tell me how it will help us reach the business goals of the organisation.
Scrum is a process framework and it provides a foundation to discover the real working process. Scrum promises the following:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Delivering products of the highest possible value is the end goal. That’s what we should spend most of our time talking about, instead of how we can do Scrum better.
We can keep talking about the foundation all day long, but at some point we need to start building the house on top of that foundation. Because that’s when value actually gets delivered.
At the end of the day, if we are following Scrum by the letter but not delivering products of the highest possible value, then we’re not really doing Scrum yet. Let’s use Scrum to get there. We should stop staring at the Scrum canvas and philosophizing about the framework. Let’s start drawing on the canvas!
4. Don’t mother your Scrum Teams
Whenever I want to interact with one of our Development Teams as a Product Owner, I shouldn’t need to go through you. You are welcome to join to make sure our interactions are helpful, but introducing yourself as a middleman is a bad idea.
It’s not your job to be their gatekeeper. Unless they are incessantly disturbed and forms an impediment to the delivery of value. It’s your job to help the team mature so they can protect themselves.
You should get your self-organizing Scrum Team to a place where they can hold their own without you holding their hand. If you keep treating your team as children, they will always need parental guidance.
5. Focus less on the team and more on the organisation as your team matures
Many Scrum Masters seem stuck in their comfort zone: introducing better retrospectives, doing cool things with liberating structures or doing some refinements with Domain Driven Design. You find a way to fill your time. But do all these things really add value to the business?
At some point you need to stop focusing so much on the team and direct your efforts to transforming the organisation to optimize the delivery of value. As an example, convincing our management to move from feature roadmaps with specific timelines to a goal-based roadmaps with fuzzier timelines.
I know it will be hard and scary, but you will learn a lot. And you will be able to deliver a lot more value by making the organisation work better, rather than just making a single Scrum Team perform better.
I understand it’s difficult to let your team go, but at some point they don’t need you as much and that’s fine. After your team spreads their wings, you should do so as well. You will be much more useful by helping the organisation grow in the realm of value delivery with Scrum.
Scrum Masters: please take a look in the mirror
These are the 5 biggest pain points I’ve experienced when working with Scrum Masters. If you agree with me that these are important, then look into the mirror and ponder if you can do better on any of these points.
If you remember five things after reading this article it should be the following:
We all should care about value just as much as Product Owners do. It’s what allows us to keep on Scrumming together.
Scrum is not the goal, delivering products of the highest possible value is.
Are all rules you are introducing on top of Scrum helping to add value, or are they just slowing us down from reaching our goals together? Flexibility is necessary to adapt to changes and to succeed with a process framework.
Avoid being a gatekeeper for your team. Get them to a place where you don’t need to hold their hand all the time.
Focus more on transforming the organisation, after your team can hold their own. Leave the comfort of your team and spread your wings to the organisation. That’s where ultimately the biggest wins can be made.