In unserem heutigen Beitrag möchten wir Dir einen unserer Scrum Master vorstellen. Marcus Autenrieth ist seit April 2017 bei der WPS Management GmbH und plaudert ein bisschen aus dem Nähkästchen, wie die Arbeit als Scrum Master aussieht und was wichtig ist, wenn auch Du ein Scrum Master bei uns werden willst.

Viel Spaß beim Lesen!

Wie bist Du zu WPSM gekommen?

Ich bin zu WPSM gekommen, weil es das einzige Unternehmen damals in Paderborn war, das öffentlich nach Scrum Mastern in Vollzeit gesucht hat. Kaum eine andere Firma hat so offen gesagt wir wollen Scrum machen. Davor durfte ich das höchstens zu 50% machen und das war nicht so befriedigend.

Was machst Du bei WPSM?

Ich begleite Teams und Individuen. Einerseits bedeutet das, dass ich Entwicklern helfe, die beste Version ihrer selbst auszuliefern. Okay das Klingt jetzt cheesy, aber das ist im Endeffekt der entscheidende Punkt.

Andererseits baue ich auch Teams. Das heißt, ich gucke mir an, wie sind die Leute drauf, wie bekommt man aus den Individuen eine Gemeinschaft gebaut, wie strukturiert man die Zusammenarbeit, wie kommt man von reiner Kooperation, wo man einfach irgendwie zusammenarbeitet, hin zu einer Kollaboration.

Hier betreue ich ein großes Team, was aus mehreren kleineren Teams besteht. Mit dem Product Owner (PO) und den Werkstudierenden sind es aktuell 18 Personen. Bis vor Corona habe ich „Management by Walking Around“ betrieben und Meetings moderiert. Nachdem die ganze Firma im März 2020 ins Home-Office geschickt wurde, musste ich dann meinen Job neu erfinden. So operativ moderiere ich weiterhin die üblichen Scrum Meetings, aber bis auf die Retrospektive bin ich da mittlerweile eigentlich überflüssig. Außerdem hat jedes Teammitglied einmal alle zwei Wochen die Gelegenheit für ein Einzelgespräch mit mir. Strategisch kümmere ich mich mit den anderen Scrum Mastern, um die teamübergreifende Zusammenarbeit in der Entwicklung und moderiere bei Bedarf auch teamübergreifende Meetings in der Entwicklungsabteilung. Zur Meetingmoderation gehört dabei oft auch die Vor- und Nachbereitung.

Das zu große Team

Das ich ein Team von aktuell 18 Personen betreue ist untypisch, normalerweise sagt die Literatur: ein Team sollte ca. 3 – 9 Mitglieder haben. Die Teams der anderen Scrum Master bei uns im Unternehmen haben auch die übliche Größe. Aber als mein Team damals auf über 9 Personen gewachsen ist, haben sie sich geweigert, sich aufzuteilen. Ich habe sie dann auch nicht gezwungen sich aufzuteilen und habe denen dann gesagt: „Wir müssen machen, dass in der Größe die Zusammenarbeit läuft! Wie können wir das machen?“

Wir haben jetzt ein großes Team, das de-facto aus mehreren Teil-Teams besteht, die aber ein gemeinsames Review und eine gemeinsame Retro haben – und das läuft sehr sehr gut. Dadurch haben wir zwar eine ziemlich große Retrospektive, die aber extrem fokussiert ist. Wenn da rauskommt, dass ein Teil- Team Probleme hat, dann machen wir fokussierte Auskopplungen, um diese Probleme in kleineren Gruppen sehr direkt anzugehen. Und wir warten auch nicht immer auf die Retrospektive, um Probleme zu lösen, sondern wenn wir mitten im Sprint sehen, da muss was besprochen werden, dann legen wir auch schon vorher mal Termine, um diese Themen zu reflektieren.

Das heißt, die Retrospektive, die man so traditionell hat, die ist für uns nur noch so eine Art Absicherung, die ich dann auch viel für teamübergreifendes Teambuilding nutze. Gerade auch, weil wir uns durch die Remote Situation kaum noch persönlich sehen, reden wir dann auch mal 10 – 15 Minuten lang nur über Hobbies, oder Urlaub, damit die Leute sich kennenlernen. Was auch an der teamübergreifenden Retrospektive ganz gut ist, die Leute sehen mal die Probleme in den anderen Teil-Teams und deren Lösungen. Das heißt, da passiert auch mal so ein bisschen Querbeet-Befruchtung.

Wie würdest Du Deinen typischen Arbeitstag beschreiben?

Das ist gar nicht so einfach. Ich beschreibe mal einen typischen Sprint und wie das Ganze für mich aussieht.

