Day in a Life: Die erste Woche als Scrum Master in einem neuen Team

Was macht eigentlich ein Scrum Master in der ersten Woche in einem neuen Team?

Es wird viel über Scrum geschrieben. Allerdings findet sich über dieses spezielle Thema nichts. Glücklicherweise kann ich dir helfen. Ich war bereits drei Mal in dieser Situation.

Wenn du weiterliest, wirst du einen Einblick in meine erste Woche als Scrum Master in einem neuen Team erhalten.

Bild: Midjourney (von einer KI erzeugt)

Beobachtung des Teams bei der Arbeit, um die Abläufe zu verstehen

Beobachten, beobachten und beobachten.

Das ist mein Mantra in der ersten Woche mit einem neuen Team. Handelst du als Scrum Master verfrüht, hinderst du das Selbstmanagement des Teams eher, als dass du es förderst. Deshalb verschaffe ich mir zuerst Zugang zu so vielen Informationen wie möglich. Hierzu gehören Sprint-Berichte, Zugang zu Wiki-Seiten, Working Agreements und natürlich das Product Backlog.

Im Anschluss analysiere ich diese Informationen. Mein Ziel ist es, zu verstehen, wie das Team arbeitet.

Dann geht es ans Tagebuchschreiben.

Ja, du hast richtig gelesen. Ich führe in den ersten Wochen ein Tagebuch darüber, wie das Team arbeitet. Dazu begleite ich die Teammitglieder zu jedem Scrum Event, Refinement, Meeting und bei der täglichen Entwicklungsarbeit und protokolliere ihre Arbeitsweisen. Das Schreiben verlangsamt mein Denken und hilft mir, keine voreiligen Schlüsse zu ziehen. In dieser Phase meiner Arbeit geht es ausschließlich um die Beobachtung und das Festhalten von Fakten.

Ein gut geführtes Tagebuch hilft mir später, Verbesserungsmöglichkeiten zu identifizieren. Dazu gleiche ich das Protokoll mit dem Scrum Guide ab. Die Abweichungen liefern einen guten Anhaltspunkt für Verbesserungsmöglichkeiten.

Die einzelnen Teammitglieder treffen, um alle persönlich kennenzulernen

Scrum Master sollten auf 1:1-Meetings verzichten.

Einzelgespräche schmälern die Transparenz. Werden Informationen nur zwischen zwei Personen ausgetauscht, fehlen sie dem Team. Somit hat das Team kein umfassendes Bild der Situation. Dies braucht es allerdings, um bestmöglich Entscheidungen zu treffen. Deshalb verzichte ich auf Einzelgespräche. Mit einer Ausnahme: beim ersten Kennenlernen.

Um das Eis zu brechen und eine Grundlage für eine vertrauensvolle Zusammenarbeit zu legen, haben sich Einzelgespräche bewährt.

Um ein Einzelgespräch zu strukturieren, verwende ich entweder Interviewfragen oder eine „Personal Map“.

Diese Liste von Interviewfragen hilft mir, mehr über die andere Person zu erfahren:

• Welche Rolle hast du im Team? Bekleidest du noch andere Rollen innerhalb des Unternehmens?
• Was ist deine Kompetenz? Weshalb kommen die Leute zu dir?
• Wie sieht die derzeitige Arbeitsweise des Teams aus? Kannst du mir einen typischen Arbeitstag von dir beschreiben?
• Woran machst du den Erfolg des Teams fest? Kannst du mir bitte eine Anekdote davon erzählen?
• Wie denkst du über Scrum und Agilität?
• Gibt es eine Sache, bei der ich dir im Moment helfen kann?

Eine Alternative zu einem Interview ist die „Personal Map“. Die „Personal Map“ stammt aus Management 3.0. Die Idee ist, eine Mindmap einer Person zu erstellen.

• Ausgangspunkt der Mindmap ist der Name. Er kommt prominent in die Mitte des Blattes.
• Rundherum werden Informationen zur Familie, Zielen und Hobbys gesammelt.
• Wie bei jeder Mindmap werden diese Informationen in Blasen um den Namen angeordnet und mit Linien verbunden.

Jetzt kommt der wichtige Punkt. Die „Personal Map“ kann jeder der Teilnehmer im Einzelgesräch für sich erstellen, aber nur das Gegenüber darf sie vorstellen! Beim Kennenlernen geht es darum, mehr über den anderen zu erfahren. Gemeinsamkeiten und Gegensätze zu erkunden. Stellst du die Map deines Gesprächspartners vor, dann entstehen Fragen. Die Beantwortung der Fragen mündet in einem Gespräch über das Leben dieser Person. Und darum geht es am Ende bei diesem Treffen.

Interviewfragen und „Personal Maps“ helfen mir, das Wichtigste beim Kennenlernen nicht zu vergessen: Interesse am anderen zu zeigen!

Klärung der gegenseitigen Erwartungen, um eine Grundlage für die Zusammenarbeit zu schaffen

Den größten Fehler begehen Scrum Master am Anfang.

