IT Knowledge from developers for developers

During the Unconference ALE2011 in Berlin, an Open Space Session titled „How to get developers’ buy-in when introducing Scrum in a chaotic environment?“ took place. While reviewing the role of the Scrum Master, I have propagated the statement „The ScrumMaster is not the friend of the Development Team!“ My a little provocative formulation shall point out a wrong image of the ScrumMaster role, which I meet with consistently. In my view, the ScrumMaster is just not the friend of the Development Team, who guards the team or actually totally insulates it from the uncomfortable and even partly hostile regarded Product Owner or from stakeholders, managers, sales people and users. It can happen, that he has exactly this function, but this is unusual and should be only an exception.

In fact, it is the sole responsibility of the ScrumMaster, to secure and, if possible, to increase the continuous productivity of the whole Scrum-Team (and not only of the Development Team). All tasks of the ScrumMaster are related to this fact and you should not forget this while considering the ScrumMasters’ role. My statement is underlined by the typical duties of the ScrumMaster:

One of his duties is to protect the Development Team against external incidents. That way, the members of the Development Team have the chance to focus on the current job, which also means that they increase their productivity. However, not everything, which the Development Team regards as a hold-up at last decreases the productivity. On the contrary, it can have a different effect too: For example, a thorough communication with the outside world is basically welcome and increases the productivity.

While fulfilling the task to guard and assist the Scrum process, the thought of productivity has an effect too. By assisting the Scrum process, the agile values and principles are boosted, which in turn increases productivity in the long term.

Another task is to guard and, if necessary, to demand the adherence to certain agreements or rules (both internal and external). Should there occur an appropriate misbehaviour, it might call for an unfriendly appearance of the ScrumMaster. This might affect any role, even that of the Development Team. Basically, this conduces to productivity too, since agreements and rules avoid that the same discussions are held again and again.

It is obvious that the productivity is increased by smoothing out impediments. But this is also effective for any support, which the ScrumMaster offers to other participants of the project, in the first place to the Product Owner. For example if he helps the PO to maintenance the Product Backlog, if he assists the human resources manager in order to get personnel reviews, if he explains the employee from financial accounting how to deal with travel expense accounting or the manager from the specialist department, how he can affect prioritisation.

One task, which often does not get much attention, is the moderation of meetings and discussions. Meetings and discussions which are not moderated are frequently inefficient and since in most cases the ScrumMaster is not directly involved in the according subject, he can be a very effective moderator. However the exceptional cases result from this too: Should the ScrumMuster be involved in a certain topic too much, it would make sense that anybody else assumes the moderation. Moderation should be left out too, if a certain culture of discussion has been developed (like for example in a stand up meeting), which means that a moderator becomes redundant.

In consideration of the fact, that the ScrumMasters’ task is to secure and increase productivity, he cannot only be the friend of the Development Team. He must show a positive attitude towards the whole process / project and in the same way act reasonably with all participants.

Do you also meet with the imagination of the ScrumMaster as a kind of “Wellness-Manager” only for the Development Team? Or are your ScrumMasters friends of the whole process?

Thanks for a great post. You are correct in pointing out that the scrum master is not ONLY ther for the developers. Often, the scrum master has to take on the role of a feind, dictating the developers that a hotfix indeed does goes against scrum but is necessary to keep the (internal) customerhappy. When a scrum master fosters the team, the team will know when it needs to plan with ‘maintenance of the last live release’ in the back of their heads.