Jun 1, 2020
Product Owners lose their job when SAFe is introduced
Let’s put an end to SAFe doublespeak: SAFe kills the Product Owner role and replaces it with Story Owners
Imagine you are working as a Product Owner for a SaaS company for many years. After a period of hyper-growth, you now are a Product Owner for around 5 Scrum Teams. You’re doing Scrum by the book: one Product, one Product Backlog, and one Product Owner. You love your job, even though it is quite stressful, and you work way too many hours. But hey, you know what you sign up for when you begin working at a start-up.
As the company grows beyond 5 Scrum Teams, scaling issues appear, and teams struggle to deliver new features. Even though there are more teams than ever, features are not released to customers any faster.
One day, your company’s CEO comes back from a day of golf with the CTO of another company. During the round of golf, your CEO has been convinced by the CTO that SAFe will solve all growing pains. As a result of their conversation, she decides to roll out SAFe at your company.
That’s the exact moment you lost your job as a Product Owner.
Your job as a Product Owner at the company is characterized by two eras:
- Before SAFe
- After SAFe
Before SAFe, even though you had to work hard, you were happy. After SAFe, your job is a mere shadow of what it was before. Out of boredom, you decide to quit and find something more challenging, fitting better with your expertise.
The Product Owner role before and after SAFe from the Scrum Guide’s perspective
Let’s compare the Product Owner role, from the Scrum Guide’s perspective before SAFe (Scrum) and after SAFe:
Scrum: The Product Owner is responsible for ensuring we build a product of the highest possible value.
SAFe: The Product Owner is no longer responsible for ensuring we build a product of the highest possible value.
Scrum: How to maximize the value is not prescribed by Scrum and can vary across organizations, Scrum teams and individuals.
SAFe: SAFe is much more prescriptive and moves the responsibility for delivering value to the Product Management Team.
Scrum: The Product Owner is the only person who is responsible for managing the Product Backlog.
SAFe: Product Backlog gets replaced with Program Backlog. Product Owners have limited say over the Program Backlog. Program Backlog gets broken down in Team Backlogs, which Product Owners are responsible for.
Scrum: Product Backlog Management Activities may be performed by the Development Team, but the Product Owner remains accountable.
SAFe: Not even the Product Owner may do Product Backlog Management anymore, so you can forget about the Development Team being involved.
In summary: before SAFe, you’re a Product Owner. After SAFe, basically every sentence written in the Scrum Guide about the Product Owner role is no longer applicable.
SAFe chops the ‘Owner’ part of the Product Owner role off and dares to still call it a Product Owner. The title ‘Story Owner’ would be far more appropriate.
So what will you be doing as a Product Owner instead after SAFe is introduced?
Product Owner —the SAFe perspective
In SAFe, the Product Owner is responsible for:
- Defining Stories and Prioritizing the Team Backlog.
- Creating acceptance tests in Behavior-Driven Development with your Development Team.
- Dependency management and planning of iterations.
- Accepting stories. This includes validating the story meets acceptance criteria, appropriate, persistent acceptance tests, and complies with the Definition of Done (DoD).
In SAFe, the Product Owner role is much smaller, and your freedom to choose how you do your job is limited. Here are some examples:
- You don’t have complete freedom on how you express your Team Backlog. You have to use Stories, Enabler Stories, and Behavior-Driven Development.
- You have to accept stories as a Product Owner. You can’t trust the team, you must check if they did their job correctly on a technical level.
- You don’t talk to customers or try to understand the market. That’s the job of the Product Manager. Just do what the Product Manager says, and all will be good.
- SAFe Product Owners operate in the solution space, not in the problem space. SAFe PO’s take features, process them and spit out Stories.
In summary, the SAFe Product Owner has a fraction of the responsibility the Scrum Product Owner has. Also, you have much less freedom over how you decide to perform these responsibilities and many more layers you need to deal with.
SAFe evicts the Product Owner and replaces it with a Story Owner
The SAFe Product Owner is a light version of a Business Analyst mixed with some planning responsibilities. At least a Business Analyst has freedom in how they express Backlog Items. With SAFe, everything is a Story. That’s why I believe Story Owner to be a much more apt name.
SAFe dares to call the role stripped of most of its responsibilities still a Product Owner. Let’s say it like it is: SAFe kills the Product Owner role. It no longer exists. Stop talking about it. The only reason the Product Owner role exists in SAFe is to be able to map it to a role from the Scrum framework. This is the excuse SAFe needs to keep on calling it a Scaling Framework for Scrum. Without a Product Owner, you can’t call it Scrum anymore.
Don’t be fooled by the SAFe doublespeak: you can call a Zebra a Peacock, but it’s still a Zebra. I’d even go one step further and say that SAFe isn’t a scaling framework, but a replacement framework (if you can even call it a framework, it is exhaustive and extremely prescriptive after all).
SAFe is a wolf in sheep’s clothing. SAFe scales Scrum by adding layers, process, rules and complexity. SAFe modifies the foundation of the Scrum framework to such an extent you no longer can call it Scrum. What makes Scrum simple and powerful gets buried by SAFe.
You can do SAFe, or you can do Scrum, but you can’t do both.
Choose wisely!
I was inspired to write this article after reading ‘SAFe Product Owner vs ‘Scrum’ Product Owner -They Are Not the Same’ by Willem-Jan Ageling. If you like this article, I can highly recommend you to read his piece to get a balanced perspective and to understand the facts supporting this article.
Do you want to write for Serious Scrum or seriously discuss Scrum?
