Als Scrum Master sich selbst überflüssig machen? 5 Gründe, warum das nicht funktioniert

In manchen Firmen und Blogs rund um Agilität wird Scrum Mastern gesagt, ihre Aufgabe sei, sich selbst abzuschaffen, sich überflüssig zu machen. Eine Teilnehmerin in einem meiner Kurse empfand das als extrem respektlos und wenig motivierend für den Karriere- und Entwicklungspfad als Scrum Master.

Aber ist es überhaupt realistisch, sich als Scrum Master selbst überflüssig zu machen? Ich behaupte: Nein! In diesem Artikel erfährst du 5 Gründe, warum ich dieser Meinung bin.

Warum bitte sollten sich Scrum Master selbst überflüssig machen?

Hinter der Annahme, als Scrum Master könntest du dich selbst abschaffen, steckt die Annahme, dass deine Aufgabe ist, einen gewissen Zielzustand zu erreichen. Nachdem das passiert ist, fällt die Aufgabe weg – und bist du überflüssig. Bereits darin steckt ein Trugschluss, wie wir später feststellen werden.

Und es verblüfft, dass von anderen Berufsgruppen, die Ziele zu erreichen suchen, typischerweise nicht erwartet wird, dass sie sich überflüssig machen. Weder für Ärzte noch über Projektleiter oder Fussballtrainer hört man so etwas üblicherweise als Anspruch.

Warum wird diese Argumentation dann für Scrum Master vorgebracht? In meinem Erleben hauptsächlich aus einem dieser Gründe:

1. Aus der Perspektive heraus, dass „das Team“ sich selbst zu managen lernen müsse. Und das sei doch dann erreicht, wenn der Scrum Master nicht mehr gebraucht wird.
2. Aus dem finanziellen Kalkül heraus, möglichst bald möglichst viel von den durch den Scrum Master verursachten Kosten einsparen zu können.
3. Aus der abstrakten Idee heraus, dass der Scrum Master am System arbeiten müsse, nicht im System. Und wenn das System dann die „richtige“ Gestalt hat, gibt es für ihn nichts zu tun.

In der Praxis funktioniert es nicht

Leider funktioniert diese Selbst-Abschaffung meiner Erfahrung nach in der Praxis nicht. Ein erfahrener agiler Coach, der einem Team (mit Scrum Master) eine Starthilfe gibt und sich nach ein paar Monaten zurückzieht, ja, das kann funktionieren. Aber ich habe es in knapp 20 Jahren, in denen ich mit Scrum arbeite, in keinem einzigen Fall erlebt, dass der Scrum Master sich selbst erfolgreich abgeschafft hat. 

Nur ein Beispiel von mehreren: Ein Team in einem großen Versicherungskonzern war sehr zuversichtlich, dass sie es auch ohne Scrum Master schaffen – und der Scrum Master war erkennbar stolz darauf. Ein Jahr später durfte ich dieses Team wieder treffen. Und wie hatte es sich entwickelt? Von einem weiteren Wachstum keine Spur! 

Die Effektivität des Teams war massiv gesunken, der Output war deutlich weniger geworden, von Outcome redete gar niemand. Und der positive Spirit des Teams war komplett verschwunden. Im Im wesentlichen war von Scrum geblieben: ein paar nach Scrum Events betitelte Meetings, ein paar Begriffe wie „Product Backlog“ und Reste von Praktiken zur Ausgestaltung von Scrum, z.B. „Stories“.

Vielleicht ist es Zufall, dass ich Teams, bei denen die Selbstabschaffung ihres Scrum Masters erfolgreich war, einfach nicht getroffen habe. Aber wenn es ein Standard-Ziel für Scrum Master sein soll, sich abzuschaffen, müsste das meiner Meinung nach sehr viel häufiger mit Erfolg passieren. Hier interessiert mich deine Perspektive. Hast du so etwas schon erlebt? Wie erfolgreich war es?

Woran liegt das?

Woran liegt es wohl, dass die Scrum Master Abschaffung so schlecht funktioniert? Ein hilfreicher Ansatzpunkt ist die Frage: Wann ist denn konkret der richtige Zeitpunkt gekommen, um sich abzuschaffen? 5 häufiger genannte Kriterien für diesen Zeitpunkt sind:

1. Scrum ist jetzt implementiert
2. Das Team hat jetzt gelernt, zusammenzuarbeiten
3. Es gibt laut Aussage der Developer keine Hindernisse mehr
4. Das Team liefert verlässlich jeden Sprint
5. Es läuft alles perfekt

Spannenderweise beruhen diese Kriterien auf grundlegenden Missverständnissen rund um Scrum und die Natur der Situationen, in denen Scrum hilfreich ist. Und – Im Laufe der Jahre habe ich zu fast jedem dieser Kriterien Teams erlebt, die ab dann keinen Scrum Master mehr hatten, mit jeweils ähnlichen Symptomen. Nur den letzten Fall habe ich bisher nicht selbst erlebt.

Grund #1: Scrum ist jetzt implementiert – Falsch!

