Scrum Master – The Director of Agile Culture
Much has been written about the Scrum Master, millions of times (with more than 13 million entries in Google) it has already been described what a Scrum Master should do, what he stands for and how his role within Scrum is defined. And still – this role is one of the most underrated roles in Scrum. How is that possible?
The aim of this article is not so much about adding one more to the many million descriptions of the role, but to put it in the right context of the three Scrum roles on the one hand and between the Scrum team and the organization on the other.
How does the role of a Scrum Master behave in relation to his Scrum team colleagues and how does he interact with the organization?
What I would like to point out here is a highly cultural aspect, and so I’m already getting pretty much down to business.
3 Roles in Cultural Change
Culture is a problematic term anyway, because it can mean everything or nothing, and it is often used for things that are difficult to define in detail.
I use the term culture here as a “traditional set of attitudes and behaviors”. By including the term “traditional” here in this context, it should become clear that you can’t create an agile culture in three months.
This, in turn, should not be used as an excuse if no effects can be seen three months after the introduction of the agile methodology.
The cultural problem I would like to point out here is not caused by the role of the Scrum Master, but from a practical point of view it probably affects it the most. It is in any case a problem that many organizations won’t have on their radar when they introduce agile methodology. This makes the job of Scrum Master extremely difficult, because they have to deliver the bad message to the organization or – even worse – demand this cultural change.
This is no small task, if you consider the dimension of the problem. But now let’s talk about the problem itself:
Scrum as an implementation methodology requires three roles. Everything that needs to be negotiated during the implementation of a project or product is negotiated between the Product Owner, the Scrum Master and the cross-functional dev team.
You can well imagine that this results in an enormous burden of tasks and responsibilities for each individual role, all the more so if the product is highly complex, the organization is scaled up, or completely new technologies and processes are being introduced.
This can only work if the individual roles are highly self-sufficient, but also perfectly coordinated.
However, in doing so, they are disrupting a part of the foundation of our current civilization, which is why we use the term “cultural change”. Find out more here: Digital & Agile Transformation: A Cultural Change
We are questioning our model of authority. In our society, and consequently in almost all organizations, we have two types of authority: the deontic authority, i.e. the attribution authority, and the epistemic authority, i.e. the knowledge authority. We have been following this principle for several hundred years now, partly emphasizing one, partly emphasizing the other.
Scrum introduces a new model of authority that is neither purely epistemic nor purely deontic, but somehow different.
Each of the three roles is on the one hand very specialized – this is the epistemic part – but has decision-making powers which correspond to the role.
This is in fact somewhat different from, for example, in the German government, if you consider the ministers.
The ministers themselves are not experts in their fields and if the ministers disagree, the Chancellor’s so-called directive competence comes into play. In most companies, this deontic hierarchy is even more pronounced.
But this is detrimental to agile working, because the essence of agile working is – apart from all the agile gospels – that good and correct decisions have to be made rapidly and based on very little information.
There is no complete specification, but at the same time the software is becoming more and more complex and deadlines are tight due to increasingly brutal time-to-market requirements. This is the problem in a nutshell.
What remains in a situation like this are the actors, which is why Scrum is more about people, while Waterfall is more about processes and architecture.
Many organizations are not even aware of this problem, including its cause and, consequently, its scope, when they introduce an agile methodology. This often leads to a shortened or mechanical introduction of agile roles and processes. In other words:
Without this essential cultural change, an organization will at best perform great Scrum theater, but it will have a hard time getting the methodology out there in such a way that they can safely meet their economic goals.
The Scrum Master – and this is the reason for this detour – is now the first protagonist of this cultural change. If you had to sum up the three roles in Scrum in one sentence, you could do it like this:
The Product Owner has sovereignty over the backlog, the Scrum Master over the methodology, and the dev team over the implementation.
What is the role of the Scrum Master?
Of course, all three roles are equally affected by this cultural change, but the Scrum Master is clearly the leader by being responsible for the methodology.
This role is highly unappreciated in many organizations. Scrum Masters are then more likely to be reduced to the role of a better PMO, in which they organize the meetings properly and perhaps also moderate and generally “take care” of things.
They often lack the necessary support from the organization and respect from often long-established development teams, all of whom were established before.
With such a configuration it is then difficult to initiate a fundamental cultural change, which in turn is often blamed on the Scrum Master. It’s a vicious cycle.
SAFe thus rightly points out that management commitment is no longer sufficient for an agile change, but that management must drive such a change. Management can’t delegate this responsibility to the Scrum Masters.
The Scrum Masters will carry this change into the teams, and they will certainly have an effect on the project organization, but agile work is such an extensive process and such a comprehensive change that Scrum Masters alone will not be able to manage it.
Even the messages of the communities right up to the big organizations like Scrum.org or Scrum Alliance are not particularly helpful. They suggest that you can learn Scrum in a three-day seminar by answering 80 questions and – poof – you are a certified Scrum Master.
In reality, the situation is more akin to that of a medical specialist who, after his license to practice, has to gain several years of practical experience in order to be able to work with patients on his own.
Because the role of the Scrum Master is more of an intermediate. He is situated between the Product Owner, the Dev Team and the organization. He is not only a friend and advocate of the development team to which he is undoubtedly closest.
His role is to enforce the methodology towards all participants.
This is often painful, especially because agile working is new to everyone, often including the scrum master. In my trainings I often say that Scrum Masters should be people who don’t need many friends. This is of course an exaggerated representation and I don’t want to paint a black picture of the role.
Being the protagonist of such a cultural change can be extremely exciting and satisfying. In fact, it should be exactly that, and organizations would be well advised to treat their Scrum Masters accordingly.
Above all, they must be given the necessary authority – an authority that has the nature of compliance, i.e. similar to data protection officers or works councils, to whom people are reluctant to object.
What are the tasks of a Scrum Master?
The challenge for Scrum Masters – and this is also the reason why they would need a longer practical training comparable to that of a doctor – is not to explain how Scrum works. Instead, it involves developing a concept of how teams and project organizations can be brought to this point in a given situation.
- How are teams trained so that they can make commitments and, most importantly, keep them?
- How should organizations adapt their demand management process to agile methods?
- How is a DevOps culture implemented so that a seamless transition between development and production can take place?
- How is an organization being prepared for teams that work vertically?
These are examples of questions that go far beyond explaining sprints, dailies or retrospectives, but which are directly related to the economic success of an organization or have a significant influence on it.
For example: Commitment is a basic value in Scrum that is not negotiable.
Organizations – but also many agile coaches – are often very quick to customize the method because they think that their organization is completely different than all the rest. That may be true, but it only means that the path to the agile method must be quite different and must be adapted to this particular organization, not the method itself.
But the way in which a Scrum Master trains teams and sets appropriate framework conditions in the organization that support (and not exactly prevent) this can be highly individual. And to find this way, Scrum Masters need a lot of practical experience.
