Ein Großprogramm auf Scaled Agile Framework umzustellen bedeutet Veränderung – auf organisatorischer, methodischer, kultureller und technologischer Ebene. Wir haben einen internationalen Versicherungskonzern dabei begleitet und möchten in dieser Artikelreihe den Programmhintergrund, die Best- und Worst-Practices und daraus resultierende Maßnahmen teilen.
Wir begleiteten die Tochterfirma eines internationalen Versicherungskonzerns mit ca. 5.000 Mitarbeitenden bei der Standardisierung und Harmonisierung des Reportings und der Finanzbuchhaltung nach diversen Übernahmen von Unternehmen auf drei Kontinenten. Zusätzlich diente die Transformation als Experiment und Leuchtturmprojekt zur Verprobung für eine umfassendere agile Transformation der Gesamtorganisation.
Nachdem das Programm zuvor im klassischen Wasserfall-Ansatz nicht die erwünschten Ergebnisse lieferte, entschied sich der Kunde für eine Vorgehensweise nach SAFe® (Scaled Agile Framework). Auf der einen Seite waren Ziele und Zeitrahmen aufgrund externer rechtlicher Vorgaben relativ eindeutig vorgegeben, auf der anderen Seite jedoch herrschten Unsicherheiten bezüglich der Zielarchitektur und den benötigten Technologien vor. Aufgrund der vorher gemachten Erfahrungen war schnell klar, dass ein hoher Bedarf an Experimenten, schnellen Feedbacks und regelmäßigen Kurskorrekturen bestand.
Das grobe Ziel des Programms war, das Reporting innerhalb von 1,5 Jahren so zu standardisieren, dass der Kunde sowohl einheitlich als auch grenzübergreifend gesetzeskonform agiert. Das Programm musste eine Vereinheitlichung von drei Tochterfirmen auf drei Kontinenten (USA, Europa, Asien) mit unterschiedlichen Technologien, Tools und gesetzlichen Standards sicherstellen. Dabei galt es auch drei verschiedene Unternehmenskulturen mit unterschiedlichen Erfahrungen bezüglich Management, Strukturen und Projektmanagement zu berücksichtigen.
Durch die Entscheidung zur Nutzung einer agil skalierten Vorgehensweise war dies zugleich der Probelauf für eine agile Transformation der gesamten Organisation.
Generell benötigte der Wechsel ein agiles Grundverständnis im Programm – das Vorwissen war aufgrund sowohl externer als auch interner Mitarbeitenden vielfältig aufgestellt und musste im Zusammenspiel mit der Veränderungsbereitschaft praktiziert werden.
Auch die gesetzlich vorgegebene Zeitvorgabe stellte die Organisation vor die Herausforderung, Kapazitäten effizient und wertorientiert einzusetzen, um Überlastungen am Ende des Programms zu vermeiden.
Zeitrahmen und Budget
Der Zeitrahmen wurde durch externe Vorgaben definiert – innerhalb von zwei Jahren musste eine Umstellung des Reportings den rechtlichen Vorgaben gemäß erfolgen. Das Budget war nicht einzelnen Ergebnisartefakten zugeordnet, sondern stand ganz im agilen Sinn dem kompletten Programm zur Verfügung und wurde entsprechend flexibel je nach aktueller Priorisierung eingesetzt und auf die beiden Agile Trains und die darin enthaltenen Teams umgeleitet.
Gemäß der SAFe Implementation Roadmap konnten alle beteiligten Teams die Theorie nach einer Trainingsphase zügig on-the-job anwenden. Hilfreich war die Einführung einer Fehlerkultur, die zunächst weniger auf strikte Perfektion, denn auf das Framework-Verständnis und die Methodennutzung abzielte. Dies war vor Allem notwendig, da direkt ab Stunde Null das Framework Essential SAFE zum Einsatz kam. Später wurde das Programm auf die Konfiguration nach Portfolio SAFe ausgeweitet.
Innerhalb weniger Wochen startete das Programm mit einem ersten Agile Release Train (ART), bestehend aus vier Teams. Der initiale Startpunkt war dabei das erste PI-Planning, das aufgrund der umfangreichen Trainings und der DoppeIbesetzung von Schlüsselrollen durch erfahrene Proxys schon einen vergleichsweisen guten Reifegrad hatte. Im späteren Verlauf ergänzte ein weiterer ART das Programm, um den zahlreichen weiteren Anforderungen Rechnung zu tragen.
Um die SAFe-Operationalisierung zu beschleunigen, wurden außerdem Epics erst nachträglich durch Epic Owner definiert und zunächst hauptsächlich mit Features gearbeitet. Die Features konnten im Nachgang zu Epics zugeordnet und aggregiert werden. Bei der zeitlichen Strukturierung aller agilen Teams orientierte man sich konsequent von Beginn an auf die empfohlenen SAFe-Standards mit Programm-Inkrementen von jeweils 5+1 Sprints à zwei Wochen. Die Sprints der Teams waren miteinander synchronisiert.
Die Vorgehensweise zur Transformation wurde bewusst nahe am SAFe-Standard in der Portfolio-Konfiguration gewählt (siehe Organigramm). Dies erleichterte die Kollaboration zwischen den heterogenen Teams zu Beginn, da es schneller ein klares einheitliches Verständnis zum Zusammenarbeitsmodell gab, obwohl die agilen Vorkenntnisse sehr verschieden und teilweise nur rudimentär ausgeprägt waren. Dies resultierte insbesondere aus dem Fakt, dass die Hälfte der Mitarbeitenden durch unterschiedliche Dienstleister bereitgestellt wurde.
Mit dem zunehmenden gemeinsamen Verständnis der unternehmensspezifischen Vor- und Nachteile, die sich aus der Anwendung des SAFe-Frameworks ergeben, ergab es später durchaus Sinn, über größere oder kleinere Adaptionen nachzudenken. Nur eben nicht zu Beginn der Transformation, sondern unter Reflexion der gewonnen Erfahrungen.
Das Programm diente als Verprobung, ob die agile Transformation sich auch auf die gesamte Organisation ausrollen lässt. Vor diesem Hintergrund formierte sich schon zu Beginn ein sogenanntes LACE-Team – zunächst bestehend aus Externen, später sukzessive um interne Teammitglieder mit Best-Practice-Erfahrungen ergänzt. So konnte das Wissen um Agilität initial in die Organisation eingebracht und nachhaltig etabliert werden.
Erfahren Sie mehr über die Aufgaben des Lean Agile Center of Excellence
Eine agile Transformation unter Nutzung von SAFe-Standards bedeutet Veränderung. Deswegen musste genau diese Veränderung vom Management bis ins C-Level verstanden, kommuniziert und gelebt werden. Das Leadershipteam war dafür zuständig, die organisatorischen Leitplanken vorzugeben, während die Freiheitsgrade bis hin zur Teamebene bestehen blieben. Das Management muss in einem solchen Changeprozess nahbar und präsent sein – dies kann durch folgende Maßnahmen geschehen:
Innerhalb der Teams zeigten die Erfahrungswerte, dass Schlüsselrollen (z. B. Release Train Engineer, Product Owner und System Engineer) intern besetzt werden sollten. Um sowohl qualitativ als auch quantitativ eine schnelle Umsetzung der agilen Transformation zu gewährleisten, wurden die Schlüsselpersonen von externen, erfahrenen Proxys zu methodischen Vorgehensweisen und Best-Practices gecoacht. Die Proxys waren somit fester Bestandteil der Teams und konnten die weniger erfahrenen Mitarbeitenden coachen.
Um einen Blick von außen sicherzustellen, wurden das Management und die Teams durch erfahrene Agile Coaches unterstützt, die kontinuierlich bei allen Facetten der agilen Transformation begleiteten und unterstützen. Coaches agieren dabei nicht als Teil des Systems, sondern gewährleisten eine neutrale Sichtweise und hinterfragen kontinuierlich die Vorgehensweisen.
In dem Programm galt das Umkehrprinzip, was konkret bedeutet: Es wurde ein umfänglicher Zugriff auf Inhalte und Tools gewährleistet und geschützte Bereiche mussten – inklusive einer Begründung – beantragt werden. Dieses Vorgehen vereinfacht den Know-how-Transfer deutlich.
Daneben wurden teamübergreifende Events durch das LACE initiiert, was den Austausch innerhalb der gesamten Organisation bzw. mit anderen Konzerneinheiten forcierte.
Die PI-Plannings wurden von Beginn an mit allen direkten Beteiligten durchgeführt. Sukzessive wurden weitere Beschäftigte eingeladen, die Methode für agile, skalierte Planung als Best-Practice kennenzulernen und zu erleben.
Teams kennen die Rollenbedarfe am besten – deswegen sollten sie auch mitentscheiden, wer im Team nach- oder neubesetzt werden soll. Im konkreten Fall musste aus rechtlichen Gründen ein sehr guter Freiberufler mit tiefgreifenden Spezialkenntnissen innerhalb eines Teams nachbesetzt werden. Beim zunächst von der Personalabteilung und Product Owner ausgewählten Kandidaten zeigte sich in kürzester Zeit, dass er sowohl kulturell als auch im agilen Mindset auf Ablehnung beim Team stieß, trotz hervorragender Fachkenntnisse. Aus dieser Erfahrung heraus wurden bei späteren Nachbesetzungen die agilen Teams durch Product Owner und Personalabteilung involviert wurden.
Zum Beispiel durch „Speed Dating“-Formate können gerade bei Großprojekten einerseits die agilen Teams mit mehreren potenziellen Kandidaten parallel sprechen und andererseits erlaubt es diverse Betrachtungen im Hinblick auf den Personal Fit.
Ein agiles, skaliertes Management benötigt ein einheitliches und gemeinsam genutztes Planungstool, mit der Möglichkeit alle Tools der Anforderungsanalyse und Delivery Pipeline (automatisiertes Testen, Integration, Deployments, Releases) wie z.B. Jira, HP ALM, confluence, TOSCA, Jenkins, Docker, GitHub zu integrieren.
Inzwischen gibt es von den bekannten Anbietern wie Atlassian, Microsoft oder HP ausgereifte Produkte, die die agilen Events und Methoden entsprechend unterstützen. Vorab genutzte Projekt-Tools sollten so früh und schnell wie möglich abgelöst werden. Die Steuerung und Optimierung der Tools können durch das LACE-Team sowie ein agiles Project Management Office (PMO) in Abstimmung mit den Release Train Egineers (RTE) und Scrum Mastern gesteuert werden. Ebenfalls durch das LACE-Team sollten bei Bedarf Schulungen und Coachings zu den Tools geplant und angeboten werden.
