The Scrum Masters job description looks somehow different in every organization. That leads to the fact, that demands are made again and again, that we can not meet, or that we should not meet. Let us get started to get rid of these ambiguities.
Simply put, it is the job of the Scrum Master to make sure that Scrum works in the relevant organizational unit – whatever that means. This large scope for interpretation is the source of some of our problems, because neither we nor everyone else can be entirely sure, how to work with this kind of generic statement.
It is even more difficult with our colleagues in the Kanban world, because there is not even a general name for them. Nevertheless, we can draw the parallel, that it is also their job to ensure that agility is lied in their respective organizational unit.
If you read the job description of a Scrum Master or any other Agile, you may find all sorts of formulations. Usually some kind of moderation of meetings – no one has a problem with that.
Often we find something like »conflict resolution«. We should be extremely careful with that, but we run into some kind of dilemma here.
If it is our job to ensure that Scrum is lived in our organizational unit and that it shows results (whatever that may be – we have to agree on that, otherwise we end up with different expectations, which is never fun), then everything, that contributes to getting this process running, keeping it alive or expanding / improving it, falls under it.
First of all, that is method and coaching our colleagues, which only applies to the educational aspects. We cannot provide personal coaching in the sense of personality development. We (at least most of us) are not trained for this, and I strongly advise you not to be persuaded.
You should draw a line in the sand here. Your argument is very simple: »I am not trained for this. If I try to do that, I could be causing more harm than good.«
Most professional coaches in personality development are psychologists, not without reason. If you get into the situation to look for professional help for your team or an individual colleague, please be conservative. There is a lot of new-age-nonsense und lots of charlatans, who are as clueless as you when it comes to the most complex psychological processes.
The ever so often mentioned conflict resolution is pointing to the same direction. We are no mediators, but if a conflict within our team or within one of the team connection to other units appears and stands in the way of our Scrum, we have to take action. That is a dilemma, because we might have to do something, we are not trained for.
In our direct environment, where we know everyone, we might be able to solve conflicts, if we have a reasonable amount of social competence. We can talk to our arguing teammates, read between the lines, what causes the conflict, and work with them. We might be able to reach the point of enough mutual respect, so that work can go on properly.
But no one can expect, that we are able to solve every possible conflict ever. Even the best mediator in the world can do that. What can we do, when we reach our limits, when nothing can be done by talking and listening?
We could consult a professional mediator, but this is of course only possible, if your teammates are consent. Worst case, we have to work on the team itself. Meaning that someone has to leave, which is of course the last possible solution. In all my years that has only happened twice.
As a Scrum master we cannot refuse conflict resolution completely, but we are very limited, and everyone has to understand that. Solving conflicts is not our superpower. We cannot magically make people work together happily, if they just can not stand each other. But our main task – making Scrum work – remains, so that we can not just turn our backs on something like that.
In any case, we should reject any kind of conflict resolution in any other organizational unit. If someone comes up to you and asks you to take on a conflict somewhere in the deepest bowels of your organization, you politely decline. No matter who it is.
Double underlined, bold, italic, and red: No matter who is asking you. Even if it is the top honcho.
We are not mediators. We are limited in solving conflicts, even in our own direct environment. In an area, that we do not know, with people, that we do not know, it is very likely that we may cause more harm than good.
Another thing all Scrum Masters and other Agiles are often asked to do, is moderating some meeting somewhere somewhen, or a workshop or other trainings.
There is no problem to moderate something somewhere. We can do that. We do that all the time. But my priority lies within my own organizational unit. If I can help someone by moderating an event without hurting my own team, I am fine with it. If I would have to postpone an appointment with my own team, I politely decline.
Talking about organizational development or my scaled levels is something different. That will affect my team at least indirectly. In that case, I would simply talk to my teammates, describe the situation and my motivation and reach an agreement. Postponing an event is not a big deal for most of them.
If we are asked to hold training courses or workshops, a second condition applies in addition to the first: We have to be familiar with the topic. I would never give a training that someone else has written, just because I am so good at those things. If it is about something I am very familiar with, I will gladly help and provide support. If I am not, I am the wrong person to talk to.
You should decline. Nothing is gained, if you do a workshop, that is completely alien to you. Methodological support would still be fine, but you should stay in the background.
A third thing, that is often mentioned in job descriptions, is the »responsibility for your assigned area«. Such formulation is in desperate need of clarity. If it means, that we are talking about numbers – as in sales – then that is absolutely not your job. This responsibility rests with the product owner. Full stop. No discussion.
It is within our responsibility to train the product owner, but we do not make any technical decision.
The term »responsibility« can be interpreted in a variety of ways. If we do not manage to reach clarity and a mutual understanding, we end up with different expectations, which is always a problem.
If we talk about methodological and processual development of our organizational unit, we are on board. Of course. If we are talking about keeping an eye on organizational processes and agreements, we are also part of it, because that still is part of our methodological work and therefore part of our tasks. But as soon as we reach technical or substantive decisions, we are out. That is within the responsibilities of the developers or the product owner. We should be very careful not to mix these things up.
Core: The limits of the Scrum Master lie in the personal development of individuals as well as in the mediation of conflicts. When moderating meetings or conducting trainings or workshops, you should decide individually whether there is a conflict with your own organizational unit and whether you are technically suitable at all. Regarding responsibility, pay attention to the boundary between content, technic and method.
