Much has been written about the Scrum Master, millions of times, it has already been described what a Scrum Master should do, what he stands for and how his role within Scrum is defined..
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.
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.
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 a 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.
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.
This is in fact somewhat different from, for example, 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:
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.
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.
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,
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.
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.
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.
Organizations, but also many agile coaches, are often very quick to customize the method because they think that their organization is very different from everyone else. That may be true, but that only means that the path to the agile method must be very different and tailored to that particular organization, not the method itself.
For example, Commitment is a basic value in Scrum that is not negotiable.
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.
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
Much has been written about the Scrum Master, millions of times, it has already been described what a Scrum Master should do, what he stands for and how his role within Scrum is defined..
How to get your team to give a commitment and to complete a sprint and wich roles Scrum Master, Daily Standup and Plannings play.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
