Scrum is the problem (part 1)

We all know that Scrum is practiced fairly poorly in most cases. There are tons of articles on this categorizing it as “Dark Scrum”, “Zombie Scrum”, “No Scrum”, Scrum-but, etc. etc. and the list goes on.

But here is a hypothesis “Scrum, the way it is written, is the problem for why Scrum is practiced this poorly” – we will look into the reasons.

A few days back Bas Vodde of the LeSS Company BV wrote an excellent blog about the “Essense of Scrum” and here is a small extract from his writing:

To me, the essence of Scrum is a simple idea. There is a customer who has a problem that is worth solving and that can probably be solved by developing a product. To help that customer, we put together a team of people who together have or can acquire the skills needed to build that product. This team interacts directly with the real customer to better understand the problem. Together, the customer and the team, decide on the most important first steps in solving the larger problem. The team develops a small, usable product in a short, fixed time to take that first step, solving a small part of the problem. Having reached the end of that first period in time, the team reflects on how they worked and determines how to improve that. The team and customer play with what was created and together choose the best next step. Off they go. This cycle continues until there is no more problem to solve.

The Scrum mechanics have been created to make this simple idea concrete and practical. But successful Scrum adoptions concentrate on the essence more than on the mechanics.

You can read Bas Vodde’s full post at https://less.works/blog/2020/05/05/the-essence-of-scrum.html .

Now back to our hypothesis “Scrum is the problem”… let’s look at some of the challenges in adoption of Scrum.

• Scrum is so simple, so hard to implement – first of all you don’t get the essence that Bas has written about from reading the “Scrum Guide” (www.scrumguides.org) – so that begs the question, why the heck is this is not in the “Scrum Guide” in the first place?
• Scrum talks about empiricism, inspection, and adaptation – and most folks have no clue what these mean when they start – definitely nothing by reading the Scrum guide, per se.
• Scrum talks about itself as an approach to complex products – but again there is no common definition and understanding to either the words “complex” or “products”
• Scrum leaves many things unsaid in the guide – as a container of other practices and methods – so these are wistfully ignored.
• Scrum requires a rule keeper, a “Scrum Master” to help coach. Now in most cases, Scrum Masters have very limited knowledge of Scrum, Product Management practices, Team practices, Software development practices, and Organizational change practices – all of which are required for some value to be realized from Scrum.
• Then to add to the Scrum Master problem, we now need Agile Coaches to help the Scrum masters and teams learn… introducing cost and time to the change. Just is assuming that the Agile Coaches know “Agile” and “Coaching” and most are quiet lacking in both.

So it all begs the question on why the Scrum Guide as written does not achieve the following:

• Convey the simple essence of Scrum as conveyed above.
• Why should the Scrum Guide be written in the vague form that no one gets anything of value from – without expensive interpreters – trainers, scrum masters and coaches, and long-winded change? This looks like exactly the PMBOK and the PMP certification program – tons of theory and a money-making certification program that no one actually practices in reality and things are learned based on practice in context.
• Understand that a meta-process method containing other methods (I don’t agree that Scrum is a framework, but that is for another day) needs to be written in a way so that the masses that consume it understand the essense in a way that they are able to learn it and practice it (within the confines of their existing knowledge)

Perhaps it is time for a rethink and reboot of Scrum and the Scrum Guide as they are instantiated?

PS: The focus of this article is to improve and evolve Scrum, from the way it is. before the Kanban guys and the SAFe guys run around and start saying that Kanban and SAFe or something else will fix these problems – stop it right there! Kanban and SAFe are problems in their own way and has nothing to do with Scrum’s success or failure. I shall write follow up articles on those as well. They all live in the same “Agile” pig-sty. Different pigs, same sty.