Das Scrum Team. Drei wichtige Rollen im gleichrangigen Zusammenspiel.

In Scrum bilden folgende drei Rollen das Scrum Team: das selbstorganisierte Entwicklungsteam, den Scrum Master und den Product Owner. Alle drei arbeiten gleichrangig miteinander und bilden das Scrum Team. In der Praxis ist dies häufig nicht einfach umzusetzen. In vielen Umgebungen ist es ungewohnt oder gar kaum vorstellbar, ganz ohne “Chef” zu arbeiten. Einer muss doch das Kommando haben oder? In Scrum ist dies eben genau nicht der Fall. Und dies mit gutem Grund. In Podcast Folge #30 “ Das Scrum Team” erkläre ich, welche Intention hinter dieser Form der Gewaltenteilung steckt. Anhand konkreter Beispiele verdeutliche ich den Sinn und Zweck des Zusammenspiels und erläutere die Wichtigkeit des Scrum Masters in diesem Konstrukt. Darüber hinaus gehe ich darauf ein, warum es wichtig ist, die drei Rollen nicht nur isoliert sondern im Zusammenhang zu betrachten und zeige, wie die einzelnen Rollen in der Praxis eingeführt werden können. 

Das Scrum Team: Gewaltenteilung in Scrum

Das gleichrangige Zusammenspiel der drei Rollen in Scrum lässt sich meiner Meinung nach am besten mit dem Wort “Gewaltenteilung” beschreiben. Die englische Entsprechung “Checks and Balances” finde ich sogar noch eingänglicher. Sie trifft genau die Intention, die Scrum mit einer Verteilung der Verantwortung auf drei Rollen verfolgt und impliziert ein Zusammenspiel verteilter Verantwortlichkeiten sowie die damit zusammenhängende, gegenseite Regulation. 

Warum eine verteilte Verantwortung wichtig ist, lässt sich am besten erkennen, wenn man sich die einzelnen Rollen näher anschaut: Der Product Owner ist verantwortlich, den Wert des Produktes zu optimieren. Das Entwicklungsteam ist verantwortlich, die passende Qualität des Produktes sicherzustellen. Der Scrum Master wiederum sorgt dafür, dass Scrum effektiv und effizient genutzt wird und nicht zuletzt kontinuierlich Verbesserungen vorgenommen werden können. 

Der Product Owner nutzt als zentrales Werkzeug zur Wertoptimierung das Product Backlog. Er sorgt stetig für eine Priorisierung des Backlogs und ermöglicht dem Team dadurch, stets an den Items von höchstem Wert zu arbeiten. Dies ist wichtig, denn ein Zusammenhang zwischen Aufwand und Nutzen ist in der alltäglichen Arbeit nicht offensichtlich. Deswegen ist es die Aufgabe des Product Owners, dem Team dabei zu helfen, durch Optimierung der richtigen Dinge, mit möglichst wenig Aufwand viel Wert zu schaffen.

Gleichzeitig hat das selbstorganisierte Entwicklungsteam die Verantwortung, Qualität zu liefern. Damit sie dieser Verantwortung gerecht werden können, müssen sie wissen, was die gewünschte Qualität ist. Dies ist nicht trivial, denn Qualität hängt vom Kontext ab. Entwickeln wir ein Produkt in Premium- oder Standard-Qualität? Ist das Team sich nicht im Klaren darüber, führt zu viel Qualität unter Umständen zu unnötigem Aufwand, den keiner bereit ist, zu bezahlen. Im Umkehrschluss führt eine zu geringe Qualität jedoch zu unzufriedenen Kunden und einer vielzahl an Nachjustierungen, um den gewünschten Level an Qualität zu erreichen. Ist das Team sich im Klaren darüber, was das gewünschte Maß an Qualität ist, muss es darüber hinaus in der Lage sein, eigenverantwortlich zu entscheiden, wie dieses erreicht wird. Das bedeutet konkret, dass das Team im Planning unabhängig auswählen kann, wie viel Items es aus dem Product Backlog in den Sprint aufnimmt.

In der Ausführung der jeweiligen Rollen und der Übernahme der damit verbundenen Verantwortung entsteht ein wichtiges Spannungsfeld zwischen Product Owner und Entwicklungsteam.

Das Berliner-Flughafen-Syndrom: Ein gängiges Szenario aus der Praxis

Das Spannungsfeld zwischen Product Owner und Entwicklungsteam ist wichtig für die Arbeit mit Scrum. Warum das so ist, lässt sich in der Praxis in Umgebungen ohne Scrum besonders gut beobachten. Dort wird klassisch das Setzen der Erwartungen mit der Aussteuerung der Umsetzung kombiniert. Das bedeutet, dass eine Person einen Projektplan sorgfältig ausarbeitet und diesen von Stakeholdern abnicken lässt. Danach ist er für die Umsetzung des Plans zuständig. Sollte sich kurze Zeit später herausstellen, dass einige Annahmen dieses umfangreichen Plans zu optimistisch waren, bleibt dem Projektverantwortlichen nichts weiter übrig, als den Plan zu ändern und die Stakeholder zu informieren. Aufgrund des hohen Drucks wird diese Option oft nicht wahrgenommen. Der Druck wird bei der Umsetzung weitergegeben in der Hoffnung, das Ziel doch noch zu erreichen. Das Resultat ist, dass viel zu lange an einem unrealistischen Plan festgehalten wird. Ich bezeichne diesen Missstand gern als das “Berliner-Flughafen-Syndrom”. 

