Why Scrum Is Killing Your Product

Scrum is, as Scrum.org proudly points out, the “de-facto standard for how teams deliver software”.

It is blindly followed by 12m+ adherents on a daily basis, but where did it all start? And why is it potentially preventing your product from achieving Product-Market Fit?

For those new to product management, a little bit of background on Scrum:

In the early 2000’s, the concept of “Agile software development” — usually just termed Agile — emerged as a response to the traditional approach to software development, where features were defined, documented, then delivered months — or years — later looking nothing like what was planned.

It was a mess, with developers sitting — frustrated — at the end of the factory line.

In 2001, a group of developers got together to determine how to make software better, coming up with 4 key principles outlined in The Agile Manifesto:

What did this all mean? Essentially, the Agile Manifesto was a set of principles — a philosophy of sorts — to help guide teams.

Individuals and interactions over processes and tools so that teams & different stakeholders prioritised collaboration & communication.

Working software over comprehensive documentation to focus on delivery — actually shipping software quickly to customers.

Customer collaboration over contract negotiation to ensure that teams were speaking to the customer & understanding their problems & frustrations, rather than just mapping out solutions managers had come up with themselves.

Responding to change over following a plan — self-explanatory.

Scrum is considered an “agile methodology”, as it is a framework for developing software in adherence to these Agile principles…

… In theory.

Scrum is focused around defining very specific roles within the team & planning software delivery in 1–2 week sprints, and is now, as Scrum.org points out, the “de-facto standard for how teams deliver software”.

The Product Owner

Scrum is also where the concept of a Product Owner came from. A person who is a proxy for the customer — who represents the customer — and passes down requirements to developers.

The purpose of many PO certifications, where people “become a Product Owner” over an over-priced, 2-day workshop is to, according to the Certified Scrum Product Owner Certification by Scrum Alliance,

“Teach that the role of the Product Owner is typically played by the customer, or customer representative, such as a product manager.”

Specifically, their role covers three main areas of responsibility:

• Define the product backlog and create actionable user stories for the development teams i.e. defining what might be build
• Groom and prioritise the work in the backlog i.e. decide what will be built
• Accept the completed user stories to make sure the work fulfils the criteria i.e. test that what should have been built it was, in fact, built

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

What Scrum fails to focus on in the real world, is:

Why are we doing all these rituals in the first place? What are they in service of? And why does that matter?

Does an organised backlog or do well-written user stories matter if the things in the backlog are unlikely to deliver value for the customer?

Does completing lots of features matter if they don’t deliver value? Or if we have no idea what the impact of those features was on the customer and the business?

Is a daily standup or retrospective even valuable if there is no deep analysis of what we are building and, more importantly, why, instead just a focus on how to build more features faster?

Particularly in a SAFe environment, in theory Product Managers are meant to manage Product Owners & do all of that strategic & discovery work themselves:

Speaking to customers, defining requirements & scope, determining what might be most valuable to build for the customer & for the business.

In reality, however, how is an internal-facing Product Owner — one that rarely speaks to the customer — meant to represent the customer?

They have no context, so they inevitably just accept tasks that come their way, organise them into a neat backlog, write out detailed user stories, then just get their development team to ship those features as quickly as possible, testing everything works on the way out, with no thought about the impact of those features once released.

Furthermore, they are even incentivised to make sure tickets are defined & completed quickly by their management team.

Although in theory meant to be speaking to customers up to half of their time, according to Scrum Inc, this is simply never the case in practice from my experience.

(Even amongst Product Managers, 80% “say they don’t talk to their customers enough yet they report that their best sources of product ideas are direct customer feedback and market research.”, according to a recent study of 550 product managers by Alpha for the 2020 Product Management Insights Report ).

Ultimately we always come back to the same fundamental flaw with Scrum:

In the words of Melissa Perri, CEO of ProdUX & author of Escaping The Build Trap:

“How do we know we are building the right thing?”

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.

And that is the core critique of Scrum as it is practiced:

That it focuses a product team’s attention so heavily on delivery — on building lots of features quickly & efficiently — that teams fail to focus on spending time to discover what the right thing to build is.

And considering — according to one study conducted by Microsoft — up to 50–70% of the features we realise have zero impact — or even a negative impact — on our key customer & business metrics, this means we are wasting MOST of our time just working on things that are creating zero value.

Scrum can be an important part of your product toolkit — it is, clearly, important to get things done efficiently — but it is just one tool amongst many to help you deliver a high-value product.

The Product Manager

This is possible the most fundamental lesson to learn in this programme:

A Product Owner is focused on output i.e. how quickly can we build these features?

Product Management, on the other hand, is focused on outcomes i.e. why are we building these features in the first place?

A good product manager prioritises against clear outcome-orientated goals:

What are we trying to achieve? Why? And how can we experiment quickly to achieve that goal?

A good Product Manager focuses on how to discover & validate customer & business value, using a toolkit of different processes & tactics as needed to ensure that the product will succeed in the marketplace.

A product manager essentially deals with mitigating uncertainty. Specifically:

1. Value risk
2. Feasibility risk
3. Usability risk

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 — but more on that next week.