Will Scrum really kill our product?

Just recently I came across this article in Medium "Why Scrum is killing your product!". It's provocative title tempted me to read it, because (a) I worked as an Agile Coach for 10+ years and Scrum was in my toolbox and (b) since beginning of July I took on the role of Product Owner in our startup thing.online and we basically practice Scrum (I like to say that we practice one-team LeSS though. And LeSS is Scrum).

The author of this article, Henry Latham, suggests at the end that, and I quote: "Therefore, Product Owner may be the role you play in a Scrum team — managing a development team & sprints to execute the work efficiently — but being a Product Manager is the overall job you fulfil to ultimately deliver customer & business value for the business." and "a Product Leader is somebody who can go beyond this, identifying opportunities to create value, telling a compelling story to get buy-in from stakeholders, then helping each product team iterate towards taking advantage of that opportunity".

So if we use Scrum and I am only a Product Owner, then we may not be able to deliver "customer & business value for our startup and I may not be able to identify opportunities that create value. I guess I need to talk to my fellow product-team members tomorrow and clarify my role with them and rename my role afterwards!

Leaving irony aside for a moment. I totally agree with Henry Latham, that way too many organizations implement cargo-cult or some other form of broken Scrum (or any other form of agile framework for that matter). And that the issues he raised can be observed in a large number of organizations out there. But can we seriously blame Scrum for that? And can we seriously believe that calling a role "Product Manager" or "Product Leader" (instead of Product Owner) or adding additional roles to Scrum (as SAFe suggests for example) is going to fix any of this!

Let's go back to the basics, the Scrum Guide. It says and I quote: "Scrum is a framework for developing, delivering, and sustaining complex products." and "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."

What does that mean? It means that Scrum doesn't give you many answers. It was constructed to help you finding the right questions to ask, so that your team or organization can find answers and improve towards better / more successful "developing, delivering and maintaining complex products."

Let's look at one of Henry Latham's examples: "How do we know we are building the right thing?" An organization that uses Scrum and doesn't recognize that they build features nobody needs, probably hasn't found a way to regularly and frequently involve their (potential) customers and users, so that they learn what their needs and desires are. 

How could the Scrum team / organization do this? They could invite customers or users to attend Sprint Reviews (or parts of it) for example; show or demonstrate them their latest Potentially Shippable Product Increment (PSPI) and get into conversations with them. Thus finding out what they really need. Or they could conduct Customer Interviews or A/B testing campaigns during a Sprint in order to find out which UX / UI variant is more appealing or useful to users for example. These are just two small examples (of many) for what a Scrum team / organization could do to find out what their customers really need.

Scrum itself doesn't include any of this explicitly, because it is up to every team or organization using Scrum to identify their own issues and experiment with their own ideas that have the potential to improve the organization's understanding of the customer's problem domain. Scrum gives us a lightweight framework that supports us to regularly improve as an organization. It is the responsibility of the people in this organization to actually improve their macro / micro structures, processes and tools.

Henry Latham also writes that, and I quote: "The Product Owner is focused on output." This may be the case for many Product Owners out there in real Scrum life. But it is not what Scrum says, and I quote the Scrum Guide again: "The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team." Pitching the Product Owner to focus on output and the Product Manager on outcome is, let's say, misleading at least. A Product Owner is responsible for the business success of his organization. That includes balancing many different interests and understandings of value. As such a Product Owner does play in the arena of product management! Only Scrum doesn't include any explicit details about how the Product Owner plays in this arena. All it says is that the results of playing in this arena shall be reflected in the Product Backlog. Again, it is the responsibility of the people in this organization to actually improve how they get to a valuable and well defined Product Backlog, not Scrum's.

In general, it is the people - and that includes leaders and all the others an organization interacts with - that need to fully own Scrum as their framework to deliver value and continuously improve as they go. Every organization that I know first hand and that successfully owned Scrum, has developed or evolved their own (flavour of) Scrum over time. And in addition they use a large repertoire of practices, techniques and tools alongside Scrum to achieve the desired outcome! 

Scrum never claimed to have all answers for all questions or problems that may arise in a product development organization. In fact, every product development organization needs to put many different values, principles, structures, processes, thinking tools and technologies to work in order to succeed. Scrum is a lightweight framework that can help your organization to get into a rhythm of delivering valuable outcome and continuously getting better as you go. Nothing more, nothing less.

So going back to my original question "Will Scrum really kill our product?" as in "if we chose Scrum, then we will most likely kill our product!".

It depends. Like any powerful tool in human history it has the potential to deliver betterment and add value to both, the developing organization and its customers / users. But the simple fact that it is people that interpret and apply Scrum, carries the risk that "Scrum done wrong" inflicts great damage and pain. I have experienced cargo-cult or broken Scrum adoptions myself (this is probably a good reason to write another article) and things can even get worse than before.

But should we stay away from Scrum or replace it with something better? Or can we adapt and improve Scrum in order to mitigate or even eliminate the risks of using Scrum - like invent "Failsafe Scrum" for example (and offer certificates for "Certified Failsafe Scrum Master" - don't get me started)?

NO, we should NOT! But why? Because in my opinion, Scrum only defines a starting point that is good enough for any organization to start with and encourages these organizations to continuously improve (towards perfection, which they will obviously never fully achieve). These organizations own Scrum! Not the Scrum Alliance or Scrum.org or any other certificate-issuing organization (I am not discounting their value though). During the process of improving their own Scrum, every organization can add "failsafe" elements, if they need or want to. Developing products is a complex undertaking. There is simply no "one size fits all" or "just add this or that bit and then it can't go wrong" solution to it. For organizations to master Scrum and mature, the option to fail (even badly) is mandatory. Only by failure can they learn and improve. If we take that element away from Scrum, then Scrum becomes worthless. Scrum, the agile framework described and maintained in the Scrum Guides, is simply good enough, as it is!