Der ScrumMaster ist nicht dein Freund!

7 Kommentare

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?

Autor

Marc Clemens

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

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

  • Oktober 20, 2011 von Marc Clemens

    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

  • 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

Kommentieren

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