Restrukturierung eines Agile Release Trains - ein Fallbeispiel

Abstract

Ein Agile Release Train (ART) im SAFe®-Framework wurde aufgrund veränderter Auftragslage neu strukturiert. Der Prozess erfolgte kollaborativ und iterativ, unter Einbeziehung aller Stakeholder. Durch Workshops wurden Produktcluster identifiziert und Führungsrollen sowie Teammitglieder zugewiesen. Das Ergebnis waren drei kohärente und autonome Teams, die eine hohe Akzeptanz und ein starkes Commitment der Mitarbeiter förderten. Diese Vorgehensweise förderte eine hohe Akzeptanz und ein starkes Commitment der Mitarbeiter, was die Wirksamkeit eines inklusiven und iterativen Change-Managements unterstrich.

Ausgangssituation

Ablauforganisation

Ein Agile Release Train (nach SAFe) mit ca. 50 Mitarbeitern verantwortet die Entwicklung und den Betrieb eines umfassenden Softwaresystems zur Schadenbearbeitung im Versicherungskontext.

Der Train setzt sich aus vier Teams zusammen. Jedes Team besteht aus ca. acht bis zehn Mitarbeitern, einem Productowner und einem Scrummaster. Darüber hinaus gibt es eine Trainsteuerung, bestehend aus Productmanagement, Release-Train-Engineer (RTE) und einem Systemarchitekt. Mehr zum Aufbau und den Rollen nach SAFe hier.

Aufbauorganisation

Flankierend zur Ablauforganisation nach SAFe exisitert eine Aufbauorganisation, die klassisch nach Fachlichkeiten und Spezialwissen untergliedert ist. In diesem Kontext existieren fünf hierarchisch Vorgesetzte unterschiedlicher Ebenen, die als Stakeholder jeweils eigene Ziele mit in den Train einbringen.

Zielsetzung

Durch eine Veränderung in der Auftragslage verschiebt sich die geplante Auslastung der Teams. Um einen glätteren operativen Ablauf der Auftragsumsetzung für die kommenden zwei Jahre zu gewährleisten, soll die Struktur der Organisation an die veränderten Umweltbedingungen angepasst werden.

Da die vier Teams nach Softwarekomponenten geschnitten sind, sind Anpassungen an die veränderte Auftragslage häufig mit Strukturanpassungen verbunden. Diese finden in diesem Kontext ca. alle zwei bis drei Jahre statt.

Vorgehen

Theoretische Überlegungen

Um in der Zukunft schneller auf sich ändernde Auftragslagen reagieren zu können, bot sich als eine Überlegung an, ganz von Komponententeams auf Featureteams umzustellen. Die Überlegung hierbei ist, daß sich Teams an der Fachlichkeit und den vom Anwender erlebbaren Funktionen ausrichten und nicht an technischen Komponenten und Wissensgebieten. Dadurch entstehen viele Vorteile, von denen nur einer die stark erhöhte Flexibilität in der Umsetzung ist. Mehr zum Unterschied zwischen Featureteams und Komponententeams hier.

Dieser Wechsel erfordert allerdings teils tiefgehende Änderungen in der Zusammenarbeit und der technischen Basis. Nur ein Beispiel hierbei ist, daß Softwareänderungen in viel kleineren Portionen (Commits/Branches) in das System eingespielt werden müssen, da das Abhängigkeitenmanagement stärker über den Code, als über Abstimmungen und Meetings auf Steuerungsebene stattfindet.

Nach reiflicher Überlegung entschied sich die Organisationsleitung zu diesem Zeitpunkt gegen einen solch tiefgreifenden Wandel.

In Gesprächen mit Mitarbeitern und Führungskräften enstand der Eindruck, daß Teamumstellungen bei den Mitarbeitern ein eher unbeliebtes Thema sind. Mitarbeiter führten Probleme in der Zusammenarbeit und der Projektorganisation häufig auf die vermeintlich (oder tatsächlich?) mißglückte Teamstruktur zurück.

Bisherige Strukturanpassungen wurden stark von „außen“, also durch die Linienvorgesetzten getrieben und gestaltet.

Wir hatten die Annahme, daß der hohe Grad an Fremdbestimmung bei den vorhergegangenen Umstrukturierungen zu einem eher geringen Commitment bei den betroffenen Mitarbeitern führte. Sowohl zum Prozess der Umstellung, als auch zum Resultat, also der jeweils neuen Teamstruktur.

Weiterhin sind wir der Überzeugung, daß die Sicht auf Probleme aus verschiedenen Rollen unterschiedlich ist. Für einen tiefergehenden Wandel in der Teamstruktur sind viele Perspektiven hilfreich. Führungskräfte und operative Mitarbeiter können also gemeinsam eine viel umfassendere Sicht auf die Thematik entwickeln.

Kollaborativ - Feedbackgetrieben - Iterativ

So entstand die Empfehlung, die anstehende Umstrukturierung wie im folgenden dargestellt über Hierarchie- und Fachebenen hinweg eng verzahnt und feedbackgetrieben anzugehen.

Bestimmung der Produktcluster

Im ersten Schritt ging es darum, geeignete Bündelungen von Produktteilen und damit verbundenen anstehenden Aufgaben zu finden. Aus diesen Bündelungen sollten dann im Anschluss die Teams entstehen.