Das Resultat: Sie enden als Meeting-Moderator oder Feel-Good-Manager. Der Fehler: Sie klären nicht gleich, was jeder von der Zusammenarbeit erwarten kann. Ich habe diesen Fehler am Anfang leider auch gemacht. Ich habe einfach meine Arbeit aufgenommen. Als ich mich dann geweigert habe, das Daily Stand-up zu moderieren, wurde mir vorgeworfen, ich mache meine Arbeit nicht.

Um nicht mehr als Meeting-Moderator oder Feel-Good-Manager zu enden, führe ich einen Workshop zur Klärung der gegenseitigen Erwartungen durch.

Er besteht aus drei Teilen:

1. Die Mitglieder des Teams formulieren ihre Erwartungen an den Scrum Master.
2. Der Scrum Master erläutert, wie er die Verantwortung im Scrum Team mit Leben füllen will.
3. Das Team einigt sich auf grundlegende Punkte der Zusammenarbeit.

Bei Schritt zwei ist mir wichtig, zu betonen: „Meine Aufgabe als Scrum Master ist, das Team zu unterstützen, damit wir unser Ziel erreichen. Ich bin nicht der Meeting-Moderator oder Feel-Good-Manager des Teams. Wenn ihr vor Fragen und Problemen steht oder einfach nur jemanden benötigt, der euch unterstützt, kommt sofort auf mich zu. Ich komme auch nicht von der Scrum-Polizei und nehme einen Haufen unnötiger Änderungen an eurer Arbeitsweise vor, nur damit die Regeln des Scrum Guides erfüllt werden. Stattdessen möchte ich verstehen, wie ihr arbeitet. Und wir überlegen gemeinsam, welche Veränderungen euch helfen, die Arbeit zu vereinfachen und die Kunden zu begeistern.“

Dass ich nicht die Scrum-Polizei spielen werde, irritiert die Teammitglieder häufig. Es ist mir wichtig, zu betonen, dass wir über alles reden und alles verändern können, aber ich Scrum Master bin und meine Arbeit auf den Grundsätzen von Scrum basiert. „Wenn ihr keine Retrospektiven mehr macht, nehmt ihr mir meine Werkzeuge weg. Wie ein Schreiner, der keine Säge hat, keinen hochwertigen Tisch herstellen kann, kann ich euch auch nicht helfen, ohne mein Werkzeug. Die Grenze der Zusammenarbeit ist erreicht, wenn diese rote Linie überschritten wird:

• Wenn ihr nicht mehr empirisch arbeiten wollt, kann ich euch nicht mehr helfen.
• Wenn Meinungsverschiedenheiten persönlich sind und Menschen im Team verletzt werden, greife ich sofort ein.“

Die Erwartungen vorab zu klären, hilft Scrum Mastern im Unternehmen, ihre Rolle so zu füllen, dass wirklicher Mehrwert entsteht.

Das Produkt verstehen, um dem Team mit Scrum zu helfen

Warum arbeitet das Team mit Scrum?

Scrum ist ein Rahmenwerk, mit dem empirisch Wege gefunden werden, um ein Produkt zu entwickeln, das seine Kunden und Nutzer begeistert und Wert für das Unternehmen generiert. Fassen wir diese Definition als Gleichung auf, dann enthält sie viele Variablen. Die Variablen lauten: Produkt, Kunden, Nutzer, Wert und Unternehmen. Um Scrum bestmöglich nutzen zu können, müssen alle diese Variablen verstanden werden. Und das ist gemeint, wenn der Scrum Guide von einem Produkt spricht.

Zusammengefasst: Als Scrum Master muss ich das Produkt unseres Teams sehr gut verstehen. Nur so kann ich dem Team wirklich helfen.

Zwei Aktivitäten, die mir dabei immer geholfen haben:

Ich bitte den Product Owner, mir einen Überblick über das Produkt zu geben. Hierbei stelle ich diese Fragen:

• Wie lautet die Vision oder lauten die aktuellen Ziele des Produkts?
• Könntest du mich anhand einer User-Journey durch das Produkt Backlog führen?
• Woran erkennst du, dass das Team erfolgreich ist?

Die Erklärungen des Product Owners stellen die Innensicht auf das Produkt dar. Ich interessiere mich aber auch für die äußere Wahrnehmung. Deshalb führe ich als zweite Aktivität Interviews mit den Nutzern des Produkts durch. Einige typische Fragen lauten:

• Erzählen Sie mir ein wenig über das Produkt?
• Wofür verwenden Sie es?
• Was gefällt Ihnen daran? Können Sie mir ein Beispiel nennen?
• Was stört Sie daran? Können Sie mir ein Beispiel nennen?
• Wenn Sie einen Zauberstab schwingen und etwas an diesem Produkt ändern könnten, was wäre das?
• Stellen Sie sich vor, Sie hätten diese Änderung. Wie würden Sie sie nutzen?
• Wie erledigen Sie heute Dinge ohne diese Funktion?

Nur wenn Scrum Master das Produkt verstehen, können sie dem Team helfen, es empirisch weiterzuentwickeln.

