Are we being too bookish?

Do you consider the Scrum Guide to be bookish?

A manager of several Scrum Teams recently remarked to me that his Scrum Masters keep saying "It has to be done that way, it states it in the Scrum Guide, and it really turns me off". Should the Scrum Master play the role of the Scrum police and be so dogmatic? He brought up a valid point because often a servant leader needs to go beyond that to help people understand the "why" behind the Scrum Guide.

On the flip side of that, I have noticed that there are many misconceptions and myths about Scrum. I've also interviewed many Scrum Masters who have never read the Scrum Guide, and wonder how professional that is? 

I respect the question, thank you for asking it.

I think this is an important question.

Personally, I'm very careful to denote when I'm talking about a part of the Scrum framework that is defined in the Scrum Guide versus "patterns, processes, and insights that fit the Scrum framework" or some other tactic that is more context-sensitive. The reason for this can be found in the Scrum Guide itself:

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

If someone says that they are using, employing, following, implementing, or some other similar word Scrum, that means something specific. That means that they are working toward the theory, values, roles, events, and artifacts as they are laid out in the Scrum Guide. Knowing that they are using Scrum as a basis for their product development process means that they don't need to describe every aspect of their process in excruciating detail. Instead, as they describe a problem that they are encountering, I am able to also look at the Scrum Framework for places where they can solve their problem by implementing some other strategy or tactic that I'm familiar with.

This doesn't mean that a "Scrumbut" or "Scrumand" process is bad. It could be working very well for the organization or team in their context. However, if you've deviated from the Scrum framework, the places to hook in various patterns or strategies may not exist in your team. We may not have a word to describe your process as it exists, and describing it as Scrum may lead people down the wrong path for helping.

I do think the 2020 Scrum Guide revision had a small change that will make a big difference, for people who have noted it. In the 2017 Scrum Guide, the section on the Sprint Retrospective said that the Scrum Master "encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint". This wording was dropped from the 2020 Scrum Guide revision. Although the Scrum Master is still responsible for "leading, training, and coaching the organization in its Scrum adoption" and "planning and advising Scrum implementations within the organization", I can see these resulting in identifying that Scrum is no longer appropriate and helping the organization find a more appropriate framework or stepping aside for someone who is able to do that.

Chris Belknap is absolutely right - when someone says that it must be done the way it says in the Scrum Guide, that's a turn-off. Scrum is not appropriate for all organizations, teams, and contexts. The Scrum Master should not be enforcing that teams must follow Scrum. Instead, someone in the coaching role should understand the Scrum framework and how its combination of roles, events, and artifacts work together to help promote agility and value delivery. They should also understand when those same roles, events, and/or artifacts are getting in the way and the team needs to reach for something different to be effective at delivering value to their stakeholders.

In my opinion, the focus of a team should be on the product and not the process. Many of my peers get into long discussions about the principles and mechanics of Scrum, Agile, SAFe, etc. but they never talk about the product. I'm pretty certain that my clients and their customers don't care about how the bacon is made. They just want it crispy.

Wow. Your insights are very interesting.

@Mark I like your metaphor.

To gently play a little with your idea, if we focus on the process (eg. create a great team), the client will be able to order any kind of food, not only crispy bacon ;-)

I frequently will use quotes from the Scrum Guide when someone asks if what they are doing is Scrum.  But I also will follow up with the reminder that the Scrum Guide describes a framework and is mostly nonprescriptive.  The portions that do prescribe are done so for the sake of providing discipline.  I have worked with some teams that needed that discipline while other teams can provide their own discipline levels.  

I have stated many times in posts that in order for a team to be successfully agile means that they have to understand what it means to be agile and employ techniques to accomplish that.  There are many techniques and practices that can be used within the Scrum Framework and parts of the Scrum Framework that can be used in other ways.  I agree with @Thomas Owens that "Scrumbut", "Scrumand", "Scrummish" is not a bad thing if the teams implementing it are successful and the organization is able to compete in their market. 

I do however take offense with entities that state you can learn Scrum from them but they do not teach the framework as described in the one true source of information for Scrum, the Scrum Guide.  I have the same attitude if someone says they will teach me to drive a commercial tractor-trailer but do it by using a compact car.  Just using words from the framework but in the wrong context doesn't mean that you are using/learning Scrum.  I have similar problems with being called a Software Engineer.  We don't engineer software, we develop software.  Engineers in all other disciplines must go through certification processes and maintain those certifications.  Software Engineers do not. 

Scrum is only one of many ways that an organization can use techniques to be able to adjust quickly to changing needs and requirements of their marketplace.  But learning the principles and reasons why Scrum is effective can lead you to opportunities of identifying other ways that might be better suited for your organization's needs.

I can only speak from my personal experience and what I've read/watched. Scrum gets a really really bad rap where I have been. Primarily because it's very dogmatic, or has been up until very recently where the guide was updated a bit, although I still think it's very strict. I've been told several times, quit quoting from the scrum bible it's not helpful... I had to learn you can't win hearts and minds with a book, you need to demonstrate the effectiveness through numbers mostly, as leadership is obsessed with numbers. But, primarily, Scrum just doesn't work for a lot of companies because they're not setup to implement it.

