A question about canonicity of the Scrum theory - Scrum Master is a managerial position

“The Scrum Guide is the canonical definition of Scrum. Ken and I have worked closely together for decades to keep it simple, clear, and, in the true spirit of Scrum, to include only what is absolutely necessary,”

See: https://www.scruminc.com/scrum-alliance-scrum-inc-scrum-org-scrum-guide/

Thank you Ian, that answers my question to an acceptable degree.

@Ian has provided the solid answer. To add to the discussion, the Scrum Guide is the canonical definition of Scrum, and my perspective is that it is crucial not only to understand what the Scrum Guide explicitly states but also to recognize what it deliberately omits.

Many people interpret Scrum as having rigid "rules and processes" that must be followed, yet these often go beyond what is actually written in the Scrum Guide. The guide is intentionally minimalistic, leaving room for teams to incorporate other approaches, techniques, and practices that can add value, provided they align with the mindset and principles of Scrum as set out in the Scrum Guide.

Pierre, thanks for your opinion. 

A sound theory serves two purposes:
- to maximize the theorethical explanations
- to minimze theorethical obligations

Hence such a sound theory needs to provide enough finite evidence so that a student can track-back to foundation rules to get whatever answers they seek if need be AND set boundaries on what the theory actually describes, so that a potential student may know where the original theory starts & ends, and by that, where to find answers not described by the original theory.

Scrum theory does not describe how to manage portfolios or use TRIZ for R&D. That's OK.

According to 2004 Schwaber's book theory - a Scrum Master is usually a Scrum Project Manager. That's OK.

Intentionally incomplete is a nonsense statement unless one is writing some sort of spiritual guide or whatnots, where incompleteness is to be filled by whatever interpretations are deemed OK by the reader, which in turn may lead to conflicts based on contradictions that grow out of contradictory interpretations.

Thus accordint to whatever theory on Scrum that is there, I have a definitive evidence to say that Scrum Master is a managerial position by design, and not doing so is wrong according to theory.

Or in other words - a theory needs to clarify things in definitive ways. Otherwise you may end up in a situation akin to Schroedinger's cat - is it dead or alive? But that thought experiment is something else.

Either Bob the Builder died last week and was burried with rites, or I have just downed few beers with him yesterday.

It may not be so, that Bob died AND he was with me to drink some beer. 

So, to conclude - if you know about one truthful and non-contradictory way to interpret Scrum Guide then please share it with links to sources, foundation rules and so on, so that other people may also use this one true interpretation provided by XYZ.

To add to Ian's callout to the Scrum Guide as canonical definition of Scrum, Gunther Verheyen put together a brief history of Scrum that includes papers, books and Scrum Guide versions in chronological order: https://guntherverheyen.com/wp-content/uploads/2020/12/Scrum-A-Brief-History-of-a-Long-Lived-Hype-Paper.pdf 

"The ScrumMaster provides leadership, guidance, and coaching". 

This holds true throughout the evolution of Scrum. Scrum Master providing leadership, guidance and coaching. 

Scrum Master is a leader.

Starting with the 2010 first version of the Scrum Guide...

"The ScrumMaster is not the manager but leads by coaching, teaching and supporting the team."

From 2011 Scrum Guide through to 2017, Scrum Master was referred to as servant-leader, and then in 2020 guide, as true leader that serves.

Later on in the Agile Project Management with Scrum book you referenced (Chapter 3: The ScrumMaster), there is clarification on why Scrum Master responsibilities are different from Project Manager...

"Why didn’t I continue to use the standard title “project manager”? I wanted to highlight the extent to which the responsibilities of the ScrumMaster are different from those of a traditional project manager"

From the same chapter...

"The ScrumMaster is a leader, not a manager"

"no ScrumMaster should have any time left over to act like a typical boss"

Thanks Ryan, that's also something new.

Just to add some comments:
1. using synonyms (leader, manager) withouth providing idiosyncratic definition true inside of a body of theory is well, just bad

Look at this example - an incident definitions from Merriam Webster (I picked up a random popular dictionary):
https://www.merriam-webster.com/dictionary/incident