Dazu wurde anhand des Backlogs (mehr zu Backlog) eine Übersicht über Aufgabenkategorien und damit verbundene grob geschätzte zukünftige Aufwände erstellt. Teilnehmer waren die Productowner, das Productmanagement, Stakeholder, die die Anforderungsseite vertraten und die Linienführungskräfte.

Es wurde ein Workshop zur Findung von Productclusteralternativen und somit Teamschnitten geplant.

Wichtige Bedingungen waren dabei:

• ausgewogene Aufgabenlast und somit Teamgröße

• kein Team zu groß oder zu klein

• möglichst hohe Entkopplung der Teams untereinander

• hohes Commitment zur Lösung bei den Mitarbeitern

Dazu haben wir den Workshop mit folgenden Aspekten designt:

• Interessen der Organisation und der Beiteiligten wurden transparent aufgeführt und ausgehandelt

• anhand der gemeinsam ausgehandelten zu berücksichtigenden Interessen und Bedingungen wurden in einem iterativen Prozess gemeinsam in Gruppenarbeit Vorschläge erarbeitet

• vor dem Workshop bereits bestehende Vorschläge wurden in die Aushandlung integriert und anhand gemeinsamer Interessen bewertet

• gemeinsam wurde im Konsens ein Vorschlag beschlossen

In den Workshop liessen wir viele Aspekte des Harvard-Prinzips für sachbezogenes Verhandeln einfließen (mehr zum Harvard-Prinzip).

Durch dieses Vorgehen entstand ein maximal belastbarer Vorschlag, der, wie sich in der Retrospektive zeigte, von den Involvierten getragen wurde. Vor- und Nachteile des gewählten Vorschlags waren allen Teilnehmern transparent und die Beteiligung der in der täglichen Arbeit betroffenen voll gewährleistet.

Zuordnung der Führungsrollen zu Produktclustern

Im Anschluss an die Aushandlung der Produktcluster wurde in einem weiteren Workshop zwischen POs und Scrummastern gemeinsam erarbeitet, welcher PO das Produktcluster führen soll und welcher Scrummaster das jeweilig darauf aufbauende Team unterstützt.

Workshop zur Selfselection der Teammitglieder

Die festgelegten drei Klammern aus Themen und jeweiligen Führungskräften (PO und Scrummaster) konnten nun mit Mitarbeitern zu neuen Teams zusammenmgestellt werden.

Dazu initiierten wir einen weiteren Workshop unter der Teilnahme aller beteiligten Mitarbeiter jeglicher Fachrichtung und Spezialisierung, allen POs, allen Scrummastern und den Linienführungskräften.

Da auch die endgültige Teamaufstellung in Zukunft von möglichst vielen Mitarbeitern getragen werden sollte, wurde auch für diesen letzten Workshop viel Augenmerk auf Transparenz und Mitgestaltungsmöglichkeit des Einzelnen gelegt.

Dazu erstellten die POs im ersten Schritt Steckbriefe ihres jeweiligen Teamklammern. Darauf dargestellt waren   die in Zukunft anstehenden Themen und die festgelegten Führungsrollen (PO und Scrummaster).

Zusätzlich enthielten sie die zu erwartenden (budgetär) Aufwände in Personentagen und das abzudeckende technische Know-How. Weitere Randbedingungen galten für alle Teams. So zum Beispiel sollte mindestens ein Fachentwickler und mindestens ein Softwarearchitekt in jedem Team vorhanden sein. Auch war Bedingung, daß das Team autarkt fähig sein sollte, ihre jeweiligen Anwendungen weiterzuentwickeln (Dev) und zu betreiben (Ops).

Damit suchten sich die Mitarbeiter in einem iterativen Prozess die für sie passenden Teamklammern aus. Jede Iteration bestand aus folgenden Schritten:

1. Mitarbeiter finden ihr Team

2. Die entstandenen Teams werden anhand der Rahmenbedingungen (s.o.) evaluiert

3. Einsprüche und Anmerkungen werden aufgenommen

Nebenabsprachen, Telefonate, Gespräche in Pausen und so weiter waren für die Teamfindung explizit erlaubt um den Mitarbeitern bei der Entscheidung genügend Raum und Privatsphäre zu ermöglichen. Auch war der Workshop auf zwei Tage angelegt um „nochmal eine Nacht darüber schlafen zu können“.

Einsprüche und Anmerkungen waren von allen Mitarbeitern möglich und erwünscht, auch wenn sie sich auf andere Teams bezogen.

Resultat und Folgen

Es entstand eine Aufstellung mit drei Teams. Die Teams waren dadurch etwas größer als in der vorherigen Aufstellung mit vier Teams. Mit je ca. 12 Mitarbeitern war damit eine für uns noch vertretbare maximale Größe erreicht (mehr zu Nachteilen von großen Teams bei J.R. Hackman: „Leading Teams“).

Die Vorteile der neuen Struktur erschienen jedoch zu überwiegen. Ich durfte die Teams noch eine Zeit weiter als Agile Coach begleiten. Die Struktur schien passend um die anstehenden Arbeitsaufträge und Produktweiterentwicklungen abzubilden. Trotz der etwas beschränkten Flexibilität des Komponentenschnitts an sich hielt sich die Aufgabenfülle für alle Teams in einer guten Balance. Auch waren Abstimmungen über Teamgrenzen hinweg nur selten notwendig.

Allgemein wurde die neue Struktur sehr positiv aufgenommen und in der Breite von Mitarbeitern und Führungskräften getragen.