Overview

The Scrum Master is not your friend!

3 Comments

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?

 

Kommentare

  • PM Hut

    Hi Marc,

    I thought I was going to read something “bad” about the ScrumMaster, but it turned out that you were more or less listing his responsibilities. It’s a good article though…

  • Melle Koning

    27. December 2011 von Melle Koning

    Hi Marc,

    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.

    @uwe: ‘“Ihr seid das Team! Es zählt nur, was Ihr wollt! ‘ – Opium unter das Entwickler-Volk ”

    Ist schon dass auch auf deutsch lesen zu konnen 😉

    Grusse,

  • Sebastian Schürmann

    Die Annahmen für motiviertes Arbeiten von Dan Pink zugrunde gelegt, nämlich Entscheidungsautonomie-Den drang zu stetigen Selbstverbesserung-Und Sinn – abseits von Gewinnmaximierung, muss ich Uwe deutlich widersprechen:

    Ich habe den Kommentar gelesen und er ist voll mit Wertungen, die für mich schon an Abwertungen grenzen. Wenn den Entwicklern nicht klar ist was die Schnittmenge ist, dann ist es Aufgabe vom “Management” dies auch klar auszudrücken. Wie ein Entwickler arbeitet und seinen, qualitativ hochwertigen, Output maximiert (bitte lasst uns an dieser Stelle keine Produktivitätsdiskussion führen) ist erst mal die Sache der Entwickler. Ich habe das selten scheitern sehen, insbesondere wenn Scrum Master involviert waren die schon über Erfahrungen als Entwickler verfügen, vielleicht auch noch Erfahrung als Teamleiter dazu.
    Am Ende müssen die Teams liefern, und das sollte allen Beteiligten klar sein: Der Sprint und das Produktinkrement sind das Ziel. Ob wir uns dafür pink kleiden oder neben einem Grill mit Beefsteak im Schmorzustand sitzen ist dabei vollkommen egal. Im Real-Life sieht es dann so aus das ganz normale Sachen gefordert werden: Vielleicht mal organisierte Releases, Verbesserungen der Arbeitsbedingungen, Lärm-Trenner, Buildserver. Ich kann das mit dem Wunschkonzert absolut nicht nachvollziehen, bei ordentlicher Moderation sollte doch sehr ergebnisorientiert gearbeitet werden. Das Development Teams hier im Kontext einer Firma agieren, das ist doch komplett klar.
    Um mal genauso wertend daherzukommen wie der Kommentator: Wenn es dem Management/Line-Management nicht gelingt den Kontext herzustellen oder Leute eingestellt werden die das nicht vertragen, dann sind das keine Fehler von Entwicklern.

    Zum Abschluss ein Zitat von Jim Collins, “Der weg zu den Besten”: “Level-5-Führungskräfte sehen aus dem Fenster, wenn sie nach Gründen für ihren Erfolg suchen. Läuft etwas nicht so gut, sehen sie in den Spiegel und üben Selbstkritik. Bei den Chefs der Vergleichsunternehmen war es meist umgekehrt – bei Erfolgen posierten sie vor dem Spiegel, bei Misserfolgen suchten sie draussen nach dem Sündenbock.”

    Dieses Prinzip erwarte ich als Scrum Master auch von den Teams mit denen ich arbeite und ich muss feststellen das die Entwickler das sehr schnell internalisieren. Bei Managern habe ich da eher durchwachsene Erfahrungen gemacht. Eine Kommunikation wie sie in Uwe Friedrichsens Posting geschieht hilft, jedenfalls laut meiner Erfahrung, da nur begrenzt.

    p.s. Ich bin nicht gerade für meinen zarten Umgang mit Teams bekannt, mir wurde schon fehlende Empathie in Retros bescheinigt. Von Coaching-Kollegen, aber nie von Teams. 😉 Die sind übrigens auch ganz glücklich wenn die Realität nicht beschönigt wird. Insofern kann ich dem Posting zustimmen. Samthandschuhe aus und ran an den Speck, hilft ja nix.

Comment

Your email address will not be published. Required fields are marked *