Im April 2020 bin ich zu einem Scrum Team in der Allianz Technology gekommen. Meine Aufgabe bestand darin, das Scrum Framework zu festigen und das Team auf seinem Weg zu mehr Agilität und Selbstorganisation zu unterstützen.
Zu Anfangs zählte das Team acht Personen und im Laufe des Jahres 2020 wuchsen wir weiter an. Im Herbst 2020 hatten wir bereits 18 Personen in unserem Team - deutlich zu viel für ein Scrum Team. Seit Längerem diskutierten wir über eine Skalierung und nun war es endlich soweit. Das “große” Scrum Team sollte aufgeteilt werden.
Unsere größten Schmerzen in dem aus den Nähten platzenden Scrum Team waren bisher:
- Anzahl der Themen
- Anzahl der Meetings
- Anzahl der Teilnehmer in den Meetings
- Anzahl der Aufträge stieg weiter an
Durch die erhöhte Nachfrage und die dazugehörigen Meetings nahmen die Kommunikation und die Transparenz im Team deutlich ab und als Team verloren wir den Fokus (nicht nur) in den Sprints.
Was genau aber bedeutet für uns nun die Agile Skalierung? Ein Trennen von Teams ist nicht außergewöhnlich, wenn Teams sich vergrößern. Was unterscheidet eine Agile Skalierung von einer ganz gewöhnlichen Skalierung?
Meine Antwort auf diese Frage lautete:
Der Prozess selbst und das Teamgefüge müssen agil eingeführt werden. Wir prüfen regelmäßig, ob die Skalierung uns bei der Bewältigung unserer täglichen Arbeit unterstützt und justieren sie dort, wo es nicht passt. Wir arbeiten also auch in Iterationen für die Veränderung im Prozess.
Unser Ziel war es, in jedem Team wieder fokussiert arbeiten zu können und auch für die Zukunft gut gewappnet zu sein. Wir wollten den Team Split schnell durchführen und flexibel anpassen können. Das würde uns nur gelingen, indem wir in Iterationen den Prozess verändern. Agil skalieren.
Uns war ein ständiges Feedback zu dem laufenden Prozess und den Neuerungen wichtig.
„The important thing is not your process. The important thing is your process for improving your process.“ - Henrik Kniberg
Um unser Team zu splitten und die Skalierung umzusetzen, planten wir zuerst zwei Iterationen á zwei Wochen, um später in weiteren Iterationen in vier Wochen Rhythmus stetig weitere Verbesserungen und Änderungen einführen zu können.
Nach jeder Iteration wollten wir Feedbacks in Form einer großen Retrospektive einholen.
Im ersten Schritt beschäftigen wir uns mit dem Prozess, den wir umsetzen und einführen wollten. Für uns kam nicht eine fixe Methode oder ein spezielles Framework in Frage. Wir schneidern uns aus den uns bekannten Frameworks unseren Rahmen für unsere Skalierung.
Für die Aufstellung unserer Teams haben wir uns an den Flight Levels von Klaus Leopold orientiert. Wir haben drei Operative Teams etabliert, zwei davon mit Scrum und eines mit Kanban, eine Ebene für die Koordination der kompletten Requirements und eine Ebene für die Demands - also jegliche neue Anfragen für unser Produkt.
Um größtmögliche Transparenz zwischen den Leveln und Teams zu erreichen, wurden für jedes Level Boards in Jira erstellt. Jedes Teammitglied kann zu jeder Zeit auf die Boards der anderen Levels einsehen.
Neben den regelmäßigen Kanban- und Scrumevents, die jedes Team für sich umsetzt, haben wir für die Kommunikation der Teams untereinander drei weitere Meetings eingeführt:
- SoS Call
- Täglich
- Vertreter aus allen Teams
- Global Review
- nach jeder Iteration
- mit allen Teammitgliedern + Stakeholder
- Globale Retrospektiven
- nach 4 bzw. 6 Wochen
- mit allen Teammitgliedern mit Fokus auf die Zusammenarbeit teamübergreifend
Unseren Plan bezüglich der Teamaufstellung, der Organisation in Jira und der Meetings haben wir dann in Einzelgesprächen mit den Teammitgliedern durchgesprochen. Hierbei war es mir besonders wichtig, zuerst Einzelgespräche zu führen, bevor wir ein großes Kick-Off Meeting veranstalten.
Meine Erfahrung zeigt, dass gerade bei international zusammengewürfelten Teams in großen Meetings nicht alle zu Wort kommen. Es gehen wichtige Einwände oder Kommentare verloren, da die Leisen in der Gruppe nicht vortreten.
Um das zu vermeiden, haben wir uns die Zeit genommen, mit jedem einzeln zu sprechen.
Die Feedbacks und Bedenken haben wir in unser Vorhaben eingearbeitet.
Im Anschluss wurde ein Kick-Off veranstaltet, in dem wir unter anderem auch eine Transition-Timeline vorgestellt haben. Mit diesem Zeitplan sollen Ängste vor den nächsten Wochen genommen und aufgezeigt werden, wo es Möglichkeiten geben wird, über Dysfunktionen in der Umstellung zu sprechen.
Zusätzlich haben wir viele Workshops in die Umstellungsphase eingebaut, sodass sich Teammitglieder durch Einzelcoachings, Requirementsworkshops, Rollen Workshops usw. um sich in die neuen Verantwortlichkeiten einzuarbeiten.
Rückblickend ist uns die Umstellung gut gelungen und wir konnten dabei einiges lernen, haben aber auch einige Praktiken von Anfang an umgesetzt, die gut funktioniert haben.
Die Learnings und Good Practices die ich hier teile, haben wir mit unserem Team in den immer wiederkehrenden Einzelgesprächen oder Retrospektiven durchgesprochen.
Wie bewahren wir den Teamspirit trotz Trennung?
Wöchentliche Coffee Calls
Damit wir nicht immer die gleichen Themen, wie Wetter und Corona, besprechen, haben wir diese 30-Minuten-Calls unterhaltsamer gemacht. Durch Spiele wie Montagsmaler, Motto-Fragen oder Quizze haben wir hier über alles, aber nicht über den Arbeitsalltag gesprochen.
Social Chat Gruppen
In Teams haben wir eine Gruppe eröffnet, in der private Fotos von den Wochenenden gepostet werden konnten. Auch Rezepte wurden hier rege ausgetauscht.
Durch die internationale Mischung in unserem Team war das - trotz des Lockdowns - wie Urlaub. Wir haben Elefantenbabys aus Indien oder Bergabenteuer aus Bayern sehen dürfen.
Festival Kalender
In Confluence haben wir einen Kalender erstellt, in dem Abwesenheiten und religiöse Festivitäten gepflegt wurden. So konnte jeder einen Überblick erlangen und das Planen bzw. Vereinbaren von Terminen gelang einfacher.
Trotz der vielen guten Praktiken haben wir allerdings gelernt, dass Erwartungen auch klar angesprochen werden müssen. Den alten Spirit des großen Teams beizubehalten, war nicht zu 100 % möglich und wir konzentrierten uns darauf, den Teamspirits der neuen Teams zu etablieren und zu fördern.
Wie lassen sich Wissensinseln vermeiden?
Als allererstes ist meine Erfahrung - sie lassen sich nicht gänzlich vermeiden. Ich denke, die Kunst liegt darin, zu wissen, wo sie sind und, wenn sie entstehen, dagegen vorzugehen.
Zwei gute Praktiken, die uns dabei geholfen haben, waren:
- Tech Deep Dives: Nach den Globalen Reviews haben Entwickler oder Business Analysten 15- bis 20 minütige Sessions angeboten, in denen ein Thema tiefergehend behandelt wurde
- Brown Bag Sessions: 15- bis 30-minütige Sessions zu diversen Themen, die während der Mittagspause abgehalten wurden
Wie können wir trotz der Distanz alle bestmöglich begleiten?
In unserem Team haben wir unter anderem vor allem auf diese Praktiken gesetzt:
- Regelmäßige 1on1-Gespräche: Durch ihre regelmäßigkeit werden sie vertrauensvolle Telefonate mit deinem Team
- Tool Trainings: Es ist wichtig, dass jeder die Alltagstools gut beherrscht und meiner Erfahrung nach wird das häufig vernachlässigt (Jira, MS Teams, etc.)
- Visualisieren aller Meetings, damit jedem vor Augen gehalten wird, über was wir sprechen und keiner abdriftet
Zudem habe ich während der Umstellung wirklich sehr gute Erfahrung mit agilen Spielen (Buchtipp: https://agilecoach.de/agile-spiele-online/) gemacht. Ich habe Spiele wie das Coin Flip Game oder das Name Game gespielt und konnte meine Kollegen auf eine spielerische Art und Weise in die Beobachterrolle bringen, die sonst nur ich habe.
Grundsätzlich möchte ich an dieser Stelle auch noch mal an alle Entscheider und Unternehmen appellieren. Holt euch für jedes Team einen Scrum Master. Ich sehe leider allzu oft Scrum Master, die mehreren Teams zugeteilt sind und für Skalierungen keinen Agile Coach haben. Agile People Power ist sehr wichtig, wenn eine agile Transformation ernst gemeint ist.
Wie finden Menschen in ihre neuen Verantwortlichkeiten?
Da sich einige Kollegen innerhalb dieser Umstellung in neue Rollen entwickelt und neue Verantwortlichkeiten übernommen haben, sollte auch dieser Schritt begleitet werden.
Dafür haben sich folgende Good Practices bewährt:
- Methoden-Workshops immer wieder auffrischen: Scrum- und Kanban-Workshops, aber auch Workshop zum allgemeinen Requirements Engineering oder speziell zu den Rollen des Product Owners usw.
- Health-Check-Umfragen: Regelmäßige Online-Umfragen, die das Stimmungsbild abfragen
- Scrum Events anderer Abteilungen: Wie arbeiten andere Teams mit Scrum, wie laufen deren Events ab? Über den Tellerrand hinaus bei anderen Teams an Reviews oder Refinements teilnehmen
Wichtig empfand ich es auch hier, immer wieder Trainings für unsere alltäglichen Toolings anzubieten. Für Jira, MS Teams und Co. muss es regelmäßige Fragerunden oder Auffrischungen geben. Beherrscht man diese Tools im Alltag nicht, wird das Arbeiten remote schwer und langsam.
Rund um den Globus - welche Besonderheiten gibt es?
Da wir ein international zusammengewürfeltes Team waren und uns nicht ein Mal in der Realität getroffen haben, gab es durchaus auch hier ein paar Besonderheiten, auf die ich nochmal eingehen möchte. Momentan geht es uns ja sogar mit unseren lokalen Teams so, wenn wir uns gerade im Homeoffice befinden. Wobei durch z.B. sprachliche Barrieren noch ein paar zusätzliche Herausforderungen hinzukommen.
Diese drei Learnings konnte ich mitnehmen:
- Meeting-Zeit: Meetings dauern länger, wenn wir nicht in unserer Muttersprache sprechen können. Sätze müssen evtl. mehrmals wiederholt oder umformuliert werden, bis man sich verständlich ausdrückt
- Facilitation: Gute Meeting-Führung holt alle Teilnehmer ab, es ist wichtig, dass wir in den Meetings alle einbinden, auch die, die eher leise sind
- Einzelgespräche: Halte deine Einzelgespräche mit den Teammitgliedern regelmäßig, es hilft, Vertrauen zu schaffen und Probleme frühzeitig zu erkennen
Was uns außerdem in der Zusammenarbeit geholfen hat:
- Jedes Meeting wird visualisiert, ob wir malen oder schreiben ist egal. Aber wir wollen sicherstellen, dass jeder zu dem gehörten auch etwas sehen kann
- Action Items schriftlich erfassen
- Arbeitszeiten: Erkenne, dass deine Arbeitszeit nicht gleich die deiner Kollegen ist, wenn du einen Kaffee zum Frühstück brauchst, ist bei deinem Kollegen vielleicht schon abends.
Der Teamsplit und die Skalierung auf vier Teams hat sehr gut funktioniert und wir haben durch das immer wiederkehrende Feedback viel lernen können. Durch unseren Ansatz der Iterationen und ständigen Verbesserungen standen wir uns selbst nicht im Weg, sondern konnten schnell neu Gelerntes einbringen.
Rückblickend bin ich überzeugt, dass folgende vier Gedanken eine gute Stütze bei einer solchen Umsetzung sind:
- Fang an - So schnell wie möglich Ideen teilen ohne Anspruch auf den “perfekten Prozess”
- Gemeinsam - Von Anfang habe ich alle bei jeder Neuerung miteinbezogen und so sichergestellt, dass das Team hinter den Veränderungen steht
- Ziele - Durch Prozess-orientierte Ziele in den 2- bis 4-Wochen-Iterationen haben wir neben unseren regulären Sprintgoals auch Ziele, die wir im Miteinander erreichen möchten
- Flexibilität - Durch unsere Anpassungsfähigkeit können wir extrem schnell auf neue Projektsituationen reagieren
Unser Team konnte mit der Skalierung wachsen und lernen, dass die Zusammenarbeit und das Ergebnis nicht darunter leiden, wenn wir offen mit der Herausforderung umgehen und bereit sind, uns den äußeren Veränderungen immer wieder anzupassen.
Wenn du weitergehende Fragen zu der Umstellung hast oder mehr darüber erfahren möchtest, nimm jederzeit gerne Kontakt mit mir oder meinem Team der ACT (Agile Coaching by Techdivision) auf.
Die Folien zu meinem Talk kannst du dir hier ansehen: Klicke hier