Was macht ein Scrum Master eigentlich den ganzen Tag?
Diese Frage erreicht mich fast täglich.
Einerseits liegt es wohl daran, dass die Besetzung einer Stelle mit einem Scrum Master für viele Unternehmen noch Neuland ist. Deshalb sind die Verantwortung und Tätigkeit oft sehr unkonkret beschrieben. In manchen Fällen gleichen die Anforderungen denen eines Projektleiters. Andererseits stellen mir Scrum Master selbst diese Frage. Dies zeigt mir, dass die tatsächliche Arbeitsweise von Scrum Mastern wenig bekannt ist.
Deshalb ganz konkret:
Die Aufgabe eines Scrum Masters ist die Verbesserung des Unternehmensergebnisses mithilfe von Scrum.
Was meine ich damit?
Schauen wir uns die Aufgabe eines Scrum Masters im Detail an:
- Mit „Unternehmensergebnissen“ meine ich nicht Agilität. Kein Unternehmen hat das Ziel, agil zu sein. Die Ergebnisse, die Unternehmen erreichen wollen, reichen von „Die Welt verändern“ bis hin zu Gewinnmaximierung. Als Scrum Master müssen wir zunächst diese Ergebnisse verstehen und dann suchen wir nach (neuen) Wegen, diese zu erzielen. Wie gehen wir dabei vor?
- „Mit Scrum“. Ein Scrum Master vertraut beim Verbessern der Unternehmensergebnisse auf Scrum. Ein Scrum Master benutzt andere Werkzeuge als ein Projektleiter. Ein Projektleiter macht Pläne, teilt Arbeit auf und schaut, ob das Ergebnis gut ist. Ein Scrum Master nutzt die Werkzeuge, die ihm das Scrum Rahmenwerk zur Verfügung stellt. Diese lauten im Kern: empirische Arbeitsweise, Selbstmanagement und Scrum Werte.
Wenn die Verbesserung der Unternehmensergebnisse die Aufgabe eines Scrum Masters ist, wie geht er dabei vor?
Betrachten wir dazu den Scrum Guide:
- „Scrum Master sind echte Führungspersönlichkeiten, die dem Scrum Team und der Gesamtorganisation dienen.“
- „Der Scrum Master dient dem Scrum Team [...] dadurch, dass er die Beseitigung von Hindernissen (Impediments) für den Fortschritt des Scrum Teams bewirkt.“
Diese beiden Passagen liefern uns eine Antwort:
Möchtest du die Ergebnisse deines Unternehmens verbessern, dann beginne bei deinem Team und hilf ihm, Hindernisse zu beseitigen.
Wie das aussieht, zeige ich dir an einem Beispiel von mir.
Erfahrungsbericht: Das Scrum Team ohne Sprint-Ziel
Vor einigen Jahren habe ich eine Stelle als Scrum Master angenommen.
Die ersten beiden Wochen habe ich nur das Team bei der Arbeit beobachtet. Hier einige meiner Beobachtungen von damals:
- Es gibt Analysten, Backend- und Frontend-Entwickler im Team.
- Die Entwickler berichten dem Interims Scrum Master, woran sie gestern gearbeitet haben.
- Der Product Owner diskutiert mit den Entwicklern die erledigte Arbeit im Detail.
- Der Technologie-Stack, der für die Anwendung genutzt wird, ist sehr modern.
- Die User Stories gleichen technischen Aufgaben und beschreiben nicht die Wünsche oder Probleme von Nutzern.
- Die Entwickler nutzen einen „Test Driven Development“-Ansatz beim Entwickeln.
- Die Stakeholder fragen sich, woran das Team eigentlich im Geheimen seit einem Jahr arbeitet.
- Im Sprint Review sind keine Personen außerhalb des Scrum Teams anwesend.
Diese Beobachtungen habe ich in vielen Scrum Teams gemacht – aufgrund meiner Erfahrung als Scrum Master und indem ich den Scrum Guide noch einmal Zeile für Zeile durchging und mir Abweichungen notierte.
Nachdem ich Transparenz über die aktuelle Arbeitsweise hergestellt hatte, habe ich mir die Frage gestellt, was das Scrum Team daran hindert, Fortschritte zu erzielen und Ergebnisse für das Unternehmen zu erreichen.
Dazu habe ich die Beobachtungen sortiert und gruppiert. Hier einige Hindernisse, auf die ich gestoßen bin:
- Das Team ist kein Team, da es kein gemeinsames Ziel verfolgt.
- Die Entwickler arbeiten nicht zusammen, sondern koordinieren nur die Zusammenarbeit und dann arbeitet jeder für sich.
- Die Stakeholder erkennen nicht den Fortschritt des Teams.
Das größte Hindernis lautete damals:
Das Hindernis: Das Team hat kein gemeinsames Ziel
Jetzt kommt ein wichtiger Teil:
Als Scrum Master vertrauen wir auf empirisches Arbeiten. Das bedeutet: Bevor wir uns daran machen, nach Lösungen für ein Hindernis zu suchen, müssen wir festhalten, woran wir erkennen, dass das Hindernis beseitigt ist!
Empirisches Arbeiten bedeutet, in Hypothesen zu denken. Wie ein Wissenschaftler müssen wir eine Hypothese formulieren, bevor wir ein Experiment durchführen, um die Hypothese zu bestätigen oder zu widerlegen. Anders ausgedrückt: Woran erkennen wir, ob das Hindernis beseitigt wurde?
Damals habe ich mir Folgendes gedacht:
- Das Scrum Team definiert gemeinsam im Sprint Planning ein Ziel, das es am Ende des Sprints erreicht haben will.
- Das Scrum Team nutzt das Sprint-Ziel im Daily Scrum, um seine Arbeit für den heutigen Tag zu planen.
- Das Scrum Team bespricht das Ziel des Sprints im Sprint Review mit mindestens einem Stakeholder.
Damit lautet die Hypothese:
- Ich habe beobachtet, dass das Team kein gemeinsames Ziel eint und die Stakeholder keinen Fortschritt des Teams erkennen können.
- Ich glaube, ein Sprint-Ziel wird dieses Hindernis beseitigen.
- Ich liege richtig, wenn ich innerhalb der nächsten drei Sprints ein Scrum Team sehe, das im Sprint Planning ein Sprint-Ziel formuliert, es während des Sprints weiterverfolgt und im Sprint Review mit einem Stakeholder die Erreichung des Ziels bespricht.
Bei der Lösung dieses Hindernisses nutzte ich die Scrum-Master-Haltung von Barry Overeem.
Barry hat im Jahr 2016 ein Whitepaper veröffentlicht, in dem er die Arbeit eines Scrum Masters aus unterschiedlichen Blickwinkeln betrachtet. Du findest die Details hier. Wenn du dir die Haltungen nicht im Selbststudium aneignen möchtest, dann empfehle ich dir den Besuch meines „Professional Scrum Master 2“-Trainings. Dort widmen Marc Kaufmann und ich uns diesen Haltungen zwei volle Tage. Mehr noch: Du bekommst auch viele Werkzeuge an die Hand, wie du Haltungen in deinem Alltag als Scrum Master einsetzen kannst.
Ich habe die Lösung des Hindernisses, dass das Team kein gemeinsames Ziel eint und die Stakeholder keinen Fortschritt des Teams erkennen können, durch die unterschiedlichen Haltungen betrachtet.
Hier meine Gedanken von damals:
Scrum-Master-Haltung: Der Lehrer
Die Haltung eines Lehrers bedeutet, dem Scrum Team die Elemente des Scrum Rahmenwerks zu erklären und außerdem, wie es ihnen hilft, in komplexen Umgebungen effektiv zu sein.
Als Lehrer betrachte ich das Hindernis und könnte ein Scrum Training durchführen. Dabei könnte ich unterschiedliche Schwerpunkte wählen:
- Schwerpunkt „Scrum Rahmenwerk“: Ich könnte ein Training durchführen, in dem ich alle Elemente von Scrum erkläre und aufzeige, wie sie zusammenspielen. Vom Team könnte ich die Konsequenzen erarbeiten lassen, wenn ein Element fehlt.
- Schwerpunkt „Sprint-Ziele“: Ich könnte auch ein Training durchführen, in dem das Team lernt, wie es Sprint-Ziele formulieren kann.
Scrum-Master-Haltung: Mentor
Die Haltung eines Mentors bedeutet, den Mitgliedern des Scrum Teams zu helfen, durch Mentoring zu wachsen oder für sie geeignete Mentoren zu finden.
Aus dieser Perspektive könnte ich dem Product Owner von meiner Erfahrung berichten. Ich würde ihm erzählen, wie ich als Product Owner die Sprint-Ziele gehandhabt habe. Dabei würde ich die Kontrolle über die Richtung des Sprints behalten, auch wenn das Sprint Backlog ausschließlich in der Hand der Entwickler liegen würde. Alternativ könnte ich auch jemanden von einem anderen Scrum Team einladen, der gute Erfahrungen mit Sprint-Zielen gemacht hat, und ihn bitten, diese mit unserem Team zu teilen.
Scrum-Master-Haltung: Coach
Die Haltung eines Coaches bedeutet, das Team dabei zu unterstützen, zu wachsen – ohne dabei meine Erfahrung oder mein Wissen zu präsentieren, sondern etwa indem ich die richtigen Fragen stelle und auf die Gründe für einen empirischen Prozess aufmerksam mache.
Als Coach auf das Hindernis blickend, könnte ich im nächsten Sprint Planning offene Fragen stellen, zum Beispiel:
- Was sollte sich nach diesem Sprint aus der Sicht unserer Stakeholder deutlich verändert oder verbessert haben?
- Was müsste während der Arbeit in diesem Sprint passieren, damit wir Grund zum Feiern hätten?
Scrum-Master-Haltung: Facilitator
Die Haltung eines Facilitators bedeutet, dem Team zu helfen, seine Arbeit transparent zu machen, seine Fortschritte regelmäßig zu überprüfen und Anpassungen auf der Grundlage neuer Erkenntnisse vorzunehmen.
Aus diesem Blickwinkel könnte ich eine Umfrage unter den Stakeholdern durchführen, welches Feedback sie für unser Team hätten. Ich könnte etwa die Frage stellen: „Was würdet ihr euch von unserem Team wünschen, damit ihr eure eigene Arbeit noch besser erledigen könnt?“ Ich könnte auch einige Stakeholder in die Sprint-Retrospektive einladen, damit wir gemeinsam den aktuellen Sprint überprüfen können und nach Verbesserungsideen suchen können.
Die unterschiedlichen Haltungen eines Scrum Masters liefern verschiedene Herangehensweisen, wie ich mich der Beseitigung des Hindernisses nähern kann.
Welche Haltung habe ich gewählt?
Damals habe ich mich zunächst für den Lehrer entschieden und ein einstündiges Training in Scrum mit dem Team durchgeführt. Im Training lag mein Fokus auf der Erklärung der Scrum Elemente. Ich habe dargestellt, wie diese Elemente zusammenhängen. Ich habe betont, dass sie nur gemeinsam empirisches Arbeiten ermöglichen. Im zweiten Schritt schlüpfte ich in die Rolle des Coaches. Ich stellte offene Fragen im Sprint Planning. Das Ziel war, zu verhindern, dass der Zweck dieses Sprints in Vergessenheit gerät.
Die Aufgabe eines Scrum Masters ist es, Verbesserungen von Unternehmensergebnissen mithilfe von Scrum herbeizuführen. Ein guter Startpunkt dafür ist, Hindernisse zu beseitigen, die das Scrum Team daran hindern, Fortschritte zu erzielen. Erreicht das Scrum Team seine Ziele, dann sollte sich dies auch positiv auf die Ergebnisse auswirken. In meiner Situation hatte das Scrum Team noch keine Ziele, und deshalb war dies das erste Hindernis, welches es zu beseitigen galt.