Ist deine Aufgabe nicht, Scrum zu „implementieren“? Also kannst du doch weiterziehen, nachdem du allen erklärt hast, wie Scrum funktioniert und alle erfolgreich durch ein paar Sprints gegangen sind.

Das dahinter liegende Missverständnis ist: Der Scrum Master sei eine Art Regisseur, dafür verantwortlich, dass Scrum korrekt aufgeführt wird, wie eine Art Theaterstück. Sobald die Schauspieler das Stück aufführen können, sei die Arbeit des Scrum Masters getan.

Doch so ist es nicht. Sobald das Scrum Team einen Weg gefunden hat, wie sie Scrum in ihrem Kontext umsetzen können, beginnen die Feedback-Schleifen zu laufen. Jetzt beginnt die eigentliche Arbeit – aus dem Feedback erfolgreich zu lernen. Dabei leitet ein guter Scrum Master einen unschätzbaren Beitrag.

Einige typische Symptome eines Teams, das in diesem Moment allein gelassen wird, sind:

• Developer gehen widerwillig zum Daily Scrum.
• In der Retrospektive geht es immer wieder um dieselben Themen.
• Der Review ist nur eine Demo.
• Das Team liefert keinen Wert.

Grund #2: Das Team arbeitet jetzt zusammen – Falsch!

Ist deine Aufgabe nicht, ein sich selbst managendes Team entstehen zu lassen? Also kannst du doch weiterziehen, wenn die Developer sich kennengelernt, gestritten, zusammengerauft und etwas erledigt haben.

Zunächst richtig. Eine einer wichtigen Aufgabe eines Scrum Masters besteht darin, aus einer frisch zusammen gekommenen Gruppe von Menschen ein Team zu formen. Das Missverständnis liegt darin, dass dies erstens weder die einzige Aufgabe eines Scrum Masters ist, noch dass diese Phasen der Team-Bildung nur ein einziges Mal durchlaufen werden.

Einige typische Symptome eines Teams, das in in der Performing-Phase allein gelassen wird, sind:

• Sie wehren sich stark gegen Team-Veränderungen
• Die Kommunikation mit anderen Teams und mit Stakeholdern funktioniert nicht so gut
• Nachdem sich die Team-Zusammensetzung geändert hat, geht der Performance stark runter
• Das Team bleibt bei einmal etablierten Vorgehensweisen

Grund #3: Die Developer sagen, sie haben keine Hindernisse – Falsch!

Ist es nicht die Aufgabe eines Scrum Masters, Hindernisse aus dem Weg zu räumen? Wenn die anderen Teammitglieder nun sagen, sie haben keine Hindernisse mehr, dann hast du dich doch überflüssig gemacht, oder?

Hier zeigen sich gleich mehrere Fehleinschätzungen.

Erstens können Entwickler verblüffend of Hindernisse gar nicht benennen. Sie werden als selbstverständlicher Teil der Arbeit hingenommen. Dass die Hindernisse nicht da sind, können sie sich gar nicht vorstellen.

Zweitens ist es nicht so, dass ein Team ein initiales Set von Hindernissen hat, die einmal weggeräumt werden müssen und das war’s dann. Hindernisse entstehen dynamisch neu bzw. werden erst später relevant. Jedesmal, wenn der aktuell einschränkende Flaschenhals entfernt ist, entsteht woanders ein neuer.

Und drittens kann man nur dort etwas sehen, wo man hinschaut. So decken Teams z.B. allein während meines Standard-Workshops zur Formulierung einer Definition-of-Done oft zehn oder mehr neue, relevante Hindernisse auf, die sie bisher gar nicht auf dem Schirm hatten.

Typische Symptome eines Teams „ohne Hindernisse“:

• Im Daily Scrum werden nie Hindernisse identifiziert
• Das Team hat keine starke Definition-of-Done oder sie wird nicht gelebt
• Das Team hat Vorgehensweisen etabliert, die nun nicht mehr verbessert werden
• Es gibt wenig Kontakt zwischen dem Scrum Master und anderen Führungskräften in der Organisation

Grund #4: Das Team liefert jeden Sprint ein Inkrement – Falsch!

Die Aufgabe eines Scrum Masters ist doch, dafür zu sorgen, dass das Team in jedem Sprint ein Inkrement liefert. Wenn das Team das nun tut, dann “Tschüss!” oder nicht?

Erst einmal – Gratulation, dass ihr so weit gekommen seid! Leider gibt es (viele?) Teams, die nicht in der Lage sind, regelmäßig auszuliefern. Doch auch, wenn dir das im Moment noch weit weg vorkommt, regelmäßig etwas zu liefern sollte nicht das finale Ziel eines Scrum Masters sein.

Zum Verständnis hilft eine Metapher: Ein Team, dass nicht liefern kann, ist wie ein Auto, das im Schlamm feststeckt und nicht von der Stelle kommt. Wenn es sich aus dem Schlammloch befreit hat, wieder fahren kann, dann entspricht das der Fähigkeit, etwas liefern zu können. Nun liegt der hauptsächliche Fokus vieler Teams auf ihrer “Velocity”, ihrer Fahrgeschwindigkeit, oft auch “Output” genannt. 