Now, ITIL4 definition of an "incident" is - "an unplanned interruption to a service, or reduction in the quality of a service"

So, those definitions are well, not the same as ITIL4's definition is of low abstraction and is coupled with ITIL4 model's logic. 


2. leadership, leader, servant-leader - other names.

Those words do not have a collective unconsciousness meanings, the meaning differ based on what definition does one use.

Once again, Merriam Webster:
https://www.merriam-webster.com/dictionary/leader

2 : a person who leads: such as
(2): a person who has commanding authority or influence

Thus a leader may have commanding authority or influence if one uses this particular definition.

Unless Scrum body of theory has it's own glossary, then people may interpret some words not as keywords with bound-meaning - bound to that body of knowledge, that is, or in other words to a model (like Incident in ITIL4), but whatever they like to fit their particular needs in that moment.

It's a mess.

Also, servant-leader is a philosophy that a project manager can adapt when doing his/her work according to Project Management Institute, I think it was in a PMBOK but now I'm not so sure.

3. what is a "true leader"? Is there a "false leader" by inversion? - I mean, it would make sense, as there were quite some people who were pretenders to the throne but not of royal blood or whatnots. Is it a key-phrase or just a poetic way to describe some kind of an idealised leader? Why I'm even asking those questions, where's the proper glossary of terms?

4. levels of abstraction - usually with high abstraction terms are interpretable. Sometimes this can be ok - like various interpretations of what actually DevOps is (or Three Ways philosophy), although there's this case of no one actually owning DevOps per se. Sure, there is DevOps Handbook by Gene Kim & others, there's DevOps Institute, other companies doing DevOps, though no one of them actually owns DevOps. It's not a trademark/servicemark, patent, intellectual property of someone or something of this sort. 

Afaik Scrum is also almost none of those - as there are creators of Scrum so to some extent they have intellectual property but I'm not that good with legal stuff from United States legislation on those things so I'm not sure how to precisely describe it.

5. thanks for fishing out those quotes, they are something indeed.

It's beyond me how an author can write in such a lazy way - first, the author describes that SM usually takes a role of Scrum project manager - that's ok, though whatever the term "usually" means, never mind.

Then describes that SM is a leader, not a manager, withouth providing a clear demarcation line where one begins and the other ends. That's to some extent fine.

Also - what is a typical boss?

So causality - SM usually takes the role of a Scrum project manager > THEN > acts more like a leader, not a "typical boss". 

But the first cause is still being a Scrum project manager and unless there's a governance policy, then project managers decide how they run stuff around the place. Some may be authoritative, some more lenient, so on. 



To conclude - as with good theory:
- maximize explanations - find what you need within a body of theory
- minimize theorethical obligations - minimize the need to search for answers outside of that body of theory

Gaps in theory are filled by interpretations, opinions, so on, and those are contextual, subjective.

Hence I think after Gabriel Steinhardt from PMTK that one cannot have a meaningful discussion about Scrum theory, aside of exchanging opinions, interpretations, ideas.

A though example, tho there've been such situations before - a group of people need to decide on a course of action. 

Sound theory steers the decision making process as people can reference the body of theory when needed and decide to follow, ignore or overwrite those points that do not seem a good idea in their context. 

A loose theory results in a clash of opinions, ideas, interests, where there is no tie-breaker inside that body of a theory, so how to decide what's true/false? By democratic voting 50%+1 decides what's in, what's out? Weighted voting where some parties have more weight to their decision compared to others BUT still may be overwritten by that less-weighted opinions majority? By sponsor's or decision maker's fiat - so authoritative call?

What are the criteria that one can use to eventually redefine contextual interpretation? Politically convince/threathen/negotiate/bribe/enforce others? 

That's a well, let me risk this statement - a lousy governance practice.

Now, it's perfectly fine for a person or a group of people to go with this high-abstraction, ambiguous hence interpretable terms, ideas, so on. In return it is perfectly fine for some random person somewhere from this planet, such as myself, to say that's it's a messy theory.

