Is Agile Impoverishing Product Culture?
Each time someone mentions “scrum” as a way of delivering value, a product manager dies
I don’t like the agile community… there, I said it. Stone me.
Of course, I don’t have a problem with agility itself. It’s not that I prefer waterfall or anything. I also don’t dislike agile coaches or scrum masters across the board. They are important figures depending on the context they are in.
The thing I just can’t stand is the gospel of agile.
There are tons of articles on this very own platform portraying scrum as this silver bullet that, if correctly implemented, means you’ll be a top-tier tech company.
Something went wrong? You are delivering the same garbage as before but now your team hates working even more? Meh… that’s because you haven’t implemented it right.
It’s like astrology: You are Libra, but you are not allergic to peanuts? That’s because your moon is in Taurus. It’s pseudoscience. Anything goes as long as your framework remains correct. It can adapt to everything so that it’s never wrong, while it’s never quite right, also.
If the snake oil sellers were isolated to their contextual domains, fine. Let them fool former PMBOK enthusiasts. The problem is that agile rooted itself so deep inside product domain that they are literally taking over, one weakminded team at a time.
This article is heavily inspired by a piece from Marty Cagan called The CSPO Pathology released in 2021. The article is a manifest against agile contamination inside the product management community. I can’t recommend you read it enough.
Why This Matters?
Frameworks are, by definition, a structural component to build on top. When you build a building, you don’t start with bricks and windows, you begin by erecting a framework of pillars and beams.
Likewise, a project framework is the foundation that enables the development of a product or service. It has fundamental importance on defining what you can do and how you do it.
Notice that I’ve chosen the word “project” on purpose. Projects are a millennia old tradition that did everything from raising the pyramids to taking humanity to the moon.
Product (with a capital P) is way newer. According to this very good article from Mind the Product, the first mention to what would be called later as product management dates from 1931. It was an open position inside Hewlett-Packard labeled as “brand-man.”
Here’s an excerpt from the article I just mentioned:
“The original product managers […] were very much a part of the Marketing function. They focused on the process of understanding the customers’ needs and finding a way to fulfill those needs using the classic marketing mix — the right Product, in the right Place, at the right Price, using the right Promotion.”
When you see a more modern definition of what a product manager does, you notice that the underlying goal of the position hasn’t changed that much. On chapter 10 from Inspired:
“…there are four key responsibilities of a strong product manager; four things that the rest of your team is counting on you to bring to the party: Deep Knowledge of the Customer[…]Deep Knowledge of the Data[…]Deep Knowledge of Your Business[…]Deep Knowledge of Your Market and Industry”
Lo and behold, being a product manager has, and has never had, nothing to do with frameworks. Product managers are not part of a fundamental structure that enables the delivery of projects. Product managers are not product owners.
The Problem of Transforming Product Managers into Product Owners
Product owners are the figures responsible for addressing “what to build” inside scrum. They collect requisites from stakeholders, organize and prioritize backlogs and share context with the engineering on what they are building through ritual meetings.
It’s a lot of work, for sure, and it’s an important one too. It’s not, however, the job of a product manager.
There is only one mention of the word “customer” inside the scrum guide, and it’s not under the product owner segment. There is no mention of the words “discovery,” “data,” “industry,” “market,” or “business.”
Before you start saying that the scrum guide is older than Product, that’s why there is no mention of those words. The current version was reviewed in 2020 — when Product was pretty common place already.
Trying to fit a product manager on the limits of a framework means you are, essentially, leaving everything that makes the role vital behind in favor of transforming it into a backlog organizer.
“Solve problems in ways our customers love, yet work for our business,” as Marty Cagan points out, is not a challenge that is addressed by scrum directly. From the Scrum guide again, the philosophy behind its value proposition is to “optimize predictability and to control risk.” That’s about delivery efficiency, not necessarily business growth.
Product management is not better than product ownership, it’s just different. Moreover, product ownership is a role, while product management is a craft. The first can be performed by anyone inside a squad if they accumulate or share responsibilities. The second, can’t.
If we don’t have product managers, just product owners, deliveries might be super predictable and safe, but they probably won’t make any customers fall in “love,” and most likely won’t “work for our business.”
A world where product owners take over product managers is a world of product mediocrity.
Why is Agile Successful in Undermining Product Culture?
The Max Planck Institute of Neurobiology is a reference research center for studies of the mind. In one of their articles, “Simplifying the world”, the opening statement reads:
“Categorization is the brain’s tool to organize nearly everything we encounter in our daily lives. Grouping information into categories simplifies our complex world and helps us to react quickly and effectively to new experiences.”
Human-beings crave for standardization. Simplifying the complex might be the single most important trait of our evolution. How do we do that, though? How do we systematically categorize and simplify very complex things?
We use frameworks!
Politics? Ideologies. Economy? Kaynes or Hayek. Psychology? There’s a school for that. Physics? Here, have a theory.
It doesn’t matter the nuances in between. If we can shove everything inside a box and get some kind of control over it, our primate brains rewards us with a rush of dopamine and we are set to move to the next problem.
Product management is, to some extent, unnatural. It’s a craft that is constantly asking you to question yourself and the people around you. It’s a discipline that embraces complexities and thrives on environments where few things are set in stone.
Again, in the words of Cagan, “Product is hard.”
Scrum charlatans take advantage of this hostile “mind environment” and kidnap product concepts for their frameworks. What was born as a tool to deliver software consistently, transformed itself on this jack of all trades that is capable of guaranteeing amazing business results “if implemented right.”
Let’s not be naive, this dispute is not about the heart and soul of the industry, its about money.
Both Scrum and product management are products on their on behalf. They are consultancy agencies, gurus and schools trying to sell to the industry the secret of growth and prosperity. Originally, there was space for everyone, but markets started to clash as product management grew in popularity.
Unfortunately, agile has a way better pitch. Between the simple and the complex, I’m not surprised that more and more people has been settling for the framework instead of pursuing the craft.
As I mentioned in my opening statement, this is not an attack on agile. On the contrary, organizations can’t do product management outside of an agile environment.
Summarizing, the problem starts and ends when agile tries to do product. It wouldn’t be acceptable for product management to influence how you calculate throughput, for example. So why the hell is scrum trying to box discovery?
Unfortunately, this is not one of those articles where I provide an alternative as a solution at the end. This is a cautionary tale, a story about the sirens cry.
So many of us submit to the oppressive rule of structure in order to comply with our stakeholders that it’s easy to forget that your value is not delivered through an organized backlog.
Results should always speak louder than adherence to process. Adapt, but never forget why your job exists in the first place: take risks, communicate well and enable the shipping of products that our customers love and make our business grow.