Gute Scrum Master nutzen nun die Chance, ihrem Team zu vermitteln, wie sie auf relevante “Outcomes” zuzusteuern können. Und sie helfen, die neuen Lernchancen aufzudecken, die sich durch die Lieferfähigkeit des Teams ergeben.

Einige typische Symptome eines Teams, das nach dem Liefern allein gelassen wird:

• Nutzer-Feedback fließt nicht oder nur stark verzögert in die weitere Produktentwicklung ein.
• Im Team ist nicht bekannt, was Benutzer und Kunden wirklich als wertvoll empfinden und woran sie das konkret festmachen.
• Die Lead-Time (vom Commitment „Wir werden das liefern!“ bis zur tatsächlichen Verwendung durch Endnutzer) reduziert sich nicht weiter.

Grund #5: Jetzt läuft alles perfekt – Falsch!

Nun funktioniert wirklich alles perfekt. Das Team liefert fast sofort relevanten Wert in hoher Qualität, bekommt gutes Feedback von seinen Kunden und auch die „Zahlen stimmen“. Dann kann ich mich doch als Scrum Master vom Acker machen, oder?

Das klingt zunächst plausibel. Spannenderweise gibt es andere Umfelder, in denen genau dieselbe Überlegung völlig absurd wäre. So erinnere ich mich noch genau an die Fussballweltmeisterschaft 2014. Deutschland gewann im Endspiel gegen Argentinien. Der Jubel war groß. Die deutsche Mannschaft war die beste der Welt! Trotzdem kommt niemand auf die Idee zu sagen: „Dann ist ja jetzt alles klar. Die wissen, wie es geht. Wer sollte denen noch was sagen? Hiermit hat sich der Bundestrainer erfolgreich abgeschafft.“

Natürlich hinkt der Vergleich mit dem Sport-Coach. Aber trotzdem lässt sich einiges übertragen. Teammitglieder werden das Team verlassen, neue dazu kommen. Plötzlich kommen in der Organisation neue Ideen auf, vielleicht von neuen Führungskräften. Oder unerwartete Dinge passieren, auf die das Unternehmen gar keinen Einfluss hat, z.B. geschieht einfach so eine Corona-Pandemie. Ganz plötzlich gilt es, Probleme zu lösen, die gestern noch nicht auf der Agenda standen: „Wie können wir gut zusammenarbeiten, auch wenn wir nicht in einem Raum sind?“. Auch der mit unsägliche Krieg in der Ukraine kam für viele unerwartet und führt für Unternehmen zu völlig neuen Herausforderungen, von “Wie helfen wir unseren Mitarbeitern durch diese neue Situation” bis hin zu “Wo bekommen wir nun Kabelstränge her?” Die Business-Welt ist heute oft komplex, vielschichtig und hochdynamisch.

Eigentlich steht hinter Grund #5 die falsche Annahme, dass perfektes Funktionieren ein stabiler Zustand ist. Doch so ist unsere komplexen Welt nicht. Hier tun sich kontinuierlich neue Fragen und Herausforderungen auf. Jemand, der es als seine Verantwortung ansieht, immer neu zu hinterfragen, was gerade passiert und was das Team braucht, damit es effektiv und erfolgreich Wert stiften kann, wird nicht überflüssig.

Fazit

Als ernsthaftes, realistisch erreichbares Ziel taugt die Idee „Ich schaffe mich selbst ab!“ also nicht.

Als Coach fällt einem hier vielleicht die Frage ein: “Zu was stattdessen?” Ein interessanter Gedanke! Was könnte Positives in der Idee liegen?
Wie wäre es mit einem stillen Gedankenexperiment. “Was müsste mein Team gut können, damit sie nicht mehr auf mich angewiesen sind?” Oder ganz einfach: “Worauf steuern wir eigentlich derzeit gerade zu? Scrum verstehen, als Team gut zu arbeiten, verlässlich zu liefern?” Und wenn wir da sind (oder auch schon jetzt): “Was für eine Art von Scrum Master braucht mein Team jetzt?”

Denn mit jedem erreichten Teilziel ist ein Scrum Master, der nur fähig ist, sein Team bis dorthin zu führen, tatsächlich überflüssig geworden. Jeder der 5 Gründe in diesem Artikel ist also gleichzeitig eine Einladung an Scrum Master, sich immer wieder neu zu erfinden und weiter zu denken, was für dieses Team noch möglich wäre. Und eine Herausforderung, sich weiterzuentwickeln.

Wenn du nach einer Möglichkeit suchst, das kontinuierlich und eingebettet in deine Arbeit in deinem Team zu tun, dann wirf doch mal einen Blick auf unser Advanced CSM Programm, mit dem du dich auf den Weg zum Certified Scrum Professional machen kannst.

Doch was ist deine Meinung zum Thema? Sollte ein Scrum Master tatsächlich auf das Ziel zuarbeiten, sich nach einer gewissen Zeit überflüssig gemacht zu haben?Habe ich einen wichtigen Gedanken vergessen? Ich bin gespannt auf deine Perspektive.