Der ScrumMaster ist nicht dein Freund!

Im Rahmen der Unconference ALE2011 in Berlin fand eine Open Space Session mit dem Titel “How to get developers’ buy-in when introducing Scrum in a chaotic environment?” statt. Während einer Betrachtung der Rolle des ScrumMasters habe ich den Satz “Der ScrumMaster ist nicht der Freund des Entwicklungsteams!” propagiert. Meine etwas provozierende Formulierung soll ein falsches Bild der ScrumMaster Rolle aufzeigen, welches mir immer wieder begegnet. Der ScrumMaster ist meiner Meinung nach eben nicht der Freund des Entwicklungsteams, der dieses vor dem unangenehmen (sogar teilweise feindlich betrachteten) Product Owner, Stakeholder, Managern, Vertriebsmitarbeitern und Anwendern beschützt oder gar vollständig abschirmt. Es kann vorkommen, dass er genau diese Position einnimmt, dies ist aber eher selten der Fall und sollte nur einen Sonderfall darstellen.

Die eigentliche (und einzige) Verantwortung des ScrumMasters ist es, die kontinuierliche Produktivität des gesamten Scrum-Teams (und nicht nur des Entwicklungsteams) sicherzustellen und möglichst zu steigern. Alle konkreten Aufgaben, die ein ScrumMaster hat, lassen sich darauf zurückführen. Dies sollte bei der ScrumMaster Rolle nie aus den Augen verloren werden und lässt sich gut an den typischen Aufgaben eines ScrumMasters aufzeigen:

Eine Aufgabe des ScrumMasters ist es, das Entwicklungsteam vor externen Störungen zu schützen. Dies soll den Mitgliedern des Entwicklungsteams ermöglichen, sich auf die aktuelle Aufgabe zu fokussieren und so ihre Produktivität zu steigern. Aber nicht alles was das Entwicklungsteam als Störung empfindet, reduziert im Endeffekt die Produktivität. Das kann auch den gegenteiligen Effekt haben: z. B. intensive Kommunikation mit der “Außenwelt”, wie Feedback von Anwendern, ist grundsätzlich erwünscht und steigert die Produktivität.

Bei der Aufgabe als Wächter und Förderer des Scrum Prozesses kommt der Produktivitätsgedanke auch zum Tragen. Durch die Förderung des Scrum Prozesses werden die agilen Werte und Prinzipien gefördert, dies steigert wiederum langfristig die Produktivität.

Eine weitere Aufgabe ist es, die Einhaltung von Vereinbarungen/Regeln (sowohl der projektinternen als auch der externen) zu überwachen und ggf. einzufordern.  Dies kann vom ScrumMaster bei entsprechendem Fehlverhalten auch erfordern, unfreundlich aufzutreten. Das kann jede Rolle treffen, auch die des Entwicklungsteams. Dies dient im Grunde ebenfalls der Produktivität, da durch die Vereinbarungen und Regeln verhindert wird, dass immer wieder die gleichen Diskussionen geführt werden.

Die Steigerung der Produktivität durch das Ausräumen von Impediments ist offensichtlich. Dies gilt aber auch für Unterstützung jeglicher Art, die der ScrumMaster anderen Projektbeteiligten, allen voran dem Product Owner, bietet. Zum Beispiel wenn er dem PO bei der Pflege des Product Backlog hilft, dem Personalmanager zu Mitarbeiterbeurteilungen verhilft, dem Mitarbeiter aus der FiBu die Reisekostenabrechnungen erklärt oder dem Manager aus der Fachabteilung erklärt, wie er Einfluss auf die Priorisierung nehmen kann.

Eine Aufgabe, welche oft untergeht, ist die Moderation von Meetings und Diskussionen. Unmoderierte Meetings und Diskussionen sind meist ineffizient und da der ScrumMaster oft nicht direkt in den besprochenen Themen involviert ist, kann er sehr effektiv moderieren. Daraus ergeben sich aber auch die Ausnahmen: sollte er zu stark in das Thema der Diskussion involviert sein, ist es sinnvoll, dass jemand anders die Moderation übernimmt. Auch wenn sich eine gewisse Diskussionskultur entwickelt hat, die eine Moderation nicht mehr notwendig macht (z.B. beim Standup Meeting), sollte man diese dann auch weglassen.