The number one problem Scrum has from a perception perspective is that it got turned heavily into a business, so it's first and foremost goal is to make money and continue to be able to make money. This means it needs to be able to continue selling certifications and training classes etc. Because of this, there is a massive sea of under experienced, unqualified scrum "masters" out there that dilute the framework and only add to the frustration. I can say that because I was one and have worked alongside them myself. 

Agile was based on four values, and twelve principles that didn't imply any required steps, simply suggestions. Scrum couldn't just offer suggestions or it would cease to be able to guarantee success. Kind of puts you in a no true scottsman fallacy. Customer has X problem with scrum. Response is, well you're not doing scrum correctly. Pay me and we'll get you sorted.

It could very well be instead... That Scrum just doesn't work for your unique situation. It could be that you're in a situation where Scrum isn't going to apply very well. I worked for an organization that wanted to pay me as a sole scrum master to come in and transform 6 and at times more of their "teams" of assigned individuals with assigned work, and no self-management or control over their own delivery / process, into scrum teams. 

I attempted to do just that, and it became PAINFULLY clear that scrum was not only not going to work at all, it was actually hurting us. Why? Because, we didn't have half of the necessary parts. We had 0 product owners, 0. We had 0 customer interactions, yep 0. Our VP wanted 60 projects done per year, because he had 60 developers and thought that was an acceptable amount of work.

Those projects had no PO, instead, the "team" members were required to reach out to internal representatives of these customers and beg for requirements, those representatives were very difficult to get ahold of and frequently just sent massive documents as answers. 

I can go ON and ON about how we had 5-7 day turn arounds on requests for server build / access, don't even get me started on the security and firewall issues we had to constantly request and wait for etc. This was a classic WATER scrum FALL scenario where the teams were flat out LITERALLY told they weren't trusted to do good work without supervision...

I was WAY too green to see how cancerous and toxic all of this was, it took me 2 years of trying to convince leadership step by step of how awful all of this was, learning all along the way myself, that I finally had a good handle on it. Then of course the pandemic hit, and they decided to just get one of their directors SAFe certified and replaced me. 

Don't even get me started on SAFe, I think that's about as anti-agile as it gets, but that's a totally diff topic.

IMO, scrum is absolutely AMAZING when you can do it as it is written... Unfortunately, rarely is the company designed or enabled to actually implement it that way, and you're left trying to fit a square peg through a round hole with duct tape and bubblegum, the whole time getting blamed for why it's not working...

I specifically call myself an Agile Team Facilitator now because I want the ability to come in and say, hey, just letting y'all know, Scrum is not going to work here, instead... let me work with your culture / structure etc and let's figure out a way to make your broken processes work better, because it's never going to actually be agile or work. There's a reason Project Managers are becoming the only thing companies want, because they are not only the single throat to choke when it all falls apart, but they're extremely process heavy and fit well into command and control that's still so pervasive. 

Just a junior sm's point of view.

@Olivier. Off topic but I think that there is great value in the new (though slow) move towards coaching product professionals (not talking about "agile coaches" or scrum masters).

In fact, when a client is open to new ideas, I encourage them to invest in trainers (those who can certify others) to come onsite periodically to conduct trainings, and to have ICF credentialed coaches available onsite to build the Organizational Development muscle of the product organization. This, I believe, is the middle ground between our positions.

Sometimes I get the impression many Scrum Masters focus too much on being compliant with the Scrum Guide.

From my perspective, a Scrum Master's purpose is NOT to ensure everything is done as described in the Scrum Guide.

Scrum is a framework to build products and services, and the purpose of a Scrum Master is to help teams and organizations building those products with Scrum.

For example, if the Daily Scrum takes 17 minutes, is this really a problem?

As long as the team meets the Sprint Goal and produces a Product Increment, there is no need to waste energy about the length of the Daily Scrum. Even the Scrum Guide says it is a 15-minute event.

When I was a beginner Scrum Master, I made a mistake and quoted the Scrum Guide regularly.

What happened?

Nobody cared. Developers did not care, stakeholders did not care, and even managers did not care.

So I asked them what they care about. Developers want to develop software with fewer interruptions. Stakeholders want their stuff delivered and know when a feature will be ready or when there will be a risk of delay—the same for managers. 

People in a company still have the same needs, whether they work with Scrum or with traditional waterfall. Helping those people removing their pain points and satisfy their needs WITH Scrum will make an impact. Quoting rules from the Scrum Guide will not.

For me that is less knowledgeable/have less experience, the Scrum Guide is the base, the scale.



I think it is like music. You have scales to train. But to have more harmony or give a specific effect in the context of the writing a piece, maybe you have to make modifications, but you know why and what it could you to.



If you talk with a musician, he would know at least what are scales, and how to find what is inside. It is easier to exchange, because you both know the patterns, it is easier to express your different point of view and sensibility within the frame.