In a recent post I explained the role of the Scrum Master and many of the tasks the role carries out. However, reflecting on what I wrote, I realized that, at times, this role is misunderstood and misused within companies.

Perhaps it is because we come from an overly hierarchical conception of the working world where we have inheritances from the past and a need to find leaders and one-person responsibilities.

This inherited culture broth is, among other factors, one of the reasons why, around the figure of the Scrum Master, false myths which are difficult to dismantle have arisen with force. In this post we explain what are the most frequent misunderstandings while trying to correct them.

Error 1: the tyrant

Before, in the computer science prior to the Agile Manifesto, we had project managers, who were in charge of coordinating and, above all, managing the different roles that they had in their development team: analysts, developers, testers, etc.

These developed "the project" through a Waterfall/RUP in which everything "flowed" through requirements, eternal analysis documents, developments that went on in time and endless test cycles.

The project manager was a semi-God, a tyrant (of course there were good bosses, the problem was that the method they used wasn’t) that he knew everything and that he orchestrated by means of precious Gantt diagrams that were never fulfilled.

When the client had a problem, there was the project manager, to whip up the team in the resolution of incidents via the whip or in the development of new features: "How much do you have left? How are you going? Do you already have it?". As if by repeating it many times the software developed faster.

When the Agile Manifesto came and frameworks such as Scrum, which were born since then, we began to speak in "another" language: leadership, multifunctional teams, product instead of project, early delivery of value...

But not the whole company adapted. It remained a trend of "the computer people" when in fact it had to go further, as a change of organizational mentality (Digital Transformation), because if not... you do not know it, but you are dead.

When an organization is not adapted to this change of culture, the most normal thing is to do the conversion of the project manager to the Scrum Master in a natural way. After all, he sees himself as a team leader, project leader, unit leader, etc.

Error 2: the sweeper

Another common misunderstanding of this figure is the Scrum Master sweeper. I have heard the comment of those who think that the Scrum Master has "free time", which may also have its origin in the ignorance of the figure both in the development teams and in the people who play this role.

Then, the sweeper, mistakenly, tends to occupy that time in pursuing the tasks that nobody wants to perform because they are tedious or motivate the team a little:

• The one who schedules the meetings of the Scrum events, takes notes and makes minutes as secretary.
• The one who every day unsuccessfully remembers the good practices of Scrum.
• The one who looks at logs or code of a very urgent incident that nobody attends.
• The one in charge of collecting the post-it or updating boards.

This point of being the one that is sweeping what nobody doesn’t do fits very well with this framework.

It is true that we are a team (although the Scrum Master is not a member of the development team, this is important) and it is good that we all help each other, but we must not fall into this bad practice, but rather encourage co-responsibility and collaboration between everybody.

Error 3: the fire extinguisher

Following the above, and raised to the maximum power, we would have the fire extinguisher that is "the sweeper" but also must solve all the problems that arise, ie, the famous impediments.

It is said that the Scrum Master "solves" impediments, but not everything fits into this definition: should it be the one that if a developer lacks a monitor asks for it? Can not he do it himself? Is not our organization sufficiently agile to solve that demand? Is it still true that in these times we need valid interlocutors, intermediaries, people who give approvals or signatures, and chinese whispers?

When I arrived at Paradigma I needed a monitor and put a post-it on a board with my need and mail. After receiving the supplies, I had it at my table in less than a week, that's Agile!

From my experience, something that we have to work on perseveringly is self-organization. It is very easy to define how we want to work, but it is very difficult to work in practice in that way, with perseverance and responsibility, in order to achieve results.

Does anyone still think that Scrum is a lax and lazy framework for work? Some said this about XP in its day. For me, it is the opposite, it is demanding and keeps each person on the team tense.

However, there are people who need help, since they are not used to that self-organization. Sometimes, in my teams, before the magical question of "what do I do now?" Formulated by some member of the team directly towards me as a Scrum Master, I turned back and asked: "Who are you talking to?".

It is necessary to find a way for people, who have previously been treated as servile sheep and have become accustomed to asking for permission, to be given the initiative and to act with responsibility and purpose. The third time I've made that joke to someone on the team, he has stopped looking at me, to look at himself and his team.

Error 4: the representative

And it is that the Scrum Master is not the representative of the team on Earth either, so if someone has to take responsibility for the actions of the Development team, be their spokesperson. Also, if someone wants to talk to the team, act as the intermediary Scrum Master or if I have a problem with someone I tell Papa Scrum.

Also within this misunderstood role we could have the reverse side of the coin: the Scrum Master protector who takes care of his owlets until one day, which may never arrive, they leave his nest.

Error 5: the Sprint Police

In addition to all those who have been influenced or on their own initiative have finished in the previous (tyrant, broom, fire-extinguisher, representative...), are those who voluntarily decide to play the role of the Sprint policeman: yes, I know what is Scrum , I know what it promotes, so I'm going to dedicate my Sprint time to evaluate how you do as a team "the Scrum". But yes, do not count on me to solve any problem, or throw a cable when you need it... my job here is Scrum, do you want me to spell it out?

It is one thing to be the Jiminy Cricket of Scrum, which we all have had to do at some point with some clueless, and another is to reach this extreme.

If you start thinking about your work environments, thousands of examples will come to your mind too, of course this does not pretend to be a closed list. I encourage you in the comments also to put your experiences.

Is there anything positive about all this?

Now comes the moment of the positive part... Yes, there is. Little by little and more and more, all this is better understood and things are getting better and better.

Each time the clients understand better that they can not live without transforming themselves. Each time the teams think more often "it's cool to commit! that it's cool to have a boss!". Every time the professionals in the computer industry are better trained. Every time saying "oh no, I hired a Scrum Master and thought it was something else!" happens less often.