Why Scrum doesn’t kill your product — you do
Why Scrum doesn’t kill your product — you do
Scrum doesn’t tell you what to do, it shows what is going on
Henry Latham wrote an article where he claims Scrum is killing your product. I disagreed with his article, as none of his arguments are rooted in how Scrum works. I decided to write a rebuttal, as it may help others better understand how Scrum is supposed to work.
I do want to stress I’ve written articles in the past where I’ve criticized Scrum. I’m not writing this because I’m a fanboy, I just want to rectify all the Scrum misconceptions present in the original article.
Scrum does have a problem. Many people seem to not get it, yet they still believe they do. It’s something that needs to be addressed, hopefully in a future version of the Scrum Guide. The Scrum Guide should be more explicit and clear, instead of requiring you to read between the lines to catch the most important points. But I digress.
Let’s start to dissect the different arguments that are used to back-up the claim that Scrum kills your product. I hope it will also provide clarity on how Scrum is supposed to work. I added many references if you want to learn more and escape the imaginary walls of a bad Scrum implementation.
Argument #1: Scrum isn’t Agile
Scrum is considered an “agile methodology”, as it is a framework for developing software in adherence to these Agile principles…
… In theory.
Scrum is older than Agile and is a parent of the Agile manifesto. Claiming that Scrum isn’t Agile, is like claiming a painting of Monet isn’t an Impressionist painting. Please brush up your knowledge on the Agile manifesto before making such bold claims.
The Agile manifesto summarizes what different Agile frameworks such as Scrum and XP have in common. You can’t use that same Agile manifesto to claim that Scrum isn’t Agile.
If you are interested in reading more about the Agile Manifesto and the relation to Scrum:
https://mdalmijn.com/5-things-i-hate-about-scrum/
Argument #2: Product Owner has a heavy focus on processes and rituals
What this tends to translate into, when a Product Owner operates in the real world, is a heavy focus on processes & rituals. Things like:
1. Creating an organised backlog
2. Writing clear user stories
3. Planning how many tickets will be completed each sprint
4. Running retrospectives & daily standups
For ‘Creating an organised backlog’ and ‘Writing clear user stories’ the Product Owner is accountable that it happens. However, anybody on the Scrum Team can create Product Backlog Items or write User Stories. In fact, even User Stories are optional.
‘Planning how many tickets will be completed each Sprint’ is not up to the Product Owner at all. The Development Team decides how much work they pick up. Here’s how it is phrased in the Scrum Guide:
The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment. — Scrum Guide, Nov 2017
‘Running retrospectives & Daily standups’, the Scrum Master is accountable that it happens, but (s)he doesn’t have to run these meetings. 4 out of 4 points are factually incorrect.
Argument #3: Product Owners are internal-facing and don’t talk to customers
In reality, however, how is an internal-facing Product Owner — one that rarely speaks to the customer — meant to represent the customer?
The author makes a segue into SAFe, where Product Managers and Product Owners are separate roles, and then uses this to claim that this is how Scrum works as well. This conclusion is incorrect. In Scrum, you just have a Product Owner, and there is no separate Product Management responsibility.
Scrum’s person with Product Management expertise is the Product Owner. The Product Owner can talk to customers and does not have to be internal-facing at all. It’s up to you to decide! The beauty of Scrum is that it’s a process framework, which I will circle back to at the end of this article.
Further reading:
Product Manager vs. Product Owner
Argument #4: Scrum focuses on output
Scrum does not say “only focus on output”, but, unfortunately, humans will optimise for what they measure.
If you worry about story points & hitting your estimations, that’s what is going to consume your attention. That is what you and your team will optimise for.
Story Points are not part of Scrum, and hitting your estimations is never the goal. The team commits to a Sprint Goal every Sprint. The Sprint Goal is the intended objective of the Sprint, similar to the Commander’s Intent of a mission. The Sprint focuses on a clear outcome, not on an output.
In short: Scrum does not focus on hitting estimations, but on achieving a clear objective every Sprint. The outcome is more important than the output, and meeting the objective is more important than following the plan.
Further reading:
Argument #5: The Product Owner isn’t a Product Manager
This is possibly the most fundamental lesson to learn in this programme:
how quickly can we build these features?
why are we building these features in the first place?
This misunderstanding is rooted in the incorrect conflation of Scrum and SAFe. In Scrum, the Product Owner is an expert in Product Management. Without this expert in Product Management, Scrum indeed risks becoming a Feature Factory.
Scrum leaves the important parts for you to figure out
The biggest misconception that permeates the original article is that Scrum claims to be enough to build great products. This is absolutely untrue!
The single most misunderstood fact about Scrum is that it is incomplete by design. Scrum doesn’t want to tell you everything you should be doing, as it believes this is impossible to do. The point of the empirical foundation of Scrum is that you are empowered to create your own, better way of working that fits your context, better than anyone else can do for you.
Scrum dictates little, which is precisely why there is so much room for misunderstanding and screwed up interpretations of Scrum. Scrum is ultimately about people. If those people are incapable or unwilling to figure out their own preferred way of working, Scrum is guaranteed to fail.
Is that the fault of Scrum, or the people that decide to apply it a certain way?
If you want to read more about the philosophy behind Scrum’s process framework approach:
https://www.mdalmijn.com/scrum-is-about-inventing-your-own-rules/
Scrum doesn’t kill your product, people do. Henry Latham: when you do Scrum, all your Product Management practices are welcome. Here’s how it is phrased in the Scrum Guide:
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
If your organisation doesn’t apply your Product Management practices in Scrum, you are the only one to blame. We can agree on one thing: if you do Scrum, but nothing more, Scrum is guaranteed to kill your product.
But then you’re missing the point of Scrum entirely.