Scrum alienates the world of Product Management
Are Scrum and Product Management an unhappy marriage? Here are 3 things which should be changed in Scrum to improve the relationship.
I’ve been working with Scrum for around 7 years. Even though Scrum is extremely popular, the number of Scrum critics is growing. This may be partly explained by the increasing adoption of Scrum. I often read stories where people are miserable with Scrum and become much happier after switching to Kanban, Shape Up, or another approach.
Over the years, the critics are growing in quantity, and opponents of Scrum are becoming more vocal. Given the increased unhappiness I’m seeing in posts about Scrum, I feel there is something there: Scrum can do better.
Here are 5 examples of Scrum criticism that effortlessly racked up more than 10.000 claps together, but keep in mind it is easy to find more examples:
The common thread in all these articles is that people are unhappy and feel constrained by Scrum. Scrum locks people in a bureaucratic way of working they dislike. For a framework that is supposed to help empower people to discover better ways of working, reading these articles makes me sad.
After reading many of these articles, and even writing a few rebuttals, I found it interesting to reflect on what I would change if I were allowed to make any changes to the Scrum Guide.
This post explores what Scrum can do improve, based on the hundreds of articles I read and review.
1. Make the importance of Product Management more evident in the Scrum Guide
The word Product Management is mentioned exactly once in the Scrum Guide, in the following paragraph:
product management
In articles criticizing Scrum, The Product Owner often gets reduced to a Backlog or Ticket Owner. Scaling frameworks like SAFe act like you need a separate Product Manager job to deliver value. I also read a lot of books on Product Management, and most of these experts aren’t big fans of Scrum at all.
If you go to a Product Management conference, rarely anybody talks about Scrum. When I get invited to speak at Product Management conferences, they lose interest if I tell them Scrum will play a central role in my talk. Why is this the case? If Scrum is really something that helps to deliver valuable products, why are the people who care most about delivering value not talking or caring about Scrum?
The only thing I can conclude is that the worlds of Product Management and Scrum are severely disconnected. It even seems like they are at odds with each other.
A lot of this confusion is caused by the fact that it is never stated clearly what the relationship is between Scrum and Product Management. I believe the essential position of Product Management in Scrum should be stated more clearly. Without a Product Owner with solid Product Management practices, Scrum can only optimize for an efficient Feature Factory. Scrum alone cannot deliver on its promise of delivering ‘Products of the highest possible value’.
I wonder why the position of Product Management in Scrum is so vague. Is it because the authors want to keep the Scrum Guide generic and tailored towards solving complex problems, regardless of whether you’re building a product or not? The title of Product Owner is extremely confusing as well. Why not call it a Product Manager? To kill the boring and never-ending ‘Product Manager vs. Product Owner’ discussion completely?
Historically speaking, the ‘Owner’ part was invented to indicate it is a position with way more responsibility than a ‘regular’ Product Manager. The Product Owner is more similar in terms of responsibility to a Chief Product Officer or VP of Product role, than a Product Manager role. However, since this is never clearly stated anywhere, many people degrade the Product Owner role to a position of far less responsibility.
The link between Product Management and Scrum, and the role of the Product Owner in supplying Product Management expertise needs to be clearer. Now it leaves the door open for people to claim that Product Owners are second-rate Product Managers and that Scrum isn’t suited to build valuable products as it excludes Product Management. This is a shame, but it can easily be rectified. It would also immediately make the Product Management separation that SAFe proposes nonsensical.
An interesting snippet Harry S Long made me aware of, present in the first version of the Scrum Guide:
For commercial development, the Product Owner may be the product manager. For in-house development efforts, the Product Owner could be the user department manager. — Scrum Guide v1, 2010
This paragraph clearly states there is a relationship between the Product Owner and Product Management. In later versions of the Scrum Guide, this connection was removed. The current Scrum Guide (version 2017) indicates the necessity of Product Management practices in a single sentence, but it is implicit and vague who should provide this expertise. To me, it is obvious that it must be the Product Owner, but it isn’t as apparent to others.
I want to stress that I am aware that Scrum.org offers many Product Owner and UX certifications. By following these courses, the confusion will definitely be removed. However, I believe the Scrum Guide should be clear enough to stand on its own, without requiring you to follow additional training to understand the fundamentals.
Recommendations:
Change the Product Owner title to something else that people take more seriously, and is aligned with the world of Product Management. Scrum is alienating Product Management practitioners by clinging to the Product Owner title. In practice, a Product Owner is perceived as having less responsibility than a Product Manager. Clearly the name isn’t working and has the opposite effect it was intended to have.
Underline that Product Ownership and Product Management are one and the same. By being more inclusive of Product Management, the door will be closed to weird things like SAFe introducing a separate Product Management role and people claiming Product Owners are just ticket pushers.
Product Management and its essential role in delivering products of the highest possible value should be more clearly stated in the Scrum Guide, including who is responsible for providing this knowledge.
2. Be even more explicit about what it means that Scrum is a process framework
Scrum is a process framework. I never heard about process frameworks before reading the Scrum guide. I still believe the meaning of the term process framework is a significant source of confusion. It should be more clearly stated that Scrum is purposefully incomplete and won’t help you deliver great products if you don’t add your own signature to it.
Scrum will help you show what is going on, but it won’t tell you exactly what to do. Scrum provides a light-weight process framework that can help you to discover the full-blown process you need to deliver value.
I believe the main reason this is not mentioned explicitly is because it may create the impression that Scrum is of lesser value. You can’t deliver great products with just Scrum, why bother using it? From a marketing perspective, it is better to position Scrum as a silver bullet that helps to deliver products of the highest possible value. But if Scrum as a process framework only succeeds if teams are able to figure out better ways of working together, this should warrant more of an explanation than is currently present in the Scrum Guide.
The truth is that people play a bigger role in the success of Scrum than the process framework itself. The process framework is there to enable people to make the right decisions. Without people capable of enriching and adding to Scrum, Scrum is toothless and unable to make a difference in your company.
Recommendations:
Elaborate more on what it means that Scrum is a process framework and the important role of the people to make Scrum work. People now often claim Scrum does or doesn’t do something, and this often stems from the confusion over what Scrum provides. The Scrum Guide should be even more explicit about what it does and doesn’t offer.
State more clearly that the purpose of the process framework is to help you create your own way of working. If Scrum doesn’t fundamentally change how you work, it can’t deliver the results it promises.
3. Scrum should focus less on delivery of features
If you reduce Scrum to its essence, it would be to deliver a valuable product increment that is potentially releasable at the end of the Sprint. The only problem is the word ‘valuable’. How does Scrum ensure you’re delivering value to your customers and the business?
Scrum is extremely non-prescriptive towards how you deliver value. The position of Product Management, and how it helps to deliver value within the framework, is unclear. Let’s contrast this to the delivery of features, which Scrum is extremely prescriptive when it comes to delivering something. That’s why four out of the five Scrum events — Sprint, Sprint Planning, Daily Scrum, and Sprint Review — all have a primary focus on delivery.
But is the biggest challenge in software development today really the delivery of features? Maybe back when Scrum was invented, the delivery process was the main challenge, but we’ve now entered a different era. How do we know what we delivered makes a difference to the customers? How do we increase confidence that what we are building is valuable, before we start coding? How do you make sure that what you’ve released is valuable to your customers?
All these questions are unanswered by Scrum. Scrum practitioners would argue that this is intentional. These questions fall outside the purview of the process framework, and you need to figure it out yourself.
As a result, if organizations do Scrum and nothing more, the main focus is on delivering features. The Scrum Guide should state more clearly what you need to add to deliver value. Scrum doesn’t need to provide the answers but more clearly indicate what it doesn’t provide, and you need to add yourself. Otherwise, organizations may operate under the assumption that Scrum is good enough to deliver value, and it simply isn’t.
Many of the rules present in Scrum are there to support delivering a Product Increment at the end of the Sprint. But on the topic of what you need to do before you start building something, or after you’ve built something, the Scrum Guide is surprisingly silent. Because these two elements are essential to delivering value, it should be at least more transparent that you need to add these things yourself.
Recommendation:
Make more evident in the Scrum guide, that even though the goal of the Sprint is to deliver a Product Increment, it does not mean the Scrum Team only focuses on delivering functionality during the Sprint. Discovery and Validation are important steps that the Scrum Team should spend time on as well.
Scrum neglects Product Management, it’s time to bring it back!
All three things I would change are closely related to each other, they are all related to the field of Product Management. If you read articles criticizing Scrum, the main criticism is that when you do Scrum, the focus shifts to ‘Deliver, deliver, deliver’. I believe we can fix this misconception, by making the crucial position of Product Management in Scrum more clear.
Without solid Product Management practices, Scrum inevitably becomes a Feature Factory. If we all agree this is the case, why not make the significance of Product Management to delivering products of the highest possible value even more apparent?
I understand we want to leave it up to the people to figure out how they want to work, but at least Scrum should be more explicit about what it doesn’t provide, and what you need to add. Many people become disillusioned with Scrum because they believe Scrum can provide answers it was never meant to provide.
If the problem is that Ken Schwaber and Jeff Sutherland want to keep Scrum generic towards solving complex problems, there is another way to solve it. We already have a Kanban Guide for Scrum teams. A great suggestion from Alex Ballarín is to have a Product Management Guide for Scrum Teams. Scrum is kept generic on purpose, but if you do work on a product, the Product Management Guide for Scrum Teams can provide additional clarity in a product-specific context.
This way, you have the best of both worlds: a Scrum guide that is generic and simple enough to be applicable to solving all kinds of complex problems, yet you also provide clarity on how to how to use Scrum when you want to ‘deliver products of the highest possible value’.
Product Ownership and Product Management seem like disparate worlds. It’s time to bring these worlds back together. Let’s move Product Management back to the forefront of Scrum, instead of having it hide in the shadows.