Wenn man nun nie aus den Augen verlieren soll, dass sich der ScrumMaster um die Sicherstellung und Steigerung der Produktivität bemühen soll, kann er nicht nur der Freund des Entwicklungsteams sein. Er muss dem gesamten Prozess/Projekt positiv gegenüberstehen und dementsprechend mit allen Projektbeteiligten sinnvoll agieren.

Begegnet Euch auch die Vorstellung des ScrumMasters als “Wohlfühl”-Manager nur für das Entwicklungsteam? Oder sind eure ScrumMaster ein Freund des gesamten Prozesses?

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Marc Clemens

7 Antworten auf Der ScrumMaster ist nicht dein Freund!

  1. Inhaltlich stimme ich überein. Allerdings ergibt sich bei einer Wahl – auch wenn die Rolle rotiert – des Scrum Masters aus dem Team ein nicht unerheblicher Rollenkonflikt. Heute bin ich noch Teammitglied und per definition Freund des Teams – und morgen bin ich Scrum Master, und nicht mehr Freund des Teams. Und übermorgen bin ich wieder Teammitglied. Das steckt einiges an Konfliktpotenzial drin.

  2. Marc Clemens sagt:

    Hallo Guido,

    ein sehr guter Hinweis von Dir. Meine Schlussfolgerung ist, dass den ScrumMaster aus dem Team zu “rekrutieren” keine gute Idee ist. Die ScrumMaster-Rolle häufig rotieren zu lassen ein noch schlechtere, da die Rolle fast zwangsläufig extrem geschwächt wird. Das halte ich für nicht akzeptable.

    Marc

  3. Hallo Marc,

    dem stimme ich voll und ganz zu und denke, Du hast das noch recht freundlich und “kuschelig” formuliert … ;-)

    Ich erlebe seit nunmehr knapp 20 Jahren, dass das, was ein Projekt voran bringt und das, was der “gemeine Entwickler” (wenn ich mal so ein Stereotyp bemühen darf) als “ideale Arbeitsbedingungen” empfindet, recht häufig nur eine geringe Schnittmenge aufweist.

    Und ich denke, da liegt auch eine fatale Missinterpretation von Agilität gemäß Scrum vor: Das Team rückt zwar in den Fokus des Geschehens (eben weil das Team letztlich die Instanz ist, die den Projektauftrag umsetzt), das bedeutet aber nicht, dass wir jetzt ein Team-Wunschkonzert haben, in dem jeder das machen kann, was ihm gerade Spaß macht und der Scrum-Master bitte alles als “lästig” Empfundene von ihm fernhält.

    Leider laufen ganz viele selbsternannte agile “Experten” und “Evangelisten” herum, die auf Konferenzen und anderweitig solche “Ihr seid das Team! Es zählt nur, was Ihr wollt! ‘Die’ haben Euch lange genug nicht ernst genommen! Nur Ihr seid wichtig! ‘Die da’ sollen gefälligst still sein und Euch machen lassen!”-Parolen als Opium unter das Entwickler-Volk streuen und sich entsprechender Beliebtheit erfreuen.

    Ich kann und möchte auch niemandem einen Vorwurf machen, der solche Parolen für bare Münze nimmt, wenn selbst die (selbst) erklärten “Gurus” der Community mit solchen Aussagen um sich werfen.

    Dass der Effekt für die einzelnen Entwickler ein verheerender ist, muss man glaube ich nicht extra erwähnen: Aus Sicht der Anforderer und Entscheider sitzt da ein Haufen selbstverliebter, ignoranter, unproduktiver Diven, die nicht das liefern, was gebraucht wird, sondern sich mit Verweis auf die Agilität lieber selber an den Füßen spielen … so mal das Worst Case Szenario hart auf den Punkt gebracht.

    Dehalb finde ich Deinen Beitrag um so wichtiger: Du stellst die Balance wieder her: Natürlich ist das Team wichtig. Natürlich sollte das Team ohne unnötige Störungen arbeiten können. Aber das Ziel dahinter ist keine Entwickler-Wohlfühlrunde, sondern höchste Professionalität … was nebenbei auch eine Menge Spaß machen kann … ;-)

    Gruß, Uwe

  4. PM Hut sagt:

    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…

  5. Melle Koning sagt:

    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,

  6. Pingback: Scrum is impossible without quality « Melle Koning Blog

  7. 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.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>