Neu als Scrum Master? Wie Dir der Start gelingt!

„Und jedem Anfang wohnt ein Zauber inne…“. Vielleicht fühlst Du Dich auch so, bevor Du das erste Mal in eine Scrum Master Rolle schlüpfst. Gefühlt endlich in einer modernen Arbeitsform angekommen. Vermutlich hast Du vorher andere Rollen ausgefüllt, kommst vielleicht aus dem klassischen Projektmanagement, vielleicht aus der Softwareentwicklung, vielleicht auch aus einem ganz anderen Bereich. Eine Scrum Master Basisschulung hast Du sicherlich gerade absolviert und nun bist Du nominiert worden zum ersten Mal ein Team als Scrum Master zu begleiten. Dailies, Sprint Plannings, Backlogs, Reviews und Retros - alles im Rahmen der Schulung gelernt und grundsätzlich bekannt. „Aber wie konkret fange ich denn jetzt an?“, magst Du Dich fragen. Die Praxis ist dann ja doch etwas anderes als Theorie und Schulung. Ein junger Scrum Master sagte mir kürzlich und kurz nach Start in seiner ersten Scrum Master Rolle, er habe das Gefühl vor lauter Bäumen den Wald nicht mehr zu sehen. Ich glaube, das Gefühl hatten wir alle schon mal, wenn wir neu in einer Rolle waren und etwas zu ersten Mal gemacht haben - und auch noch beim zweiten, dritten und vierten Mal können da immer noch mehr Bäume als Wald sein.  

Mir hilft es immer, mir vor dem Start in einem neuen Team bewusst Ziele für die erste Woche zu setzen. Und ehrlich gesagt sind das für Woche 1 auch gar nicht so viele Ziele. Niemand erwartet Wunderdinge von Dir, meist hat man ja selber ohnehin höhere Erwartungen an sich selbst, als dass andere sie an einen haben.

Die Ziele für die erste Woche als Scrum Master in einem neuen Team hängen natürlich stark davon ab, in welchem Setting man sich befindet. Kommst Du als Scrum Master ein existierendes Scrum Team, das bereits seit einiger Zeit zusammenarbeitet? Oder wird ein neues Scrum Team aufgesetzt, in dem die Teammitglieder aber bereits über ausreichend Scrum-Erfahrung verfügen? Oder wird ein neues Team aufgesetzt, für das Scrum und Agilität absolutes Neuland sind? Oder, oder, oder… . Je nach Fall liegt Dein Fokus als Scrum Master etwas anders und Deine konkreten Ziele für die erste Woche können unterschiedlich sein. Wenn Du neu in der Rolle als Scrum Master bist, ist die Wahrscheinlichkeit am größten, dass Du in einem existierenden Scrum Team startest, das bereits über Erfahrung im agilen Arbeiten verfügt. Für diesen Fall möchte Dir ein paar Impulse geben, die für Dich Ziele in Deiner ersten Woche sein könnten.

#1 - Das Team beobachten um Abläufe und Teamdynamik zu verstehen

Als Neuzugang in einem Team sollte man sich ohnehin nicht an Tag 1 in den Vordergrund drängen. Die meisten Menschen sind auch so gestrickt, dass sie das ohnehin nicht tun. Als neuer Scrum Master in einem existierenden Scrum Team hilft es am Anfang bewusst einen Schritt zurückzutreten und die Beobachterrolle einzunehmen. Eine Deiner Kernaufgaben als Scrum Master ist die Teamentwicklung, immer das Ziel vor Augen habend, Deinem Team dabei zu helfen effektiver zu werden. Hierfür musst Du die existierende Teamstruktur und die vorhandene Teamdynamik erstmal verstehen: Wer hat welche Rolle? Und wer füllt welche Rolle wie aus? Wer ist Lautsprecher, wer Leisesprecher? Werden die Leisesprecher trotzdem gehört? Wie erfolgt die Kommunikation zwischen Product Owner und Development Team? Und wie anderes herum? Wie werden Entscheidungen getroffen? Wie wird der Scrum Prozess gelebt? Und und und… .  

Erfahrungsgemäß hilft es hier am Anfang einfach nur zu beobachten, ohne in der ersten Woche wirklich aktiv einzugreifen. Nicht aktiv eingreifen heißt für mich auch, in Woche 1 nicht in die Moderatoren-Rolle für Meetings zu schlüpfen. Nimm an allen für Deine erste Woche angesetzten Events Deines neuen Scrum Teams teil, aber mach zum Beispiel zu Beginn von Deinem ersten Daily Stand-up allen klar, dass Du dies (mindestens mal) anfangs nicht moderieren, sondern lediglich als stiller Beobachter beiwohnen wirst.

