Scrum's "Product Owner" Problem | Hacker News Reader

Scrum's "Product Owner" Problem

rethinkingsoftware.substack.com

14 pointsaard15 comments

Open articleView on HN

>In Scrum, Product Owners have sole authority over the Product Backlog;

That first sentence was enough to stop reading

Isn't that pretty much textbook Scrum? The language in the Scrum Guide couldn't be much clearer...

"The Product Owner is also accountable for effective Product Backlog management, which includes:

- Developing and explicitly communicating the Product Goal;

- Creating and clearly communicating Product Backlog items;

- Ordering Product Backlog items; and,

- Ensuring that the Product Backlog is transparent, visible and understood. "

And if that wasn't enough...

“…the entire organization must respect their decisions.”

“The Product Owner is one person, not a committee.”

“Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”

Sounds like "sole authority" to me.

That's for people outside the Scrum team, meaning that no external stakeholder may manipulate the backlog by bypassing the POs. Internally the team must act as a cohesive unit, which means that a Scrum dev should have the same objectives as a PO, with regards to both priorities and goals. That may mean adding items in the backlog pertaining to technical debt, and so forth

Thank you for listing out the cancer that is Scrum.

Anecdotal story:

Are product owners engineers? Typically not, and this is where the problem starts for most engineering teams doing "Scrum".

I work with overzealous POs (who aren't engineers) and since they "own" the product and the backlog (as according to that definition), they own everything. Since the PO is supposed to manage the backlog, we have POs running backlog refinement sessions where the vast majority of topics and tickets being discussed are of an engineering/technical nature (lots of stuff that is periphery to the product features such as security enhancements, build pipelines, performance, code quality and tests, etc.) and since the PO "owns" it all it is their decision/opinion what counts, i.e. they pretend to be tech-leads.

I even work with a PO who insists of writing all the engineering tickets (title/description), where no engineer can understand what the ticket is about since this person simply doesn't have the ability to clearly and concisely articulate engineering tasks.

Now, obviously people will point out that this is not a problem with Scrum but a culture issue with the organisation, and I agree (my organisation has many ingrained and deeply embedded institutional dysfunctions) but the Scrum definitions aren't helping engineering teams.

As much as this comes across as an obvious strawman, it is also consistent with Scrum in practice. Scrum proponents constantly suffer from the "no true Scotsman" fallacy exactly because in practice Scrum inevitably resembles it's own strawman.

In my experience, developers are rarely any good at conceiving of the product that customers want.

This is a special skill, which requires patience with customers and users, and a keen understanding of the domain.

It is pure fantasy to expect that anyone could wave their process wand over a team and turn out a great product just because people who are good at coding try to guess at product design.

I designed a test tool that was implemented by a small team of coders. It wasn’t until half way through the project that the senior developer suddenly realized how testers would use the tool. I know this because he told me… and that’s when I discovered that he and the rest of the team had been humoring me up to that point, confused about the features I had insisted upon. I had explained the concept over and over, and they had nodded as if they understood. Imagine having to get a group like that to independently bring a product together when apparently they couldn’t or didn’t want to savor its vision?

I started my professional career as a coder in 6502 assembly, doing video games designed by my boss. I saw first hand, in game after game, that my coding skills in no way overlapped with those needed to design a good game.

I had one idea for a game (Adventure Creator for C64) and watched in wonder as he (Dale Disharoon) turned it into a playable design.

Interesting analogy but I’m not convinced it’s the best one. One might also note that in many large scale restaurants, there is in fact only a handful of chefs who determine the menu and most of the day to day is handled by cooks assigned to various specialized stations.

In my experience many software teams work exactly in this way, even if many do not. There is often one lead that drives a lot of the architectural decisions and champions things like code quality and best practices.

> One might also note that in many large scale restaurants, there is in fact only a handful of chefs who determine the menu and most of the day to day is handled by cooks assigned to various specialized stations

But those handful of chefs, are indeed, actually cooks, not? Not some person who read a book on cooking and is now telling cooks how to cook...

Yet another dig at Scrum and Agile that, in their very premise, are talking about something that is [at least supposed to be] anti-Agile and anti-Scrum.

Agile was a small manifesto that listed a set of principles, one of which was "people over processes." If the relationship between your PO and the rest of the team is not collaborative, that's not because Scrum has some dogmatic prescription somewhere in the Scrum bible that declares "though shalt grovel at the feet of your PO and accept their every command without question or suggestion"

If that's how your PO and team behaves, it's because that's how your organization set things up.

Ironically, the relationship described in the article describes "waterfall"; the very boogeyman that Scrum and Agile were a response to.

The role of PO is really just to have a final decision maker as far as how product development gets prioritized and represents THE person to ask when there are unclear product requirements. I mean, at the end of the day when you're trying to ship something, you can't always get everyone sitting down at a table to hash out how the product ought to behave, or whether or not a particular defect is severe enough to block the release.

Also as far as backlog prioritization and delegation goes, you could just as easily target the Scrum Master with the same complaints if your team has one. Although sometimes the PO and SM hats are worn by the same person ... I've seen that at a lot of companies.

I wonder if the article's author would take issue with the concept of a lead developer who has final say on what technical solutions get adopted when there are alternatives (including things like code conventions, 3rd party libraries etc.) because certain lead developers might not collaborate in the way that he thinks all should.

As I see it, whoever has the "final say" has to take the final responsibility. There is then no room for blaming anyone else. Discord arises if the developer gets criticized for the outcomes of decisions made by someone else.

> I wonder if the article's author would take issue with the concept of a lead developer who has final say on what technical solutions get adopted when there are alternatives ...

Pretty much every solution has alternatives and in the same manner that a PO would have final say over the product, a tech-lead would have final say over implementation. However, there is no concept of a tech-lead in scrum so what happens in most cases, the PO becomes the tech-lead. A recipe for a true dictatorship.

This is a pretty naive take on both product delivery and restaurants.

> <Critical take on Scrum>

That’s not real Scrum!

The author apparently doesn't think software developers are capable of talking to the product owner and influencing their decisions.

Nor, apparently, has he seen the nightmare navel gazing when software developers run wild.

Reply on news.ycombinator.com