That’s no Scrum

Why I start this article with this anecdote? Because it was the last time I was “rewarded” for simply reproducing information. Today it comes to my mind when I hear and read why Scrum does not work in organisations if it is not used, as the book says. “This is not Scrum what you’re doing!” Or: “This can’t work at all if you don’t do Daily Scrum every day!” Or: “Take a look at the Scrum Guide, it has all the important information.” Well, then let’s just take a look at the Scrum Guide.

The Scrum Guide

Scrum is a framework that describes essential concepts for the management of product developments and projects. The rules are explained in the Scrum Guide. This guide is revised from time to time.¹

Framework, essential concepts, current version – you probably haven’t read anything new so far. This is not surprising, after all it is only a reproduction of known information. Nevertheless, I would like to go into the three points briefly:

• Scrum is a framework. There are always discussions about this. Is it not a method after all? “No, it is not a method. Nowhere in the Scrum Guide does it say how to do anything.” But if “methods are understood as a planned procedure to achieve a goal or a way to gain knowledge, then Scrum is also a method. And of course the Scrum Guide does say how to do things.”²
• The Scrum Guide describes essential concepts. The crucial word, however, is not concepts, but ESSENTIAL. In itself it is obvious that the Scrum Guide with its 22 pages does not describe all concepts that make sense in the course of an agile development or that might make sense under certain circumstances.  For comparison: when V-Modell XT – a process model for the development of software and systems – was published more than 15 years ago, it had more than 600 pages. Of course, more content can be discussed on 600 pages than on 22 pages. I will go into this point in detail in a moment. (Don’t worry, I will not recommend you to read 600 pages, but an appeal will follow.)
• Why are there revisions to the Scrum Guide? One reason is certainly the clarification of content. “It is the task of the Scrum Master to implement Scrum in the sense of the Scrum Guide” or: “Scrum is generally suitable for product development and not only for software development” are such clarifications. I will also go into these two examples.

What is not written in the Scrum Guide

As mentioned, the Scrum Guide describes essential concepts:

• the Scrum Team (consisting of Product Owner, Scrum Master and Developers),
• the events (Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective) and
• the artefacts (product backlog, sprint backlog and increment).

Guess how often the word “agile” appears in the Scrum Guide? Zero. Not once is “agile” used. The word “agility” appears exactly one time. Surprising, isn’t it? There are a number of concepts and terms that many companies use day in and day out in the course of their development with Scrum, but which are not mentioned in the Scrum Guide:

• user story
• acceptance criteria
• story points
• definition of ready
• taskboard
• velocity
• standup meeting
• traceability
• scaling or Scrum of Scrums

The list can be easily continued: Prototypes, minimum viable products, pretotyping, click dummies – very many terms are not used. But what does this absence of terms mean? From my point of view: Nothing. In fact, I think it’s clever that Ken Schwaber and Jeff Sutherland don’t try to use or even explain these terms. It is simply not necessary, because Scrum is first and foremost a framework (or a method … 😉).

Nobody’s giving you 15 points …

If the absence of terms means nothing, what about the terms that are described? From my point of view they have a great meaning, but nobody will give you 15 points or an A+ just because you use Scrum as described in the Scrum Guide.

Of course it is important to know how the concepts work and what recommendations are made. Certainly I would also advise many organisations to seriously try out the concepts and gain their own experience with them. For this they need

• patience and a long breath,
• a suitable mindset (even if it is not mentioned once in the Scrum Guide) and
• probably also external support.

For me the focus of Scrum is not on the concepts, but on the framework itself. Scrum is not synonymous with the words in the Scrum Guide. In my opinion, Scrum unfolds its value for organisations by inspecting and adapting a respective approach. Exactly as it is described in the Scrum Guide.

At this point I would like to recommend the series of articles by Heiko Bartlog Agility? We tried that! Does not work!. Maybe some areas in your company are already working Subversively agile, as Oliver Buhr describes it, and other areas can profit from corresponding experiences? You can find many useful tips in the German Inspect & Adapt Blog by Daniel Dubbel.

My appeal

I had “promised” you an appeal and I wanted to go into two more statements in the Scrum Guide. “The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.” and “Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, …”.

Why was the 2nd sentence included as a clarification in the current version of the Scrum Guide? Isn’t it obvious that Scrum can be used as a framework for the development of products, regardless of the type of product? Scrum is a framework, no more and no less. Apart from the advertising message of this statement, I suspect that many people read exactly the words that are in the Scrum Guide but do not pay attention to the context. To be honest: such sentences irritate me. Not because they are unclear and incomplete, but because they are so obvious that they are actually not needed.

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.” In other words: It is the task of the Scrum Master to implement Scrum in the sense of the Scrum Guide. Not literally, but in the spirit of Scrum and thus in the sense of inspection and adaptation. I wish the sentence would read: “… in the sense of your organisation”, but I do not want to get hung up on individual phrases.

And what is my appeal?

• Read between the lines in the Scrum Guide and pay attention to small phrases such as “rules of the game”.
• Get away from single statements and try to see the whole picture.
• Use the information as a frame, a starting point or as a guiding idea. But always keep your concrete situation in mind.
• Develop your approach further: “Inspection and adaptation” is the magic formula.
• Refrain from discussions about whether Scrum is a framework, a method or a process model. The added value of such discussions is often manageable.

And avoid people who accuse you of not doing Scrum at all, or Scrum fails in your case, just because you do not follow the recommendations in the Scrum Guide. Ideally you work in a way that suits you and your product development.

PS: Do you remember my anecdote? In fact I was never able to write 12 pages in 45 minutes. I had anticipated the task, prescribed the work and left one line free for the assignment I wanted to write above my prepared content. When our history teacher presented the exam question, I was shocked. I had no idea what it was about. But what could I do? I wrote down the assignment about my “wrong” content and handed in my work after 45 minutes. Sometimes even 15 points are worth nothing!

Notes:

[1] A new version of the Scrum Guide was launched in November 2020.
[2] That insight comes from Kai-Marian Pukall who wrote an fantastic post about Modern Agile Principles: Agile work made easy.

Zombie Scrum is a term that describes a form of practice that looks like Scrum on the outside, but does not properly implement the actual spirit and principles of the framework.

Michael Schenkel has published more articles in the t2informatik Blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.