Alles was Dir auffällt, was die Arbeitsweisen Deines Teams, sowie den Umgang miteinander betrifft – gleichermaßen positive Aspekte, wie Punkte, bei denen Du ein Verbesserungspotential siehst, solltest Du erstmal für Dich aufschreiben und reflektieren. Das Ansprechen solcher Punkte, insb. der Räume für Verbesserung, sollte auf keinen Fall in Woche 1 erfolgen, sondern erst nachdem Du das Team ausreichend kennengelernt hast und sich Deine Meinung verfestigt.

#2 - Den Einzelnen kennenlernen und seine Rolle verstehen

Genauso wichtig, wie das Team als Ganzes kennenzulernen, ist das Kennenlernen der einzelnen Teammitglieder. Für mich sind hier 1:1-Gespräche mit den einzelnen Personen unabdingbar und ich versuche sie auch alle in der ersten Woche stattfinden zu lassen. Gemäß dem Sprichwort „der erste Eindruck ist der Wichtigste“ solltest Du die Macht solcher Einzelgespräche mit den Teammitgliedern zu Beginn nicht unterschätzen. In diesen Gesprächen legst Du den Grundstein für eine gute und vor allem auch vertrauensvolle Zusammenarbeit. Mir persönlich hilft es immer solche initialen Einzelgespräche nicht in der typischen Büroumgebung (also ein oft wenig kreativ eingerichteter Büroraum, oft mit anderen Personen im Hintergrund von denen die Hälfte sich Meetings oder Gesprächen befindet) stattfinden zu lassen, sondern hier bewusst eine lockerere Umgebung zu wählen. Wenn Du es irgendwie einrichten kannst, würde ich Dir immer ein in-person Meeting empfehlen und hier bewusst kein virtuelles Meeting anzusetzen. Für mich noch besser sind Situationen, in denen die Einzelgespräche dann gern bei einem gemeinsamen Kaffee an der frischen Luft stattfinden, statt in einem Meetingraum.

Ziel des Gesprächs ist das Schaffen der Basis für eine gute Zusammenarbeit und das Erlangen eines Eindrucks Deines Gesprächspartners mit Blick auf das Team und natürlich auch auf die Entwicklung des Produkts um die sich Dein neues Team kümmert. Auch die Ergebnisse und Eindrücke, die Du aus diesen Einzelgesprächen gewinnst, solltest Du aufschreiben und im Anschluss nochmal in Ruhe reflektieren.

Es bietet sich übrigens an, dass Du Dir vorher Fragen überlegst, die Du in all Deinen Einzelgesprächen den einzelnen Teammitgliedern stellst. Eine Frage, die mir regelmäßig sehr wertvolle Eindrücke gibt, ist die Flaschengeist-Frage: „Stell Dir vor ich wäre ein Flaschengeist und Du hättest 3 Wünsche frei zu Dingen, bei denen ich Dir konkret im Team helfen könnte. Welche Wünsche wären das?“ Meine Erfahrung ist, dass 1 Antwort dabei ist, die mindestens (!) von der Hälfte der Teammitglieder genannt wird und mindestens noch 3 weitere Antworten, die zumindest mehrfach genannt werden. Wenn Du diesen Überblick zu den Mehrfach-Antworten hast, hast Du einen bereits guten Eindruck wo der Schuh drückt und wo Du dem Team schnell helfen kannst.

#3 - Das Produkt kennenlernen um das Ziel des Ganzen zu verstehen
 

Scrum hat bekanntlich keinen Selbstzweck, sondern bildet den methodischen Rahmen um ein Produkt zu entwickeln. Wenn ich mich mit Scrum Mastern austausche, erhalte ich die unterschiedlichsten Antworten, inwieweit ein Scrum Master das von seinem Scrum Team entwickelte Produkt verstehen muss. Es gibt Scrum Master, die die Meinung vertreten, dass man sich inhaltlich nicht näher mit dem Produkt beschäftigen muss, sondern sich auf das Team, die richtige Anwendung der Scrum-Praktiken und das Beseitigen der Impediments fokussieren sollte. Für das Produkt gebe es in erster Linie ja den Product Owner. Meine persönliche Meinung dazu ist, dass Du auch als Scrum Master das von Deinem Team entwickelte Produkt nicht nur kennen, sondern auch gut verstehen solltest um wirklich in der Lage zu sein Deinem Team zu helfen das Produkt iterativ-inkrementell zu entwickeln. Nur wenn Du als Scrum Master das Produkt verstehst, d.h. einen Überblick zu den Nutzern hast und den Wert für die Kunden verstehst, einen Eindruck zur zugrunde liegenden Technologie bekommst und Dir die Einbettung in Dein Unternehmen klar ist, bist Du meines Erachtens in der Lage den Product Owner effektiv zu unterstützen um z.B. den richtigen Detaillierungsgrad der Einträge im Product Backlog zu gewährleisten, sowie eine methodisch sinnvolle Priorisierung der Einträge vorzunehmen. Ebenso wirst Du feststellen, dass Du Dich effektiver um das Beseitigen von Impediments kümmern kannst, wenn Du das Produkt (und sein Umfeld) wirklich verstanden hast.

