Scrum Master für mehrere Teams: So skalierst du, ohne dich dabei unwohl zu fühlen
Scrum Master in einem Team zu sein, stellte für mich die Norm dar.
Auch alle Scrum Master in meinem Umfeld waren nur Teil eines Teams. Deshalb stand für mich außer Frage: Ein Scrum Master kann nur ein Team unterstützen. Dieser Glaube wurde auch durch eine meiner ersten Scrum-Schulungen bestätigt, als der Trainer sagte:
„Ein guter Scrum Master kann mehrere Teams begleiten, ein großartiger Scrum Master kann ein Team begleiten.“
Im Jahr 2018 stellte ich mich als Scrum Master für ein großes Projekt bei der Bundesagentur für Arbeit in Nürnberg vor. Drei Teams arbeiteten an einem Produkt und ich sollte eines davon coachen.
Am ersten Tag im Projekt verbrachte ich den Vormittag damit, die Daily Scrums der drei Teams im Kalender so zu jonglieren, dass ich alle drei besuchen konnte. Am Morgen hatte ich herausgefunden: Ich bin der einzige Scrum Master im Projekt. Als ich eine Lösung gefunden hatte, war ich stolz und zeigte sie meinem Teamkollegen. Er warf einen kurzen Blick auf meinen Outlook: „Donnerstag können wir nicht um 9:30 Uhr, da ist ein Architektur-Meeting. Ach, und Montag kann ich auch nicht, da gehe ich gerne zur Projektrunde.“ Den restlichen Tag versuchte ich, eine Lösung zu finden, aber um 17:00 Uhr gab ich mein Kalender-Tetris auf.
Um 9:30 Uhr am nächsten Tag moderierte ich mit einem unguten Gefühl nur das Daily Scrum meines Teams. Danach traf ich im Gang einen Entwickler eines anderen Teams. Ich hatte das Bedürfnis, mich zu entschuldigen und zu rechtfertigen, dass ich sein Team nicht unterstützen konnte, und fragte:
„Wie seid ihr im Daily Scrum zurechtgekommen?“
Er erwiderte: „Eigentlich gut. Ach, hättest du vielleicht eine Idee, wie wir etwas weniger Zeit brauchen? Ging mal wieder 20 Minuten.“
„Natürlich“, sagte ich. Dann erklärte ich ihm, warum sie die Spalten des Sprint-Backlogs von rechts nach links durchgehen sollten.
Am nächsten Nachmittag berichtete er mir, dass er meinen Tipp umgesetzt hatte und das Daily jetzt besser gelaufen war.
An diesem Tag erkannte ich zum ersten Mal, dass Scrum Master auch mehr als ein Team unterstützen können. Damit wir allerdings weiterhin großartige Arbeit leisten können, müssen wir unsere Art und Weise, wie wir arbeiten, anpassen.
Das erste, was wir benötigen, um unsere Wirkung als Scrum Master zu potenzieren und mehrere Teams gleichzeitig betreuen zu können, ist eine nachhaltige Art, Wissen weiterzugeben: das Unterrichten.
Skalierung durch Training
Anstatt selbst die Arbeit zu übernehmen, unterrichten wir andere darin, die Arbeit zu machen.
Training muss dabei nicht immer formal sein. Im Projekt bei der Bundesagentur für Arbeit habe ich einzelnen Entwicklern Tipps gegeben, wie sie das Daily Scrum ihres Teams verbessern können. Dem Product Owner habe ich erklärt, was bei der Planung des Sprints wichtig ist. Und ich habe kurze Sessions durchgeführt, in denen ich ein Format für die Retrospektiven vorgestellt habe.
Seither gehören Schulungen in den Grundlagen über Scrum zum festen Bestandteil meiner Arbeit als Scrum Master. Schulungen zu halten stellt einen großen Hebel dar, um Scrum-Wissen über die Grenzen des Teams hinaus zu skalieren.
Ich will ehrlich mit dir sein: Trainings nach kognitiven neurowissenschaftlichen Prinzipien zu gestalten – also so, dass die Teilnehmer langfristig lernen –, ist eine Wissenschaft für sich.
Deshalb will ich dir die gleiche Abkürzung verraten, die ich auch den Teilnehmern meiner „Training from the Back of the Room“-Schulung vermittle:
Halte es einfach. Konzentriere dich beim Entwerfen deiner Schulungen darauf, diese vier Fragen zu beantworten:
- Was wissen die Teilnehmer bereits über das Thema?
- Was müssen sie noch über das Thema lernen?
- Wie können die Teilnehmer das neue Wissen anwenden oder andere darin unterrichten?
- Wie wollen die Teilnehmer ihr neues Wissen in Zukunft anwenden?
Die Beantwortung der Fragen liefert dir eine Karte für die Durchführung deiner Schulung.
„Training from the Back of the Room“-Anwender nennen diese Karte die 4Cs-Map. (Mehr Hintergrundinformation zum „Training from the Back of the Room“ gibt es hier.)
Eine weitere Möglichkeit, deine Arbeit als Scrum Master zu skalieren, stellen für mich Communities-of-Practice dar.
Skalierung durch Communities-of-Practice
„Willst du schnell gehen, geh allein. Willst du weit kommen, geh in Gemeinschaft.“
Klingt wie ein Kalenderspruch. Allerdings hat er sich das eine oder andere Mal bewahrheitet, wenn es um Veränderung in Unternehmen geht. Deshalb: Wenn du als Scrum Master deine Wirkung skalieren willst, dann verbinde dich mit den anderen Scrum Mastern im Unternehmen. Dafür eignen sich besonders gut Communities-of-Practice.
In dieser Gemeinschaft könnt ihr euch fragen:
Welche Maßnahmen und Initiativen investieren wir im Moment, um unser Unternehmen mit Scrum erfolgreicher zu machen?
Maßnahmen zur Veränderung sollten wir uns hierbei nicht als linearen Prozess vorstellen. Realistischer ist es, dabei von einem Zyklus auszugehen. Es kann z.B. sehr anschaulich sein, sich dabei am Lebenszyklus von Pflanzen zu orientieren. (Die Idee des „Ecocycle Plannings“ stammt von Keith McCandless und Henri Lipmanowicz).
Dieser sieht grob so aus:
Fällt ein Samenkorn in fruchtbaren Boden, so keimt es (Erneuerung). Die Keimlinge benötigen wiederum ausreichend Sonne, Wasser, Schutz und Mineralien, um zu wachsen (Wachstum). Wenn diese Bedingungen erfüllt sind, wachsen die Keimlinge zu Pflanzen heran, die Früchte tragen und neue Samen verbreiten (Reifung). Doch irgendwann sterben die alten Pflanzen ab und werden kompostiert, um Energie für neue Pflanzen zu gewinnen. Dadurch wird Platz geschaffen, damit neue Pflanzen aus den Samen im Boden wachsen können (kreative Zerstörung).
Dieser Prozess lässt sich visualisieren:
Hierauf könnt ihr gemeinsame Aktivitäten und Initiativen abbilden und Einsichten erhalten, welchen Wert sie stiften. Diese Fragen sind gute Startpunkte für den Austausch in der Community of Practice:
- Welche Aktivitäten wollen wir voranbringen?
- Und welche Aktivitäten wollen wir stoppen?
Es gibt aber noch weitere Wege, unsere Wirkung als Scrum Master zu skalieren:
Skalierung durch Delegieren
Noch einmal zurück zu meiner Zeit in Nürnberg bei der Bundesagentur für Arbeit und den drei Scrum-Teams.
Eine Erkenntnis, die sich daraus ergab: Scrum Master können ihre Wirkung skalieren, indem sie unterrichten, anstatt alles selbst zu machen. Es gab noch eine weitere Erkenntnis, die mir allerdings erst Jahre später bewusst wurde.
Dadurch, dass ich nicht mehr jedes Daily Scrum, jede Retrospektive, jedes Sprint Planning begleiten konnte, übertrug ich die Verantwortung der Durchführung auf andere. Ich wechselte von „selbst Verantwortung übernehmen“ zu „Verantwortung auf andere übertragen“. Ich delegierte also.
Das Problem war nur: Es geschah unwissentlich. Es geschah auch eher unfreiwillig. Und ich fühlte mich nicht sonderlich wohl damit.
Eine Methode, mit der wir uns beim Delegieren wohlfühlen, habe ich erst später entdeckt: Die sieben Level von Delegation aus dem Management 3.0.
Hier eine Übersicht der Level:
- Verkünden
- Verkaufen
- Befragen
- Einigen
- Beraten
- Erkundigen
- Delegieren
Ich bin damals direkt vom Selbermachen zur vollen Delegation übergegangen. Das Modell zeigt, dass es auch noch Schritte dazwischen gegeben hätte. Etwa hätte ich die Teams fragen können, wie wir mit der Situation umgehen sollten. Das entspräche dem „Befragen“ im Modell. Oder wir hätten gemeinsam entscheiden können. Das entspräche dann der „Einigung“.
Das Delegieren ist ein sehr wichtiger Schritt, um als Scrum Master zu skalieren und mehrere Teams zu betreuen. Gerade deshalb sollte der Delegationsprozess bewusst eingeleitet werden und geführt ablaufen.
Ich bin mir sicher, mit diesem schrittweisen Vorgehen hätte ich mich viel wohler damit gefühlt, Teile meiner Aufgaben zu delegieren.
