Weekend Reading – Improve Your Agile – not Your Scrum!

“This better way of working should always be leading, not Scrum. If your Scrum is at the forefront, you are either at the early stages of your Scrum adoption OR you’re doing something wrong.” Marten Dalmijn, Head of Product at Rodeo

Dear all,
Recently, well-respected Agile Thought Leader Marten Dalmijn has launched yet another project to improve Scrum. A valiant effort. But frankly speaking, I consider it a waste.

Scrum and religiously sticking to it has become a major impediment to many a product development process. Instead of focusing on the agile delivery of impactful products, too many people in the industry try to improve their Scrum.

Scrum is just one framework and should be treated as such. To be useful, frameworks need to be simple as well as clear in their principles. They also need to be open to adaptation to the situation at hand.

Scrum as practiced by many and sold by the certificate industry is a self-referential closed world. It falls – in my opinion – short in at least three major areas:

• The understanding of the Product Owner role and the qualifications of POs
• Scrum Masters too often being solely Scrum Ceremony- and Impediment Backlog Clerks
• Agile (with capital „A“) being constrained to Scrum as defined in the Scrum Guide

Let me try and explain.

Understanding of the PO Role

„The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. (The PO)… is also accountable for effective Product Backlog management…“ (Scrum Guide 2020)

Many POs start their position with nothing but a CSPO training. These trainings tend to be focused on the „process“ and mechanics of Scrum. „… learn new ways to get to know your customers…“ is the last thing mentioned in the Scrum Alliance’s description of the CSPO certification training – after extolling the framework and principles.

Value is created by an outcome that leads to a positive business impact. Understanding what in- and why a product impacts users, customers, and the company is what truly matters. There is no value in the delivery itself. „an outcome is not, “we shipped the app.” Instead, an outcome is, “50% of our audience has upgraded to the new app.” Outcomes tell us when we’ve delivered something of value (or not).“ (Jeff Gothelf)

Even outcomes are only relevant if they have an impact. Impacts like „Revenue has increased 25% as a result of users upgrading“ or „Support calls have dropped 30% as a result of the upgrade.“ matter.

To be effective, the Scrum PO role (and individual POs) will have to evolve and focus on impact or accept to share its space with Product Managers.

Scrum Masters being only Scrum Masters

Don’t get me wrong. Product development is impossible without someone continuously improving the process. But „The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide…“ as per the same is again too narrow. Sprint-based Scrum is just one way of agile product creation. But „… enabling the Scrum Team to improve its practices, within the Scrum framework.“ in my eyes does not provide the flexibility to create an effective product process.

Again, it’s a matter of desired outcome and training. A „perfect“ by the book (guide!) Scrum implementation does not buy anyone anything. Understanding the constraints at hand and improving an agile product process with the aim of delivering impactful products makes a difference. It should not matter if that takes incorporating elements of Kanban, XP, or any other lean/agile framework – or even coming up with something new. Therefore Scrum Masters need a working knowledge of agile concepts beyond Scrum.

This fluency being absent, as CSM certification courses, unfortunately, do not impart the required knowledge, the Scrum Master role is all too often interpreted as „Scrum Ceremonies- and Impediment Backlog Clerk“.

In the understanding that continuous process improvement is a core part of agile impact creation, Scrum Masters have to be empowered to look over the edge and grow into Agile Coaches who can manage and reduce complexity.

Agile Being Constrained to Scrum (as in the Guide)

Many of our clients‘ managers still confuse Agile with Scrum. The guide and the certifications provide the security that seems otherwise absent in a world of digital intangibles. Proponents of Scrum keep arguing with me, claiming it to be industry best practice.

Admittedly, Scrum has come a long way since Schwaber’s 1993 OOPSLA paper. But Scrum still can’t seem to fully shed its origins in „Systems Development“ and is a far cry from being a product development framework.

In that respect, I would consider it a partially-functional MVP at best. As is the case with any MVP, Scrum has to be adapted and expanded to make problem-solution-fit.

Agile (with capital „A“) and product management practices have evolved well beyond Scrum. Let’s focus Scrum on its basic principles, and put them to best use where they fit. But expand or even replace them where required to create truly agile working models.

It’s time to look beyond Scrum-by-the-Guide. Here are some ideas:

Scrumban: The Myth and The Reality

by Raj Nagappan. How to modify or even abandon Scrum in pursuit of continuous delivery and improvement.

Click to view!

Have a great rest of the weekend!

All the best,
Godehard