Häufig lassen sich starke Verzögerungen im Projektabschluss, ähnlich wie beim Berliner Flughafen, darauf zurückführen, dass man sich zu spät eingesteht, dass ein Problem existiert und in diesem Stadium (in den meisten Fällen kurz vor dem Live-Gang) sowohl Budget und Zeit fehlen, etwas daran zu ändern. In der Praxis beobachte ich, dass dies keine Seltenheit darstellt sondern viele Organisationen ab einer gewissen Größe ihren eigenen kleinen Berliner Flughafen haben und mit dieser Problematik konfrontiert werden.

Warum das Spannungsverhältnis zwischen PO und Entwicklungsteam im Scrum Team so wertvoll ist

Durch die Aufteilung der Verantwortung auf die unterschiedlichen Rollen soll in Scrum verhindert werden, dass eine einzelne Person das Projekt treibt und steuert. Deswegen gibt es auf der einen Seite das Entwicklungsteam, dass die Verantwortung für Qualität übernimmt. Auf der anderen Seite gibt es den Product Owner, der den Wert des Produktes steigert. In dieser Aufteilung ist es nicht vorgesehen, dass der Product Owner Einfluss oder gar Druck auf den Umfang an Items ausübt, die das Team mit in den Sprint aufnimmt. Die Auswahl soll komplett unabhängig erfolgen. 

Auch wenn viele Product Owner sich mit Sicherheit gelegentlich wünschen, dass das Team zehn anstatt lediglich zwei Items mit in den Sprint aufnimmt, ist die Unabhängigkeit des Entwicklungsteams hinsichtlich des Sprint-Umfangs essentiell. Wird Druck auf das Team ausgeübt, so kann das Team seiner Verantwortung an Qualität nicht mehr gerecht werden. Darüber hinaus wirkt dieser Druck sich negativ auf die Motivation aus, da Sprints dadurch häufig nicht beendet werden können. 

Aufgrund des Zusammenspiels und dem daraus entstehenden Spannungsfeldes ist es möglich, unrealistische Hoffnungen oder etwaige Abweichungen vom Plan zur Realität schneller sichtbar zu machen und Probleme aus dem Weg zu räumen. Es geht an dieser Stelle dann nicht mehr einfach darum, “schneller zu arbeiten”, sondern vielmehr darum, harte Entscheidungen zu treffen. Dies kann beispielsweise eine Verringerung des Scopes oder das Hinzuziehen eines zweiten Teams sein. Es ist natürlich auch möglich, sich darüber Gedanken zu machen, den Liefertermin nach hinten zu verschieben und dementsprechend zu umzuplanen. Durch das frühe und realistische Sichtbarmachen der Abweichungen passiert eine Verschiebung des Liefertermins allerdings wesentlich früher und bewusster, als eine verzweifelte Last-Minute-Entscheidung. 

Scrum ohne Scrum Master nur Scrum Theater

Welche Auswirkungen hat es nun auf das oben beschriebene Zusammenspiel und das damit einhergehende Spannungsfeld, wenn wir Scrum ohne Scrum Master umsetzen? Wenn in Scrum die Rolle des Scrum Masters nur sporadisch oder auch halbherzig umgesetzt wird, entsteht eine Dysfunktion, die ich gerne als “Scrum Theater” bezeichne. Das bedeutet: Scrum wird nicht gelebt, sondern gespielt. Hinter den Kulissen bleibt alles beim Alten. Ein gängiges “Scrum Theater”-Beispiel zeigt sich im Verhältnis zwischen Product Owner und Entwicklungsteam bei der Planung des Sprints. In diesem Szenario präsentiert der Product Owner sein Backlog und stellt abschließend die rhetorische Frage, ob die von ihm gewünschte Menge machbar sei. Durch ein “Das schafft ihr doch, oder?”  teilt er dem Team sehr klar seine Erwartung mit. Teams lassen sich in den allermeisten Fällen dazu hinreißen, die Erwartung abzunicken. 

Das Resultat ist offensichtlich: Da diese Vorgehensweise sich nicht von der unterscheidet, die vor Scrum angewandt wurde, kann sie auch keine besseren Ergebnisse erzielen. Erst, wenn es dem Entwicklungsteam möglich ist, eine wirklich unabhängige Entscheidung zu treffen, erfüllt Scrum hier seinen wahren Zweck. Es ist die Aufgabe des Scrum Masters, genau das sicherzustellen. Er ist dafür verantwortlich, dass alle Scrum Events ihren Zweck erfüllen und somit Scrum als Rahmenwerk effektiv genutzt und gelebt wird und nicht nur ein Theaterspiel ist.  

