How do we look at the blocking responsibilities of scrummaster?

I read the Agile Project Management with scrum by Ken schwaber and have doubts about one of scrummaster's responsibilities. Scrum requires scrummaster to ensure that developers are not disturbed by other irrelevant personnel, especially the superiors, during a sprint. Can this be done? Even if scrummaster identifies the product backlog through effective communication with the product owner, then we start a sprint and confirm the sprint backlog. However, once the requirement changes, can we still ensure that the sprint is not affected by this change?

Or, the premise is that we have an advanced and experienced authoritative product owner. We may try to avoid changes to the demand, but in the software development process, changes are always inevitable. Especially when domestic customers generally do not understand software development, we often need to guide customers to make demands, rather than explicitly asking customers for us. Isn't agility able to cope with changes flexibly? But the problem is that there are always employees in the organization who do not understand agile ideas. In Scott Ambler's view, these bosses are a bunch of "bureaucrats )", they only care about the deadline proposed by the customer, instead of ignoring the basic truth of software development. What's more, customers are always right. Isn't that true?

There may be some ways to make scrummaster a qualified "dog ". For example, he must explain agile ideas and principles and processes for others outside the team. At this time, he is a trainer or evangelist. He also needs to constantly cope with the tedious meetings that the "bureaucracy" requires to hold, and be overwhelmed by the Sea of documents. At this time, he is exhausted by the documents that must be submitted in process management, he is a brilliant coordinator and a playball player. Scrummaster has set up a highly shielded environment for its team members so that they can work with peace of mind without hearing anything.

However, there is a general controversy that such blocking of duties will lead to two distinct camps in the company. One camp is a crazy agile fan, and the other camp is a traditional guard. Will this cause conflicts between the company and the team, and even cause the collapse of the company's corporate culture? As a leader in a company, if we cannot deal with the conflicts between the two, we have to throw a strong man to sacrifice the cost of a small number of people for the overall development, as the head of the Assembly number did.

I used some methods of scrum in a company project. For example, a standing meeting, for example, a sprint iteration cycle. When I divide the development team into several groups, we are also struggling to choose the development method. The leader of a group always sticks to a method that you are familiar with, such as FDD or RUP. As a project manager, I chose a compromise. I asked the leader of each group to select their own method. The only requirement is:
1. Complete the required tasks according to the schedule;
2. You must attend the Team Leader standing meeting every day.

I have protected one of their own options, which may be a disguised form of SHIELD. I don't know if this method is appropriate, but I finally succeeded. Therefore, I am thinking that if a company does not fully establish an agile environment, it may be a good choice to allow them to choose their own methods, in addition to making every effort to implement and train agile. But the premise is that they must be divided into different groups. The most important thing is not to show a preference for a group, but to persuade the team members as a result of facts. In addition, one key point is to ensure communication between groups, especially group owners. Communication is the best way to eliminate misunderstandings.

In Agile development, blocking is indeed helpless. There are risks and conflicts between the two camps. However, if they are handled properly, they can communicate with each other through Team meetings, it can largely eliminate the negative impact of blocking on the Organization. At this point, we need to act as blocker (the blocker, in fact, I prefer to use the blocker, as the big forward in the rugby movement does) The scrummaster must have very strong control.

If I vote, I will vote in favor of the "blocking" method in scrum with a reserved opinion.

Refer:
1. Ken schwaber Agile Project Management with scrum
2. AMR elssamadisy is the scrummaster-as-blocker a pattern to follow or a smell to avoid? [Chinese version: "scrummaster acts as the shield" is a model worth following, or should it avoid bad taste?]
3. Geoffrey Wiseman blocking: useful? Dangerous? Ethical?