Um das Produkt kennenzulernen und zu verstehen kann ich nur empfehlen, dass Du Dir zusammen mit dem Product Owner die Zeit nimmst und Dir von diesem einmal die Produktvision erläutern lässt und ihr gemeinsam durch das Product Backlog geht. Anhand des bereits ausgelieferten Produktstatus solltet ihr euch natürlich auch den bereits entwickelten Produktstand anschauen.

#4 – Historie kennenlernen um weitere Erkenntnisse zu erlangen und eventuelle Muster zu verstehen

Wenn Du in einem bereits seit einiger Zeit existierenden Scrum Team als Scrum Master startest, solltest Du natürlich auch versuchen Erkenntnisse über die Historie des Teams und der Produktentwicklung zu erlangen. Nicht selten erhältst Du hieraus bereits wichtige Erkenntnisse und kannst Muster sehen, die Ansatzpunkte für Deine Arbeit als Scrum Master sind. In diesem Zusammenhang hält die erste Woche als Scrum Master in einem bestehenden Team für Dich auch etwas Zeit für Lektüre bereit: Deine zu lesenden Bestseller sind hier vor allem die Ergebnisse aus den letzten Sprint Retrospektiven, sowie das Impediment Backlog. Vermutlich decken sich einige Punkte, die Du lesen wirst, mit Informationen, die Du auch in den Einzelgesprächen mit den Teammitgliedern erhalten hast, aber in der Regel wirst Du hier auf ein paar weitere spannende Punkte treffen, die Du noch nicht kanntest. Für mich eine weitere wichtige Erkenntnisquelle sind die letzten Sprint Burndown Charts. Diese verraten Dir, ob die gesetzten Sprintziele in der Regel erreicht wurden, oder ob z.B. ein Muster erkennbar ist, dass regelmäßig nicht alle geplanten Story Points umgesetzt wurden (ein Klassiker, den ich immer wieder beobachte). Auch hieraus kannst Du wichtige Ansatzpunkte für Deine Tätigkeit als Scrum Master gewinnen.

#5 – Erwartungen klären um Basis für eine gute Zusammenarbeit zu legen

Last, but definitely not least geht es zu Beginn der Tätigkeit als Scrum Master in einem Team natürlich auch darum die Erwartungen zu klären und Vereinbarungen zum Ausfüllen der Rolle zu treffen. Erwartungen gibt es übrigens immer in beide Richtungen. Als Neuling neigt man schnell dazu, erstmal nur die Erwartungen der anderen an einen selbst zu erfragen (oder manchmal auch ungefragt genannt zu bekommen). Ich kann Dich nur ermutigen auch Deine Erwartungen an Dein neues Team als Ganzes und die einzelnen Teammitglieder individuell zu kommunizieren. Du hast ja eine Vorstellung von der Rolle des Scrum Master und wie Du sie ausfüllen möchtest und was Dir diesbezüglich in der Zusammenarbeit mit Deinen Teammitgliedern wichtig ist. Mach den anderen diese Punkte deutlich!

Ich bin der Meinung, dass die Klärung der gegenseitigen Erwartungen so wichtig ist, dass man dies nicht mal eben zwischen Tür und Angel tun sollte. Ich kann hier nur empfehlen einen dedizierten Workshop anzusetzen und sich die Zeit zu nehmen die gegenseitigen Erwartungen zu kommunizieren, mögliche Diskrepanzen zu besprechen und sich anschließend auf die elementaren Punkte der Zusammenarbeit zu einigen.

Es bietet sich auch an, diesen Workshop nicht gleich für Tag 1 anzusetzen, sondern nachdem Du ein paar Tage in Deinem neuen Team verbracht hast und bereits ein paar Erkenntnisse gewonnen hast. Wenn Du als neuer Scrum Master zu einem existierenden Team stößt, wirst Du wahrscheinlich auch ein paar Mal den Satz hören: „Dein Vorgänger hat das so und so gemacht“. Sei offen dafür, Sachen, die dabei gut funktioniert haben, zu übernehmen. Habe aber auch den Mut Sachen abzulehnen und anders zu machen, wenn Du davon überzeugt bist. Deinem Team tun neue Impulse eines neuen Scrum Masters von Zeit zu Zeit ganz gut. Du findest da Deinen Weg!

Wie waren Deine ersten Tage als neuer Scrum Master? Hast Du Fragen oder Anregungen? Komm gern auf mich zu!

Tobias Krieftewirth, 09.08.2024

Über mich:

Seit 2007 begleite ich meine Kunden bei der Umsetzung großer Organisations- und IT-Vorhaben, sowie der Einführung von Projektmanagement- und Projektportfoliomanagement-Strukturen. Der Einsatz von passgenauen Methoden – egal ob klassisch, agil oder in hybrider Form – hilft mir dabei meine Kundenprojekte effizient umzusetzen. Im Zentrum steht dabei immer der Mensch: als Teil meiner Projektteams, oder als Nutzer der in meinen Projekten erzielten Ergebnisse.