I’ve stumbled upon this list, and I like it – as it clarifies again a bit the role of the Scrum Master.

Source: https://age-of-product.com/70-scrum-master-theses/

• Scrum is not a methodology, but a framework. There are no rules that apply to each and every scenario — just practices that have worked before in other organizations.
• Successful practices of other organizations cannot simply be copied to your own. Every practice requires a particular context to work.
• You need to determine for yourself what works for your organization — which is a process, not a destination.
• The role of a scrum master is primarily one of leadership and coaching. It is not a management role.
• A scrum master should recognize that different stages of a scrum team’s development require different approaches: some, teaching; some, coaching; and some, mentoring.
• A scrum master should be familiar with the Shu-Ha-Ri concept of learning new techniques.
• A scrum master’s principal objective should be to remove themselves from daily operations by enabling the scrum team to be self-organizing and self-managing.
• Being a scrum master does not entail, and should never entail, enforcing processes.
• Scrum is not designed for bean counters, although some metrics are helpful in understanding the health of a scrum team. Generally, insisting that the team achieve specific KPI (for example, commitments vs. velocity) does not help.
• Scrum doesn’t elaborate on the process that enables a product owner to add valuable, usable, and feasible user stories to the product backlog. Product discovery using the Design Thinking, Lean Startup, or Lean UX methodologies may help, but in any case, a good scrum master will want the scrum team to be a part of this process (whether participating in user interviews or running experiments).
• A scrum team’s communication with stakeholders should not be run through a gatekeeper (e.g., solely through the product owner) because this hurts transparency and negatively affects the team’s performance. Sprint reviews, conversely, are a good way to stay in close contact with stakeholders and to present the value delivered by the team during each previous sprint.