Über den Scrum Master wird viel geschrieben, millionenfach (>13 Mio Einträge in Google) wurde bereits beschrieben, was ein Scrum Master tun soll, wofür er steht und wie seine Rolle innerhalb von Scrum definiert ist. Und dennoch gehört diese Rolle in der Praxis zu der wohl am Meisten unterschätzten Rolle in Scrum. Wie kann das sein?
In diesem Artikel wird es nicht so sehr darum gehen, den vielen Millionen Beschreibungen der Rolle, noch eine weitere hinzuzufügen, sondern sie in den richtigen Kontext der drei Scrum Rollen einerseits und zwischen Scrum Team und Organisation andererseits zu setzen.
Wie verhält sich die Scrum Master Rolle also in Bezug auf seine Scrum-Team-Kollegen und wie interagiert er mit der Organisation.
Kultur ist ohnehin ein problematischer Begriff, denn darunter kann irgendwie alles oder nichts verstanden werden und er wird oft auch für etwas im Detail schwer zu Definierendes verwendet.
Ich verwende den Begriff Kultur hier als ein „tradiertes Set von Einstellungen und Verhaltensweisen“. Wenn der Begriff „tradiert“ hier schon auftaucht, dann ist damit auch klar, dass eine agile Kultur nicht in drei Monaten herzustellen ist.
Das kulturelle Problem, auf das ich hier hinweisen möchte, entsteht nicht durch die Rolle des Scrum Masters, aber aus praktischer Sicht betrifft es sie wohl mit am Meisten. In jedem Fall ist es eins, welches viele Organisationen gar nicht so auf dem Radar haben, wenn sie agile Methodik einführen und dies erschwert die Arbeit von Scrum Mastern enorm, denn sie müssen der Orgnisation dann die schlechte Botschaft überbringen oder – noch schlimmer – diesen kulturellen Change einfordern.
Keine leichte Aufgabe, wenn man sich die Dimension des Problems verdeutlicht. Aber jetzt zum Problem selbst:
Scrum als Implementierungsmethodik kommt mit drei Rollen aus. Alles, was in der Implementierung eines Projektes oder Produktes zu verhandeln gibt, wird zwischen Product Owner, Scrum Master und cross-funktionalem Dev-Team ausgehandelt.
Man kann sich leicht vorstellen, dass dies zu einer enormen Aufladung jeder einzelnen Rolle mit Aufgaben und Verantwortung führt, umso mehr wenn das Produkt sehr komplex ist, die Organisation skaliert oder ganz neue Technologien und Verfahren eingeführt werden.
Das kann nur funktionieren, wenn die einzelnen Rollen sehr autark aber gleichzeitig perfekt aufeinander abgestimmt sind.
Damit rütteln sie aber an einem Teil des Fundaments unserer aktuellen Zivilisation, weshalb wir auch das große Wort „Kulturwandel“ bemühen.
Gerüttelt wird an unserem Autoritätsmodell. In unserer Gesellschaft, und demzufolge auch in nahezu allen Organisationen kennen wir zwei Autoritätsmodelle, die deontische Autorität, also die Zuschreibungsautorität und die epistemische Autorität, also die Wissensautorität.
Nach diesem Prinzip funktionieren wir schon seit einigen hundert Jahren, mal die eine, mal die andere mehr betonend.
Scrum führt ein neues Autoritätsmodell ein, das weder rein epistemisch ist, noch rein deontisch, sondern irgendwie anders.
Jede der drei Rollen ist einerseits sehr spezialisiert, das ist der epistemische Teil, hat aber Kraft seiner Rolle entsprechende Entscheidungskompetenz.
Das ist sogar etwas anders, als beispielsweise in unserer Regierung, wenn man sich die Ministerrunde ansieht. Die Minister selbst sind keine Experten in ihrem Fachgebiet und sollten sich die Minister nicht einig sein, greift die sogenannte Richtlinienkompetenz der Kanzlerin. In den meisten Unternehmen ist diese deontische Hierarchie sogar noch stärker ausgeprägt.
Für agiles Arbeiten ist das aber nicht gut, denn das Wesen agilen Arbeitens besteht darin – mal von allen agilen Evangelien abgesehen – dass sehr schnell gute und richtige Entscheidungen auf Basis von nur wenigen Informationen getroffen werden müssen. Es gibt keine vollständige Spezifikaiton, die Software wird gleichzeitig aber immer komplexer und die Deadlines drücken wegen immer brutaleren time-to-market Anforderungen, um das ganze Problem in einem Satz zu beschreiben.
Was in einer solchen Situation noch übrig bleibt, sind die Akteure, weshalb sich Scrum ja auch mehr mit den Menschen beschäftigt, während Wasserfall sich eher mit Prozessen und Architekturen befasst hat.
Dieses Problem inklusive der Ursache und damit auch der Tragweite ist vielen Organisationen bei der Einführung agiler Methodik gar nicht bewusst und das führt dann oft zu einer sehr verkürzten oder mechanischen Einführung von agilen Rollen und Prozessen. Anders ausgedrückt:
Ohne diesen notwendigen kulturellen Wandel spielt eine Organisation bestenfalls großartiges Scrum-Theater, aber wird es schwer haben, die Methodik so auf die Straße zu bringen, dass die ökonomischen Ziele sicher erreicht werden können
Der Scrum Master – und das ist der Grund für diesen Exkurs – ist nun der erste Protagonist für diesen kulturellen Change. In einem Satz könnte man die drei Rollen in Scrum ungefähr so zusammenfassen:
Der Product Owner hat die Hoheit über das Backlog, der Scrum Master über die Methodik und das Dev-Team über die Implementierung.
Betroffen sind von diesem kulturellen Change natürlich alle drei Rollen gleichermaßen, aber der Scrum Master ist hier ganz klar der Leader indem er die Verantwortung für die Methodik hat.
Diese Rolle wird in vielen Organisationen sehr unterschätzt und Scrum Master sind dann eher auf die Rolle eines besseren PMOs zurückgeworfen, in der sie die Meetings artig organisieren und vielleicht auch moderieren und sich ganz im Allgemeinen „kümmern“.
Ihnen fehlt es oft am nötigen Rückhalt durch die Organisation und an Respekt bei oft alteingesessenen Entwicklerteams, die ja alle schon vorher da waren.
In einer solchen Konfiguration ist es dann schwer, einen so fundamentalen kulturellen Wandel einzuleiten, was den Scrum Mastern dann wiederum oft auch noch vorgeworfen wird. Ein Teufelskreis.
SAFe weist daher ganz zurecht darauf hin, dass ein Management-Commitment für einen agilen Change nicht mehr ausreicht, sondern dass das Management einen solchen Change selbst treiben muss. Das kann das Management nicht an die Scrum Master delegieren.
Da sind auch die Botschaften der Communities bis hin zu den großen Organisationen wie Scrum.org oder Scrum Alliance nicht besonders hilfreich, die suggerieren, man könnte Scrum in einem Dreitageseminar erlernen und 80 Fragen beantworten und schwups, ist man zertifizierter Scrum Master.
Real ist die Situation doch eher vergleichbar mit einem Facharzt, der nach seiner Approbation noch einige Jahre praktische Erfahrung sammeln muss, um eigenverantwortlich auf die Patienten losgelassen zu werden.
Denn die Rolle des Scrum Masters beschreibt doch eher einen Intermediate. Er sitzt zwischen Product Owner, Dev-Team und Organisation. Er ist eben nicht nur Freund und Anwalt des Entwicklungsteams, dem er zweifellos am nächsten steht.
Er ist in der Rolle die Methodik gegenüber allen Beteiligten durchzusetzen.
Das ist oft schmerzhaft, ganz besonders deshalb, weil das agile Arbeiten in der Praxis ja für alle zunächst neu ist, oft auch für den Scrum Master selbst. Oft sage ich dann in meinen Trainings, dass Scrum Master Menschen sein sollten, die nicht viele Freunde brauchen sollten. Das ist natürlich eine übertriebene Darstellung und ich will die Rolle auch nicht schwarzmalen.
Protagonist eines solchen Kulturwandels zu sein, kann extrem spannend und befriedigend sein, sollte es sogar und die Organisationen wären gut beraten, ihre Scrum Master entsprechend zu behandeln.
Vor allem müssen sie mit der notwendigen Autorität ausgestattet werden, einer Autorität, die Compliance-Charakter hat, also ähnlich wie Datenschutzbeauftragter oder Betriebsrat, denen auch ungern widersprochen wird.
Die Herausforderung für Scrum Master, und das ist auch der Grund, warum sie eine dem Fachartz vergleichbar längere praktische Ausbildung bräuchten, besteht nicht darin zu erklären, wie Scrum funktioniert. Sondern sie besteht darin ein Konzept zu entwickeln, wie Teams und Projektorganisationen in der konkreten Situation dahin gebracht werden.
Organisationen, aber auch viele agile Coaches sind oft sehr schnell dabei die Methode zu customizen, weil sie denken, dass ihre Organisation ganz anders ist, als alle anderen. Das mag stimmen, aber das bedeutet nur, dass der Weg zur agilen Methode sehr unterschiedlich verlaufen muss und auf diese spezielle Organisation abgestimmt werden muss, nicht die Methode selbst.
Häufig wird Teams der Unterschied zwischen agilem und klassischem Projektmanagement nicht richtig erklärt. Was ist der wesentliche Unterschied und wie vermeidet man, zurück in ein Micro-Management zu rutschen?
Scrum vs. Wasserfall – Für alle Scrum Fans die schlechte Nachricht zuerst: Scrum ist nur ein Kompromiss. Die gute Nachricht, dies ist die einzige schlechte Nachricht..
Wie trainiert man ein Scrum Team? Mit diesen einfachen 4 Schritten wird dein Team schnell fit für den effektiven Einsatz der Scrum Methodik.
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