Also das Ganze beginnt an einem Montag mit dem Sprintplanning am Vormittag, wo wir in den einzelnen Teil-Teams die Arbeit für die nächsten zwei Wochen planen. In meiner Anfangszeit habe ich dort immer die Realitätsfrage gestellt, also ist es realistisch, dass das, was wir uns da vornehmen, auch am Ende des Sprints fertig ist. Wenn ich da dann keine Zustimmung höre oder keine offensichtliche Zustimmung sehe, dann fällt im Zweifel lieber Arbeit aus dem Sprint heraus. Aber mittlerweile muss ich dort nur noch ab und an mal nachhaken, weil der Product Owner automatisch in den Dialog einsteigt und die Aussagen der Entwickler respektiert. Das ist schon ziemlich cool. Danach habe ich ein paar operative und administrative Tätigkeiten zu tun, die ich mir im remote Setting so angewöhnt habe. Ich helfe zum Beispiel mit der Dokumentation, richte die Confluence Seiten für die Sprint Reviews ein, bereite die Foliensätze für die Sprintreviews vor, sodass die Leute nur noch ihren Content dort eintippen müssen, aber die Sprintziele und das Datum schonmal richtig eingetragen sind. Dann aktualisiere ich noch ein paar Jira Dashboards und falls der PO im Jira noch nicht auf den Startknopf gedrückt hat, drücke ich noch auf das Knöpfchen. Dann habe ich erstmal nur die One-on-Ones mit den Teammitgliedern, diese Termine sind in meinem Kalender auch fest geblockt, damit jeder, der ein One-on-One bekommen möchte, auch tatsächlich eins erhält. Und dann habe ich noch Abstimmungen nach oben und nach links und rechts also mit den anderen Scrum Mastern und meinen fachlichen Vorgesetzten.

An dem Mittwoch der ersten Woche kommen dann noch ein paar administrative Aufgaben. Weil ich mich auch sehr für unsere Produkte interessiere, gehe ich gerne in die Reviews der anderen Entwicklungsteams rein – mittwochs ist bei uns Review Tag – und mache dann da die schriftliche Zusammenfassung für mein Team und poste diese später, sodass sie jeder einsehen und nachlesen kann.

Wenn in der Retrospektive rausgekommen ist, dass die Leute gerne noch eine Abstimmung hätten oder einen Workshop zu einem bestimmten Thema wollen, dann plane ich den auch noch mit ein und moderiere den dann. Jetzt im Juni habe ich zum Beispiel einen Refactoring Workshop durchgeführt und da haben wir uns dann geeinigt, dass wir das Thema in drei Wochen in der Retro nochmal ansprechen, wie das bisher läuft und was wir da noch tun können und müssen.

Dann haben wir Donnerstag und Freitag Refinement, da höre ich dann so ein bisschen rein und gucke, ob ich da ab und an mal nachhaken muss, wenn mir etwas komisch vorkommt, aber eigentlich habe ich mich da, genauso wie im Sprintplanning, extrem überflüssig gemacht, da der PO den Stil, den ich da am Anfang reingebracht habe, so nahe kopiert hat, dass das alles läuft.

Dann haben wir freitags gerade unter der Remote Situation zwei Social Events. Einmal innerhalb meines Teams. Das ist dann eigentlich so der Wochenabschluss der Leute, wo man mal wirklich nur über privates Zeug redet, was man am Wochenende so vorhat, welche Hobbies man hat etc. Ab und zu spielen wir auch mal ein Spiel, da tut es richtig gut, mit den Leuten einfach mal gemeinsam zu lachen, das hält das Team zusammen. Anschließend haben wir das Ganze nochmal von der gesamten Entwicklung aus.

Die zweite Woche startet dann in meinem Team montags mit einem gemeinsamen Frühstück, das ist dann so der soziale Termin zum Wochenanfang, dienstags bereite ich die Retro vor, lasse das Team in Ruhe ihre Arbeit am Sprint abschließen und kümmere mich um strategische Themen.

Mittwoch ist dann wieder Sprint Review, vormittags zwei Teams und nachmittags dann wir. Wer jetzt aufgepasst hat, wird sagen: „Hä, das sind ja keine zwei Wochen!?“ Das ist auch so eine Spezialität von uns. Die Entwickler haben 20% Zeitbudget die sie selber einplanen dürfen; um die Architektur ihrer Services zu verbessern, Innovation oder Weiterbildung. Wichtig ist nur, dass es einen Mehrwert für die Firma generiert. In anderen Teams wird das mit im Sprint eingeplant, bei uns haben wir den Sprint von 10 Tagen herunter auf 8 Tage verkürzt. Für diese beiden Tage haben wir ein separates Planning, was ich moderiere, damit die nötige Transparenz da ist. Ab und an fließen die Ergebnisse aus den beiden Tagen dann in einen Sprint mit ein, wenn die Entwickler sagen, dass sie da noch etwas fertig machen müssen, oder wenn es sogar für das Release relevant ist.