And the good things with opinions is that those need not be defended. I like tomato soup - I don't need to defend my opinion.

Anyways, thanks for your answer - it's a fuel for thought for sure.

Verheyen's paper looks like a solid piece of work, I plan to read it, thanks for the link.

This thread can turn into an interesting discussion, but I’ll try to keep the following short with just a few points.

The phrase ‘intentionally incomplete’ is nonsense.

That is the wording used in the Scrum Guide itself—or more correctly, "purposefully incomplete." Above I used the term "intentionally minimalistic." What is being conveyed is that only what is absolutely necessary is provided by the framework, while allowing the team to build processes and select tools suited to their specific product and environment.

As @Ryan mentioned, the Scrum Guide has evolved over the years. While views from 2004 aren't necessarily wrong, I believe it’s more practical to refer to the current Scrum Guide—both what it says and what it doesn’t—and work from there. I believe the terminology in the Scrum Guide is clear and well understood by the community.

Regarding whether a Scrum Master is a manager and how the role relates to that of a Project Manager, here’s my perspective: (Disclaimer: This is open to debate and reflects my personal opinion.)

There is a perspective that a Scrum Master is a manager. Some prefer the term "leader" to distinguish Agile leaders from traditional "monitor and control" managers. However which term is prefered, I hold the view that the Scrum Master is a manager, but not in the traditional sense.

In Scrum, the traditional project management role is split among the Scrum Master, Product Owner, and the team (developers). The Scrum Master ensures the Scrum framework is followed but does not monitor or control progress, assign tasks, or decide what to work on. The Product Owner is responsible for defining items that contribute to the product goal and prioritising work items (i.e., managing the product backlog). The team itself manages progress, decides what they can work on and what they cannot, and determines how to execute the work.

For the Scrum Master, coaching the team on proper Scrum practices, removing blockers beyond the team’s control, and advocating for Scrum principles across the organisation are managerial responsibilities requiring managerial skills. I prefer the 2020 phrasing of a Scrum Master as a "leader who serves," as it provides a clearer description than "servant-leader."

The key difference between a Scrum Master and a traditional Project Manager is: A Project Manager instructs what to do and monitors & control progress, while a Scrum Master coaches and mentors—often advocating against counterproductive behaviours, and focus on fostering Scrum interactions and processes that optimise the team’s efficiency.

For further reading, here’s a blog that explores some ideas (though it’s an older article):
https://www.scrum.org/resources/blog/scrum-master-management-position 

Thanks Pierre, I think that those are interesting points for a discussion. For now I am not looking for a discussion, I'm looking for concrete facts, evidence, data, so on. Crumpets of codified theory, links to antique articles, quotes from a bygone era - those are also ok.

If there is no data, then I prefer my own opinion. 

Though a word on managerial roles that do not have any sort of any sort of power & influence.

It's a lousy governance.

There is not much point in having a captain that one do not need to listen to, because ther is a captain that someone needs to listen to.

Organizations are hierarchical entities, where orders needs to be followed or consequences may arise. Of course, organizations are rife with policies, politics, power struggles, so on, hence sometimes people who do not follow orders do not face consequences and sometimes good intentions are punished with consequences.

I do get that from some points in time there was this rhetoric that this role is a managerial position but not in the sense of... xyz, so basically ontology was complicated to still push Scrum ideology but do not anger potential clients (project managers, directors, so on) so that they'd not ban Scrum outright as they don't need competition.

Even though a simpler approach would be to say that SM is just a work manager with authority just in case, yet the preference is for such a figure to coach, teach, xyz, yada yada.
 

Verheyen's opinion is interesting, yet toughts like this one 

"One can be a manager with accountability, without employing command and control management techniques. A managing Scrum Master is a wise leader who engages people through purpose, vision and motivation. And through living Scrum."

Basically prove my point - managerial position, managerial responsibility, accountability, authority that is there, but needs not to be used.

Otherwise we get back to the algae eater type of a role, that does the work that not many people want to do - run events, type whatnots in this or that system, not being able to tell anyone to shut up and do their work. 

And this is reality in many organizations.