Neben Interviews gibt es noch viele weitere Techniken, die dir helfen, das Produkt besser zu verstehen. Wenn du mehr darüber erfahren möchtest, dann empfehle ich dir den Besuch meines nächsten „Professional Scrum Product Owner“-Trainings.

Die Grenzen des Teams überblicken, um das Unternehmen besser zu verstehen

Wie bin ich als Scrum Master wirkungsvoll?

Der Scrum Guide beschreibt das Produkt als ein Vehikel, um Wert zum Nutzer zu liefern. Allerdings lebt dieses Vehikel nicht im luftleeren Raum. Es ist eingebettet in ein Unternehmen. Und dieses gilt es, als Scrum Master zu verstehen. Begreife ich als Scrum Master meine Verantwortung nicht als Meeting-Moderator oder Scrum-Polizist, werde ich den größten Teil meiner Arbeit außerhalb des Scrum Teams verbringen. Nur dort kann ich meine Wirkung voll entfalten und Änderungen bewirken, die meinem Team helfen, besser zu arbeiten.

Die Grundlage für diese Arbeit als Change-Agent ist, die Stakeholder des Teams zu identifizieren und kennenzulernen. Die Stakeholder des Teams sind alle Personen, die direkt oder indirekt Auswirkungen auf das Team haben können. Es handelt sich häufig um Manager aus den Abteilungen Marketing, HR, Finance, Betrieb, disziplinarische Führungskräfte oder Mitglieder anderer Teams.

In großen Unternehmen ist dies eine endlose Liste.

Deshalb fange ich damit bereits in der ersten Woche an. Das Gespräch mit dem Produkt Owner oder ein Blick auf das Org-Chart reichen, um damit zu beginnen. Aufgrund eigener Erfahrungen mit kritischen Betrachtungen meiner Arbeit als Scrum Master bin ich bei diesen Gesprächen sehr vorsichtig. Ich versuche mich von Minute eins an auf den Gesprächspartner einzulassen und seine Sicht auf das Unternehmen zu verstehen.

Dabei helfen mir diese Fragen:

• Was ist deine Rolle im Unternehmen? Was sind deine Ziele?
• Was ist deine Vision für dieses Team? Wie sieht aus deiner Sicht Erfolg für das Team aus?
• Was sind deine größten Sorgen in Bezug auf das Team?
• Was erwartest du von einem Scrum Master? Welche Rolle spiele ich in deinen Augen für den Erfolg des Unternehmens?
• Was ist dein größtes Problem, bei dem du jetzt gerne Hilfe hättest?
• Wie denkst du über Agilität und Scrum?
• Mit wem sollte ich noch sprechen, um mehr über die Arbeit des Teams zu erfahren?

Da Org-Charts meistens veraltet sind oder die Realität eines Unternehmens nicht gut abbilden, ist die letzte Frage wichtig. Sie hilft, weitere Stakeholder des Teams zu identifizieren.

Die Informationen verwende ich dann, um eine Stakeholder-Karte des Teams anzufertigen.

• In die Mitte schreibe ich den Namen des Teams.
• Und rundherum die Namen der Stakeholder und relevante Informationen.

Um als Scrum Master wirkungsvoll zu arbeiten, hilft die Stakeholder-Karte, um Allianzen zu schmieden. Wirkungsvolle Veränderungen im Unternehmen zu gestalten, ist ein Teamsport. Leider müssen die Mitglieder, die du dafür im Team haben willst, erst angeworben werden.

Erstellung eines Scrum-Master-Backlogs, um für Transparenz zu sorgen

Der Scrum-Master-Backlog enthält keine Hindernisse!

Am Ende dieser ersten Woche beginne ich damit, einen Scrum-Master-Backlog zu erstellen. Ich verwende hierfür gezielt nicht das gängige Wort „Hindernis-Backlog“. Die wichtigste Aufgabe eines Scrum Masters ist, für Transparenz zu sorgen. Transparenz entsteht, wenn die Dinge sichtbar und verständlich sind. Das gilt auch für die eigene Arbeit als Scrum Master. Die Veränderung im Unternehmen ist ein Teamsport. Wollen Stakeholder wirklich in meinem Team spielen, wenn sie etwa ihren Namen in meinem Backlog für Hindernisse lesen können?

Beim Befüllen des Backlogs gehe ich in drei Schritten vor:

1. Ich schaue durch meine Notizen und betrachte die Beobachtungen. Dabei versuche ich Muster zu erkennen. Diesen Mustern gebe ich dann thematische Namen.
2. In einem zweiten Schritt gehe ich daran, die Auswirkungen dieser Themen auf den Team- und Unternehmenserfolg einzuschätzen.
3. Dann überlege ich mir einige Optionen, wie ich dem Team vorschlagen kann, wie wir diese Verbesserungen angehen könnten.

Dieses Vorgehen nenne ich das BAV-Framework. Die daraus resultierende Liste ist erst mal kein Backlog, da sie nicht geordnet ist. Die Priorisierung nehme ich dann gemeinsam mit dem Team vor. Etwa in einem Workshop in der nächsten Woche.

Wie gestaltest du deine erste Woche als Scrum Master in einem neuen Team? Schreibe es in die Kommentare!