Ein weiterer wichtiger Aspekt, der durch den Scrum Master abgedeckt wird, ist das Identifizieren von Verbesserungspotenzialen. Aufgrund ihrer Verantwortung ist das Entwicklungsteam sehr auf die Qualität des Produkts fokussiert. Ebenso konzentriert sich der Product Owner auf das Stakeholder Management und die Wertmaximierung. Es ist nicht einfach, nebenher auf das Große und Ganze zu blicken und Optimierungspotenzial zu identifizieren. Deswegen ist es wichtig, diesen Verantwortungsbereich einer weiteren Rolle, dem Scrum Master, zuzuschreiben. Entsprechend ist es auch eine wichtige Aufgabe Hindernisse aufzudecken und dabei zu helfen diese aufzulösen.

Teamverantwortung trotz Gewaltenteilung

Bei all der Gewaltenteilung darf jedoch nicht vergessen werden, dass man in Scrum nur dann etwas Großes schaffen kann, wenn man sich auch wirklich als Team zusammenrauft.  Durch das Erschaffen der einzelnen Rollen sollte ein funktionierendes Zusammenspiel sichergestellt werden. Jedoch führt diese Rollenverteilung häufig in Organisationen  nicht dazu, dass sich die Akteure über das Zusammenspiel Gedanken machen, sondern vielmehr über die einzelnen Verantwortungsbereiche. Das Resultat ist dann leider eine Abgrenzung und eine Isolierung einzelner Bereiche. Etwas, das der ursprünglichen Intention von Scrum entgegensteht. Aus diesem Grund ist die Betrachtung des Scrum Teams als Ganzes essentiell. Es muss nicht nur sichergestellt werden, dass die einzelnen Rollen verstanden und gelebt werden, sondern ebenfalls das Zusammenspiel des gesamten Teams. Es muss jedem klar sein, dass es bei Scrum nicht um die Leistung und Fehler einzelner Personen geht, sondern um das, was man als Team erreicht. Dazu gehört auch, sich gegenseitig zu helfen, zu unterstützen und und die Verantwortung als Ganzes zu übernehmen. Die Einführung der Scrum Rollen

Dies stellt Organisationen nicht selten vor eine große Herausforderung. Die große Frage, die oft gestellt wird ist: “Wie können die einzelnen Rollen und die damit einhergehende Verantwortung eingeführt und gemeinsam als Team gelebt werden?” In einem Kick-Off können die Intentionen hinter den einzelnen Rollen sowie die damit einhergehende Verantwortung gut verinnerlicht werden. Trotz ausgiebigem Kick-Off-Meeting können Rückfälle in alte Verhaltensmuster nicht verhindert werden, denn das ist nur allzu menschlich.

Um die Scrum Rollen erfolgreich einzuführen und zu leben, benötigen Teams nach dem Kick-Off einen stabilen Rahmen. Dieser entwickelt sich beim Durchlaufen erster Sprints. Ist diese Voraussetzung geschaffen, hilft eine Reflexionsphase nach wenigen Sprints, die Rollen dem Kontext entsprechend auszugestalten und wiederkehrende „alte Muster“ auf Grundlage der gesammelten Erfahrung zu beseitigen.

Ich starte diese Reflexionsphase für gewöhnlich mit einem Brainstorming, in dem Teilnehmer Beispiele sammeln, wie die Rollen in den vergangenen Sprints gelebt wurden. Daraufhin gehe ich nochmal auf die ursprüngliche Intention der einzelnen Rollen ein, um zu verdeutlichen, wo es gegebenenfalls noch Abweichungen gibt. Anhand einer einfachen Rollen-Reflexion arbeite ich mit dem Team auf, was bereits gut gemacht wurde und wo es Verbesserungspotenzial gibt. Wichtig ist, nicht nur über die drei Rollen zu sprechen, sondern auch über die Teamverantwortung, die jeder Rolle inhärent ist.  

Die ausführliche Übung sowie ein Template zur Rollen-Reflexion stehen hier zum Download bereit.

Zusammenfassung

In Scrum arbeitet man ganz bewusst mit einer dreigeteilten Verantwortung um zu verhindern, dass eine Einzelperson alle Entscheidungen trifft. Dieses Spannungsfeld  führt dazu, Abweichungen zwischen Planung und Realität früh erkennbar zu machen und dementsprechend früh Maßnahmen zu ergreifen. Der Scrum Master sorgt dafür, dass das Team den diesen harten Entscheidungen nicht ausweicht, sondern dass diese früh getroffen und Scrum damit effektiv gelebt wird. Neben den Verantwortungsbereichen einzelner Rollen ist es essentiell, sich vor Augen zu halten, dass es darüber hinaus auch eine Teamverantwortung gibt. Bei der der Einführung der einzelnen Rollen kommt es vor allem darauf an, eine stabile Umgebung zu schaffen und die Rollen aus der Arbeit heraus zu reflektieren.