Und auch die zweite Woche endet dann wieder mit den beiden remote Social Events.

So sieht eigentlich typischerweise ein Sprint aus meiner Sicht aus. In der Zwischenzeit, wenn ich etwas Luft habe, schreibe ich an verschiedenen Konzepten weiter. Ich bin beispielsweise auch in dem Arbeitskreis Arbeitszufriedenheit von WPSM mit drin und mache dadurch auch so ein bisschen Schnittstellenpflege in andere Unternehmensbereiche. Ansonsten beschäftige ich mich mit Weiterbildung, damit ich meine Scrum Aliance Zertifizierung halten kann. Wenn man sich selbst als Scrum Master nicht ein bisschen weiterbildet, wie will man dann erwarten, dass die Teammitglieder, die man betreut sich dann weiterentwickeln? Das gehört auch zum Job.

Warum sollte man sich als Scrum Master bei WPSM bewerben?

Es gibt in Paderborn einfach wirklich keinen besseren Arbeitgeber, wenn Du Scrum Master sein willst. Die Product Owner mit denen ich bisher zusammengearbeitet habe, waren super kooperativ mit mir und den Entwicklern. Hier wird kein totales „Command and Control“ gelebt. Und in 2020 fand ich die Reaktion der Geschäftsführung auf den Corona Lockdown im März mutig und konsequent. Seitdem arbeiten wir erfolgreich remote. Das hat mir gezeigt wie viel Vertrauen die Führungskräfte in ihre Mitarbeiter haben. Und die Ergebnisse der Teams haben dieses Vertrauen gerechtfertigt.

Was sollte jemand mitbringen, der bei uns Scrum Master werden will?

„Den Mut zur Transparenz!“

Also das man den Leuten zeigt, man macht sich die Hände schmutzig und redet über die Dinge, an denen man da arbeitet. Man kann das High Level halten, man muss da jetzt nicht die ganzen Details ausplaudern. Die sind ja manchmal auch vertraulich. Aber wenn man da grob sagt, für wen man da gerade ungefähr was macht, dann ist das gut genug. Das reicht den Leuten. Die wissen dann, womit Du Dich beschäftigst und was Dein Beitrag für den Erfolg der Firma ist. Manchmal geht es ja auch um Dinge, die sie ganz konkret betrifft; wenn man für das Team etwas erledigt und sich um eine Verbesserung der Arbeitsbedingungen kümmert. Da sollte man das Team schon regelmäßig über den Fortschritt informieren.

Die Fähigkeit Meetings zu moderieren ist natürlich auch wichtig; nicht unbedingt bei den Standard Scrum Meetings, sondern bei Meetings, die sich so drum herum ergeben. Das sind die schwierigen Meetings, wo man gut vorbereitet und als Moderator präsent sein sollte.

Bei solchen Meetings helfen dann auch Techniken, um das Thema des Meetings zu modellieren.

Geschriebene Kommunikation erlaubt uns die Möglichkeit, nichtlinear zu arbeiten, wenn mal jemand einen Arzttermin hat, bspw. – Kein Problem! Und warum? Weil der Tag nicht mit Meetings zugeknallt ist. Wir haben so wenig Meetings, wie nur vertretbar und das ersetzen wir halt durch asynchrone Kommunikation und das heißt geschrieben in Slack und wenn es dann etwas Größeres ist, dann zeichne es als Bild oder modelliere es als Graph aber skizziere Dein Problem.

Das ist einer der wichtigsten Punkte im agilen Bereich, dieses gemeinsame Denken über Artefakte. Du baust etwas und dadurch, dass es irgendwie aus Deinem Kopf rausgekommen ist, hast Du einen Referenzpunkt, um mit anderen Leuten darüber nachzudenken und da brauchen wir jemanden, der das Vorleben kann und da brauchen wir jemanden der da Bock drauf hat.

Und was mir noch einfällt; wir haben englischsprachige Kollegen. Mit denen wird man als Scrum Master unweigerlich zu tun haben; man sollte also keine Angst haben, die englische Sprache zu benutzen.

Marcus Eindrücke haben Dir gefallen und Dein Interesse geweckt?

Alles rund um unsere Stellanzeige als Scrum Master (m/w/d) findest Du hier.

Du möchtest noch mehr über den Beruf als Scrum Master erfahren? Kein Problem, sende uns einfach eine Nachricht an Jobs@wps-management.de Marcus freut sich auf Deine Fragen.