Revisiting: Why Scrum is the Wrong Way to Build Software Pt.1

Reviewing Item #1

Image by Gerd Altmann from Pixabay

Why Scrum is the Wrong Way to Build Software is a listicle— fourteen items with minimal explanation. Whenever Scrum caused me pain (oh, the pain) at work, I tried to pinpoint exactly what was hurting and jot it down. These scribbles became the basis for why I believed Scrum was the wrong way to build software.

I used my list to try and convince management that Scrum was a bad idea, that we should try something else. They were unconvinced. We did Scrum anyway. So I posted my list to Medium. From the comments (supporting both sides of the argument), I learned just how contentious this topic was (and still is). Team Scrum and Team Scrum-is-dumb went at each other’s throats — no one making any concessions.

After nearly a decade of additional ‘Scrumming’, and with a mountain of comments directly on my post as well as on its cross-posting to reddit, I think it’s time for a second look at my list. Is each point still valid? Have any been resolved? Did any of them represent a misunderstanding of Scrum on my part? Let’s take a look:

1. Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.

Was I right about this? Let’s consult the Scrum manual for the definition, duties, and authority of a Product Owner. Of key importance is how the Product Owner relates to the Product Backlog:

…

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.

…

For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.

The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

So, directly from the Scum Guide, there can be no misunderstanding that the Product Owner is the sole authority over (1) the content and (2) the ordering of the Product Backlog. This is important. If you control the list of things to build and the order in which to build them, then I think it’s fair to say all product decision authority rests with you. What else is there left to control?

If you still have doubts about Scrum’s intention, look at the strong language around this topic:

“…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.”

… the Dear Leader … I mean … the Product Owner will see you now.

The only thing left to ask is whether it’s fair to say that “Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction”?

I guess this is more subjective. All Product Owners are different. While some may be happy to listen without grovelling, others may not listen at all, grovelling included. For some a small bribe may be sufficient. So perhaps I should have said:

1. Because all product decision authority rests with the “Product Owner”, engineers must rely solely on persuasion to affect product direction.

“Does that seem more fair?” I ask to all the people who commented before, that will probably never read this? The grovelling thing was kind of snarky, so I’ll take that out. But, nevertheless, is it wise for a process to appoint dictators, and rely on their benevolence to make governments (or work processes) ethically resilient?

If I learned anything in middle school social studies, it’s that a governing model should protect people from abuse, not expect leaders to do the right thing in spite of their power. Remember separation of powers, checks and balances, term limits, elections, all that stuff?

And if I learned anything from Lord of the Rings, it’s that the ring of power could only be carried by the humblest of hobbits. It corrupted everyone else that tried. And in the end, even the hobbits could not longer withstand its allure, and Middle-earth was only saved because a greedy little gollum bit the ring off of Frodo’s finger and accidentally fell into Mt. Doom.

If you’re familiar with the Stanford Prison Experiment, you know it doesn’t take much power for people to start taking themselves too seriously. In this case, all it took was telling a few participants that they have been selected as pretend prison guards, and after six days they had become so brutally oppressive to the fake prison inmates that the experiment had to be stopped before things went too far.

So Item #1 really ought to read:

1. Because all product decision authority rests with the “Product Owner”, engineers must rely solely on persuasion to affect product direction — and we all know how that is going to go.

But, the real question is: Does Scrum intend for engineers (or anyone else for that matter) to be involved in product decisions? Or does it assume that engineers should stay focused merely on building what product professionals come up with?

Some organizations think this way — maybe the authors of Scrum do as well. “Product is concerned with what to build and engineering is concerned with how to build it,” is a phrase I hear all the time, even though I hate it.

Progressive organizations flip the script on this outdated mentality. InThe Other Road Ahead, Paul Graham gives advice to engineers doing startups. The best companies these days function like aggregates of startups which makes this advice all the more relevant:

Don't listen to marketing people or designers or product managers just because of their job titles. If they have good ideas, use them, but it's up to you to decide; software has to be designed by hackers who understand design, not designers who know a little about software.

https://paulgraham.com/road.html

Let that sink in for a minute. Engineers making decisions, taking advice from designers and product managers, but making their own final decisions. Can you dig it?

Conclusion

Scrum is either naive about Product Owners sharing their power, or they don’t intend for anyone else to participate in product decisions and consider this to be the sole domain of the product organization. Either way, they have it wrong.

But Wait, There’s More

As I think more about this, I believe we are still not discussing the biggest problem with Scrum Product Owners and Product Backlogs. The main problem I have experienced is that every company I know of is terrible at distinguishing between the Product Backlog and the engineering backlog. By terrible, I mean they don’t even try. It’s all the same backlog. And while I can live with a Product Owner telling me to create the ‘Save’ button before the ‘Load’ button, I cannot deal with being told to create function A before function B or being told that an important refactor has been deprioritized. This isn’t a Product Owner’s specialty, and frankly it isn’t any of their business. Product Owners can place their orders and even tell me what should come out first, but they need to stay far away from the kitchen, or I am packing up my knives and going home. “Come on little ratatouille! Let’s get out of here!”

You see, when the product backlog becomes the everything backlog, which it always does, the Product Owner is not just deciding about feature work, they are deciding about engineering work as well — any task that goes in the system (and if you try to avoid putting engineering tasks into the system, your Product Owner and Scrum Master are sure to pester you with backlog grooming meetings until you do). When Product Owners become engineering managers, engineers become ticket takers.

I want to be fair to the Scrum advocates though, there is a way to address this if people bother to read the Scrum Guide:

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

So, if you want to, you can decide to be disciplined about keeping engineering work out of the Product Backlog. The Scrum Guide allows engineers to use any method or tool they wish to track their own work. I would suggest they keep their task documentation far away and under lock and key — accessible only to developers that swear an oath to keep it secret.

And in my own defense, it’s always the Scrum Master and Product Owner who pester everyone to put engineering work in the backlog. So, what do you do when your Scrum experts (always!) get it wrong? Aren’t they suppose to be the authority on the process? Do they read the Scrum Guide? And why are all the Scrum Masters coming out of certificate training with the wrong understanding of their own process? It’s exactly this kind of lunacy that makes talking to Scrum zealots so infuriating. When they say, “You’re doing it wrong,” they are actually right a lot of the time. But that doesn’t change the fact that 99% of organizations are doing it wrong and our lived experience in Scrum hell is not improving.

Deep breaths, deep breaths…

Ok, I am just going in circles on this now, so I think that’s probably enough. Here is my final edit of revised item #1:

1. Because all product decision authority rests with the “Product Owner”, engineers must rely solely on persuasion to affect product direction — and we all know how that is going to go.

P.S. Whatever you do, never, never, never put engineering work in the Product Backlog, or the Product Owner will have all decision authority over that work as well.

Real Conclusion

In summary, Scrum is wrong to force companies to exclude engineers from product decisions. But I admit that a lot of the crap that people suffer when doing Scrum comes from implementing crap Scrum, including the common (like every place I have ever worked or heard of) practice of mixing engineering work with the Product Backlog.

Phew, that was a lot! Are we only through the first point? This is going to be a series I think. Let’s make this Part 1. Stay tuned for Part 2 in the near future.