Es ist zwar schon eine Weile her, als über die Fünf Schwachpunkte von Scrum geschrieben habe. Die Resonanz auf diesen provokanten, aber aus meiner Sicht treffenden Artikel war durchaus unterschiedlich. Man hat mich des Plagiats bezichtigt, man hat mich als unkonstruktiven Satzbauartisten bezeichnet, man hat mir Rollen-Personifizierung vorgeworfen und mich als nachhilfebedürftig abgestempelt (inkl. Links zu „guten Coaches“). Ach ja, es gab auch tatsächlich einige ernsthafte Diskussionen, die von nachdenklichen Lesern über die einzelnen Punkte geführt worden sind.
Wie dem auch sei, am Ende des besagten Artikels hatte ich einen Ausblick darauf gegeben, dass ich nicht nur die Punkte nennen werde, die ich als Schwachstelle in Scrum sehe, sondern auch meine Ideen dazu beitragen werde, diese Schwachstellen zu stärken und damit Scrum als agile Managementmethode für mein Verständnis erfolgreicher zu implementieren. Das habe ich für das Thema “bessere Sprintdauer” schon getan, und damit widme ich mich heute einem ganz besonderen „Schwachpunkt“ – dem Scrum Master.
Die innere Handbremse
„Oh je, der Scrum Master ist ein Schwachpunkt von Scrum?“ werden sich nun viele stirnrunzelnd denken. Ja, genau so ist es, der Scrum Master ist meiner Meinung nach sogar eine richtig hinterlistige Schwachstelle in Scrum-Projekten. Das liegt viel weniger an dem Scrum Master als Person als am Scrum Master als Rollenimplementierung, wie er in vielen Büchern beschrieben wird und von Scrum-Trainern bei Unternehmen „antrainiert“ wird.
Viele Scrum Master in heutigen Organisationen sind „Vollzeit-Scrum Master“, die dediziert ein Scrum Team betreuen und sich tagtäglich mit den Sorgen, Nöten und Bedürfnissen Ihres Teams auseinandersetzen. Meiner Meinung nach ist hier schon der erste Schwachpunkt erkennbar. Obwohl die Rollendefinition in „Scrum-Bibeln“ nicht oft vom Scrum Master als institutionalisierte Position spricht, wird sie überall diskutiert, implementiert und implantiert.
Ein Scrum Master ist dazu da, sich überflüssig zu machen. Eines seiner größten Ziele ist es, sein Team in die Selbstorganisation zu führen und dort zu halten. Doch wie geht das bei einem Scrum Master, der eine Planstelle in einer Organisation ist? Mehr noch, hinter der Rolle Scrum Master verbirgt sich dann eine konkrete Person, ein konkreter Arbeitsplatz, ein konkretes Schicksal. Und diese Person soll sich jetzt überflüssig machen? Das wird wohl selbst der barmherzigste Mensch nicht tun. Jetzt könnte man diesen Vorwurf mit „don’t blame the tool“ abwiegeln, aber das wäre zu einfach. Die Schwachstelle liegt viel tiefer begraben als es auf der Oberfläche sichtbar ist.
Zwischen den Stühlen
Zumeist befindet man sich als Scrum Master innerhalb einer „agilen“ Organisation sowieso in der Zwickmühle. Einerseits sollte man das Team nicht führen, sondern begleiten. Andererseits bleibt das Management als „Chicken“ selten mehr als die ersten paar Sprints ruhig. Nicht selten trägt es „Erwartungen“ und „Strategische Leitlinien“ an den oder die Scrum Master heran. Schließlich ist der Scrum Master ja überzeugt von Scrum und der Idee, dass der Product Owner nun das Management betreiben soll. Die Kennzahlen über Team- und Projektperformance holt man dennoch beim Scrum Master ein, weil der „einfach näher dran am Geschehen ist“.
Viele Scrum Master fügen sich in diese organisatorische „Kneifzange“, anstatt sie mit Kraft zu durchbrechen. Wie soll man auch, wenn z.B. der eigene Job daran hängt oder die letzte (dicke) Auszahlung des Dienstleistungsvertrages mit dem Kunden noch aussteht?
Der Alleskönner
Viele eingefleischte Scrum-Experten und erfahrene Trainer stellen deshalb die Rolle des Scrum Masters auf ein hohes Podest. Der Scrum Master sei „eine Führungsrolle im Prozess“, es dauere tausende von Stunden, die Charakteristika und schwierigen Aufgaben eines Scrum Masters zu meistern. Ein Change Agent und Facilitator hat es eben nicht leicht.
Der Scrum Master als Rolle wird oft als Alleskönner dargestellt. Schließlich muss er die Grundlagen des Managements beherrschen, ein absoluter Teamplayer sein und obendrein auch noch ein feiner Kerl den jeder mag. Der Scrum Master ist der neue MacGyver in der agilen Software-Entwicklungslandschaft und kann selbst aus den schwierigsten und aussichtslosesten Situationen mit Einfallsreichtum, Know-How und Cleverness den Erfolg hin zur effektiven & profitablen Software-Entwicklung gestalten.
Eine schöne Vorstellung. Doch die Realität ist eine andere. In der Realität gibt es nur einen MacGyver, und den sogar nur im Fernsehen. Schade für die vielen Softwarefabriken und Weborganisationen, schade für die vielen Scrum Trainer und Berater, schade für die Tausenden von „Certified Scrum Master“. Doch Karten auf den Tisch: Es wäre auch zu schön gewesen, oder?
Mittlerweile ziehen sogar Alpha-Agilisten und Scrum-Kenner das „Scrum Is Always Better, Scrum Master Is Always Hero“-Gefühl durch den Kakao. Mit wunderbar leichtem und gleichzeitig nachdenklich stimmendem Humor schreitet seit einiger Zeit „Scrum Norris“ durch die geistigen Pfade der Agilität.
Quo Vadis Scrum Master?
Doch weder Humor noch Lamentiererei helfen einem dabei, diesen Schwachpunkt des „Scrum Master-Daseins“, nämlich die viel zu starke Fokussierung der Rolle und deren Implementierung, zu verbessern. Was tun? Wie kann man in einem Scrum-Team oder in einer Organisation mit Scrum-Teams diesen viel zu starken Fokus auf den Scrum Master mindern? Ich möchte hier einen konkreten Verbesserungsvorschlag und eine konzeptionelle Perspektivänderung als Diskussionsgrundlage vorstellen.
Dazu möchte ich ein Szenario aus der Entwicklung selbst voranstellen, um den Effekt der Maßnahme deutlicher hervorzuheben. Es wäre meines Erachtens sehr hilfreich für Team und Scrum Master, wenn die Abhängigkeiten zum Scrum Master zu allen anderen Rollen sowie zu der umgebenden Organisation so gering wie möglich sind. Um Abhängkeiten voneinander zu entkoppeln, gibt es in der Software-Entwicklung einige bewährte Methoden. Eine davon ist die sog. „Dependency Inversion“ oder „Inversion of Control“. Das hört sich doch genau nach dem an, was gebraucht wird, nämlich eine „Inversion of Control“ im wörtlichen Sinne. Nicht der Scrum Master organisiert das Team, das Team organisiert das Team.
Scrum Master in Bewegung
Übertragen auf den Prozess und die Rahmenbedingungen, die die Scrum-Methode vorgibt, ließe sich eine solche Indirektion mit einem einfachen Mittel erreichen: Die Rolle des Scrum-Masters wird im Team rotierend „durchgereicht“. Statt eines Scrum Masters, der sich dediziert um ein (oder noch schlimmer mehrere) Teams kümmert, kümmert sich das Team um die Erfüllung der Rolle des Scrum Masters. In der Praxis kann man den „Scrum Master-Hut“ z.B. sprintweise, monatsweise, oder quartalsweise von Team-Mitglied zu Team-Mitglied weiterreichen.
So ist jeder einmal mit der „Verantwortung“ des Scrum Masters konfrontiert und lernt obendrein eine weitere, wichtige Perspektive des Prozesses kennen. Dadurch erschließt sich sukzessive dem ganzen Team eine tiefere Kenntnis der Vorgehensweise. Es ergibt sich eine induktive Selbstorganisation: Man lernt die Probleme und Aufgaben der Scrum Master Rolle kennen und hilft sich gegenseitig im Team, dass es nicht zu Problemen kommt oder diese schnell ausgeräumt werden.
Aus Sicht des Prozesses mündet das Rotationsprinzip in mehrere Vorteile. Zunächst wird einmal wird nicht nur die Selbstorganisation gefördert, sondern auch das Know-How effektiv verteilt. Der Bus-Faktor wird im Kontext des Prozesses und der Methodensicherheit massiv erhöht.
Refokussierung der Kommunikation
Für den Product Owner ist der wechselnde Scrum Master ein regelrechter Segen: Statt sich die ganze Zeit auf den Scrum Master zu konzentrieren, kann (und muss) er sich nun mit dem ganzen Team auseinandersetzen – so wie es am effektivsten ist und sich auch „gehört“. Darüber hinaus lernt der Product Owner, seine geschäftlichen Anforderungen und Interessen mit der „Masse Team“ zu koordinieren, statt mit dem „Ansprechpartner“ Scrum Master, wenn es mal wieder Abstimmungsprobleme oder Missverständnisse gibt.
Nicht nur der Prozess, sondern auch die umgebende Organisation – also das Unternehmen – profitiert von dieser Maßnahme. Statt wieder neue Stellen oder Stufen in die Organisation zu implementieren, wird durch die Rotation der Scrum Master von „allen“ getragen. Ergebnis: Keine neue „Position“ Scrum Master, keine Kompetenz- und Verantwortlichkeitskonflikte mit Teamleads (Gruppenleiter) oder Head-Of’s (Abteilungsleiter), keine Skalierungsprobleme. Die Führungsmöglichkeiten sind klar und bei einem partizipativen Führungsstil höchst effektiv.
Die Rückkopplung zum mittleren Management und der strategischen Führung wird greifbarer, denn jetzt kann sich das Management nicht mehr den „Scrum Master“ als Mittelsmann für Mitarbeiterführung herauspicken. Der Fokus für wird stattdessen zum Product Owner gelenkt. Der wiederum wird – wie auch das Management selbst – realisieren und anerkennen müssen, dass sich eine Selbstorganisation nicht kommandieren lässt, sondern sich nach Bedürfnissen orientiert.
Scrum Master: Kein Platz für Projektleiter
Das Unternehmen wird schlanker, weil der „klassische“ Projektmanager nun nicht mehr in die für ihn äußerst angenehme „Scrum Master“-Schiene flüchten kann, sondern sie entscheiden muss: Entweder Product Owner oder Team!
Ich selbst dachte vor ein paar Jahren noch, dass der klassische Projektmanager nur die Wahl zwischen Scrum Master und Product Owner hat. Falsch! Heute darf ich die Lehre ziehen, dass ich damals auf den Scrum Master als Rolle viel zu Stark fokussiert gewesen bin. Team und Product Owner sind die “Key Player”, der Scrum Master ist nur Mittel zum Zweck, und das – wenn möglich – nur soviel wie unbedingt notwendig.
Mein Fazit: Mit einem rotierenden Scrum Master schafft man viele inherente Hürden aus dem Weg. Das Team, der Product Owner und die umgebende Organisation fokussieren sich deutlicher auf die Aufgabe. Der Prozess Scrum wird dadurch im Software-Entwicklungs-Theater wieder mehr zum Bühnenbild, das Team zu den Schauspielern und der Product Owner zum Regisseur. Damit ist dann auch eine gute agile Vorstellung wesentlich einfacher und schmerzfreier umsetzbar. Vorhang auf!