Wem kommt das bekannt vor: ,,Was machst du als Scrum Master eigentlich den ganzen Tag?“
Schaut man sich die Aufgabenbeschreibung dieses Berufes an, könnte man meinen, diese Frage sei berechtigt. Nun, ich bin von Beruf Scrum Master und eins kann ich euch sagen: Meine 8 Stunden sind immer voll. Am Ende eines anstrengenden Tages merke ich was ich geschafft habe, beziehungsweise was mich geschafft hat. Selten läuft alles nach Plan, denn bei zwei Teams, die ich betreue, kommen täglich unerwartete Aufgaben hinzu, die ich zusätzlich bewältigen muss.
Ist doch nur „ein“ Sprintwechsel
Noch tiefenentspannt komme ich Dienstagmorgen zur Arbeit. Der Sprintwechsel steht an. Für die Review ist alles organisiert und vorbereitet. Gestern bin ich mit dem Team noch einmal alle auslieferbaren Inkremente für die Präsentation durchgegangen. Mein Product Owner hat alle wichtigen Stakeholder eingeladen und der Raum für die Review ist auch gebucht. So weit, so gut.
Die Retrospektive, passend auf die Bedürfnisse des Teams abgestimmt, habe ich ebenfalls schon fertig ausgearbeitet und gezeichnet.
Ich werfe nochmal einen Blick ins Backlog. Im gestrigen Refinement wurde fleißig geschätzt und alle Storys sind laut Definition of Ready (DoR) bereit um in den neuen Sprint gezogen zu werden. Auch gut. Somit sollte einem erfolgreichen Tag eigentlich nichts mehr im Wege stehen.
Der erste Termin, der auf dem Plan steht, ist das Daily mit dem Team was erst am nächsten Tag mit seinem Sprintwechsel startet. Da meine beiden Teams keine Abhängigkeiten zueinander haben, ist es in diesem Fall möglich die Sprintwechsel auf zwei unterschiedliche Tage zu legen. So kann ich mich an beiden Tagen voll auf das jeweilige Team fokussieren.
Nun ist es 9:15 Uhr und ich entschließe mich nach dem Daily bei meinem Team vorbeizuschauen, um zu hören ob soweit alles nach Plan läuft. Plötzlich erfahre ich von einem meiner Scrum Master Kollegen, dass er gleich nach der Retrospektive gehen muss, um einen wichtigen Termin wahrzunehmen. Im gleichen Atemzug bittet er mich sein Planning zu übernehmen. Nach einem kurzen Blick in den Kalender stimme ich schnaufend zu und strukturiere mich gedanklich schon mal um. Doch wie man weiß: ein Unglück kommt selten allein. Ein weiterer Kollege nutzt die Gelegenheit mir mitzuteilen, dass mein Kollege Peter krank sei und niemand vor Ort ist um sein Team zu betreuen. Langsam werde ich unruhig.
Ich verschiebe ein paar Termine und bringe einen weiteren Sprintwechsel noch gerade so unter. Anschließend erkundige ich mich bei seinem Team ob für die Review alles vorbereitet ist. Zum Glück – Ja! Leider finde ich nicht die für das Team vorbereitete Retrospektive, also schreibe ich mir eine Notiz, dass ich diese später auch noch fertig machen muss.
Das wird ein harter Tag
Die Review meines Teams verläuft ohne Probleme. Stakeholder und Product Owner haben nur kleine Anmerkungen, sind aber alles in allem sehr zufrieden was mich und das Team sehr freut.
In den 10 Minuten zwischen Review und Retrospektive erkundige ich mich bei dem zweiten Team wie die Review gelaufen ist und gebe ihnen die Zeit durch, wann wir mit der Retrospektive starten. Im Anschluss mache ich noch einen Abstecher zu meinem eigentlichen zweiten Team, um zu hören ob sie alles haben, um arbeiten zu können. Zum Glück ist bei ihnen alles gut und ich kann in Ruhe zu meinem nächsten Termin „sprinten“.
Die Retrospektive mit meinem Team verläuft nach dem guten Feedback der Review sehr positiv, dennoch entwickeln wir ein paar Maßnahmen die uns helfen werden im kommenden Sprint noch besser arbeiten zu können.
Da wir gut durch dieses Event kommen, habe ich 5 Minuten Zeit gewonnen, um mir eine gute Methode für das Team auszudenken, welches ich vertrete. Da ich nicht genau weiß, was das Team beschäftig und diese Methode immer gut passt um Blocker aufzudecken, entscheide ich mich für die Segelboot-Retrospektive. Ich liege sehr gut in der Zeit und bekomme die Retrospektive fertiggestellt noch bevor das Team eintrifft und mein Plan geht zum Glück auf. Zusammen erarbeiten wir gute Maßnahmen, um in Zukunft Blocker zu lösen und gehen im Anschluss zufrieden und glücklich zum nächsten Termin über.
Gemeinsam mit dem Product Owner machen wir direkt im Anschluss das Planning. Auch dieses Team hat das Refinement am Vortag genutzt und gut vorgearbeitet, so dass wir schnell durch den Termin kommen. Bis auf die normalen kleinen Diskussionen läuft alles reibungslos und trotzdem fängt langsam mein Kopf an zu qualmen. Sowie ich den Termin geschlossen habe, stehen schon die Jungs aus meinem eigentlichen Team in den Startlöchern für ihr eigenes Planning. Aufgrund neuer Erkenntnisse mussten wir zwar noch zwei neue Storys besprechen und schätzen, dennoch kommen wir auch hier gut durch.
Planning 2/3 geschafft
Jetzt habe ich noch kurz Zeit auf Toilette zu gehen und mir einen Kaffee zu besorgen. Weiter geht’s mit Planning Nr. 3!
Diesmal muss ich öfter eingreifen und das Team bitten den Fokus zu behalten. Es gibt einiges neu zu schätzen und Details zu besprechen. Nach und nach fängt mein Kopf an weh zu tun, dementsprechend bin ich froh wenn auch dieser Termin erfolgreich zu Ende geht.
Jetzt hätte ich Zeit, mein Essen warm zu machen und durchzuatmen, aber nicht lange, es steht noch die Dokumentation an. Alle besprochenen Maßnahme werden zusammengefasst und den jeweiligen Teams zur Verfügung gestellt, in der Zwischenzeit führe ich parallel immer wieder Gespräche mit einzelnen Teammitgliedern.
Zeit für einen kurzen Gang über den Flur um zu hören ob bei den Teams alles in Ordnung ist und ob sie arbeiten können.
Da am nächsten Tag noch ein Sprintwechsel geplant ist, steht für heute noch ein Refinement und ein kurzer Preview-Termin im Kalender. Im Anschluss checke ich den Kalender, buche Räume und stelle neue Termine ein. Ich erfahre, dass der erkrankte Kollege die ganze Woche ausfällt. Das bedeutet, dass wir seine anstehenden Termine die ganze Woche abdecken müssen.
Solche Tage sind nicht unüblich, meistens sind die Scrum Master so knapp besetzt, dass wenn jemand ausfällt, es sowohl zeitlich als auch nervlich schwierig wird, jedem Team und dessen Mitgliedern gerecht zu werden. Als Scrum Master ist es wichtig eng beim Team zu sein, um zu wissen was es beschäftigt und um frühzeitig eingreifen zu können, sollten Impediments auftreten. Dies ist jedoch schwierig, wenn man sich um mehr als ein Team kümmern möchte.
Zum Schluss möchte ich noch fragen:
Und was macht ihr eigentlich den ganzen Tag so?
