Ein Großprogramm auf SAFe® (Scaled Agile Framework) umzustellen bedeutet Veränderung – auf organisatorischer, methodischer, kultureller und technologischer Ebene. Im ersten Teil der Artikelreihe haben wir bereits den Projekthintergrund und die Best Practices aus der Versicherungsbranche beleuchtet. In diesem Teil weiten wir den Fokus und legen ein besonderes Augenmerk auf Optimierungsfelder bei der Einführung von SAFe und daraus resultierende Maßnahmen.
In vielen Fällen wird eine agile, skalierte Transformation begonnen, ohne dass der Großteil der betroffenen Teams vorab Wissen über die anstehenden Veränderungen erlangt. Es geht nicht darum, dass man in Zukunft nun mit einem Kanban-Board arbeitet. Die Veränderung einer wirklichen agilen Transformation – wie hier nach dem SAFe Framework – ist wesentlich umfangreicher und geht weit über den Einsatz einzelner Methoden hinaus.
Der Umfang und die Herangehensweise einer Transformation lässt sich gut anhand der nachstehenden vier Dimensionen – Mindset, Organisation, Methodologie und Technologie – veranschaulichen. Je nach Ausgangslage und Zielvorstellung des Unternehmens werden die einzelnen Dimensionen unterschiedlich priorisiert. Mit einem zunehmenden Reifegrad verändern und erweitern sich dann im Idealfall auch die Prioritäten.
Gerade zu Beginn der Transformation sollte sich das Management über die Ausprägungen in den Themenbereichen für ihre Organisation klar werden und dieses Zielbild und insbesondere den Nutzen kommunizieren. Auf dieser Basis sollten Schulungsangebote für Mitarbeitende zur Verfügung gestellt werden, die auf die zukünftigen Rollen spezifisch zum SAFe Framework angepasst sind. Wir empfehlen dringend, dass in einem ersten Schritt so viel agile Erfahrung wie möglich in einzelnen Teams aufgebaut wird, bevor ein Unternehmen eine Skalierung bzw. agile Transformation ganzer Unternehmensbereiche in Erwägung zieht. Wir erleben in der Praxis häufig, dass diese wichtige Phase aus Gründen der Dringlichkeit zu kurz kommt und Mitarbeitende agiles Arbeiten quasi „on the job“ lernen müssen.
Auch in unserem konkreten Kundenkontext war dies der Fall. Immerhin wurden alle Projektmitarbeitenden (intern wie extern) je nach Rolle spezifisch zum SAFe Framework geschult (Leading SAFe, SAFe4Teams, SAFeDevOPs), um ein Grundverständnis sicherzustellen.
Mitarbeitende, die von Veränderung betroffen sind, wünschen sich oft einen „perfekten“ Fahrplan mit klarer Rollenbeschreibung und dem idealen Schnitt der agilen Teams bzw. Agile Release Trains (ARTs) oder Value Streams. Befürchtungen, der Veränderung nicht standzuhalten, sind die Ursache. Als Agile Coaches ermutigen wir unsere Kunden und deren Mitarbeitende, sich nicht ewig mit der Findungsphase aufzuhalten, sondern sich nach einer initialen Vorbereitungsphase von circa einem Quartal in das „Abenteuer zu wagen“. Es gehört zum Prozess der agilen Transformation dazu, dass sich Personen, Teams, ARTs selbst hinterfragen und sich die Strukturen und Zusammensetzung im Zeitablauf verändern. Diese Offenheit zur Veränderung gilt es im Mindset aller Beteiligten zu verstetigen.
Mitarbeitende haben oft die Erwartungshaltung oder zumindest die Hoffnung, sich durch Trainings allein perfekt für eine Rolle vorbereiten zu können. Hier gilt es durch die Führungskräfte und den „Change Agents“ immer wieder zu kommunizieren, dass man „im selben Boot“ sitzt, gemeinsam neue Arbeitsweisen erlernt und insbesondere auf das 70-20-10-Modell des „Center for Creative Leadership“ verweist.
Das Lernen wird in diesem Modell wie folgt aufgeteilt:
Dies bedeutet konkret: Wir bilden uns weiter. Dies ist jedoch nur ein kleiner Teil der Lernerfahrung. Vielmehr geht es darum, schnell in die Praxisumsetzung zu kommen, um den neuen Arbeitsalltag zu begreifen.
Wir alle haben ein bestimmtes Wertesystem, geprägt durch unser berufliches und privates Umfeld. Agile Events, Rollen und Artefakte geben uns zwar einen groben Rahmen vor, jedoch ist die Grundlage für die Zusammenarbeit ein gemeinsames Werteverständnis. Es ist der ausschlaggebende Punkt für psychologische Sicherheit innerhalb eines Teams und für einen guten Umgang miteinander. Daher empfehlen wir gerade zum Start bzw. bei der Zusammensetzung neuer Teams, diesen Aspekt nicht zu unterschätzen und entsprechend zu berücksichtigen. Insgesamt spricht man von fünf Agilen Werten:
Retrospektiven innerhalb der Teams dienen dazu einzuordnen, inwieweit die Kolleg:innen sich im Team sicher und respektiert fühlen und offen über Probleme sprechen können. Bei unserem Kunden haben wir mit Umfragen im Zyklus der PI-Plannings gute Erfahrungen gemacht, um Veränderungen wahrzunehmen.
Die agilen Werte sprechen sehr konkret darüber, dass Werte wie Mut und Offenheit unumgänglich sind, um die psychologische Sicherheit innerhalb eines Teams sicherzustellen, was die Grundlage eines „high-performing Teams“ ist. Teammitglieder sollen die Möglichkeit haben, Veränderungen kritisch zu hinterfragen und Probleme/ Impediments anzusprechen, die sie in ihrer täglichen Arbeit behindern. Diese werden wiederum von Scrum Master und Release Train Engineer aufgenommen und eingeordnet.
Manche Probleme sind jedoch nicht auf Team- oder nicht mal auf Projektebene zu lösen – regulatorische Bedingungen oder spezifische Unternehmensentscheidungen können Impediments innerhalb der Teams entstehen lassen. Dies kann zu langwierigen Diskussionen führen – man versucht Lösungen zu finden, ohne jedoch die Kontrolle darüber zu haben, auf diesen Ebenen Entscheidungen zu treffen oder das ganze System zu verändern.
Hier kann der „Circle of Influence“ ein Instrument sein, Projektmitglieder über den Handlungsspielraum aufmerksam zu machen und nach der LCL-Methode („Love it, Change it oder Leave it“) zu leben.
Ein Beispiel ist der oft streng regulierte Releaseprozess bei Finanzinstituten. Dieser hemmt die Schnelligkeit der Produktivstellungen von Lösungen oder Produkten, jedoch ist er bei regulierten Institutionen notwendig und verpflichtend. Diese Problematik soll innerhalb der Teams auch offen besprochen und diskutiert werden. Mit Hilfe des „Circle of Influence“ konnten wir den Teams zeigen, welcher Handlungsspielraum bei dieser Herausforderung realistisch umsetzbar ist.
Agile Release Trains bestehen in der Theorie aus 50 bis 125+ Mitarbeitenden. Abhängig von der Programmgröße erfordert dies bei den gemeinsamen Events wie dem PI Planning eine ausgeklügelte Event-Koordination und -Moderation inkl. Timeboxing (wir empfehlen eine Art „Master of Ceremonies“ vorab zu definieren).
Doch das ist nicht alles – durch die Breite an Themen, die durch die Teams abgedeckt werden, muss insbesondere bei den Plenum-Sessions als auch den Reviews auf eine zielgruppengerechte Präsentationsweise geachtet werden. Die Teams sollten nicht den Eindruck haben, für die Quantität, sondern für den Mehrwert einer Präsentation geschätzt zu werden. Inhalte sollten auf das Wichtigste beschränkt werden und das ART Management den „Mut zur Lücke“ fördern. Der Sinn eines Reviews ist kein Statusmeeting, sondern Feedback seitens anderer Teams und Stakeholder einzuholen.
Ein schönes Beispiel aus der Praxis ist das Kiosk-Prinzip auf PI Plannings in Präsenz. Unerfahrene Product Manager oder Architekt:innen verwenden bei ihren ersten PI Plannings viel Zeit und Umfang auf den initialen Präsentationen zu Vision, Features und technischen Rahmenbedingungen. Die Erfahrung zeigt uns, dass hier weniger oft mehr ist, da kaum jemand in der Lage ist, die Menge an Informationen so schnell zu verarbeiten. Besser ist es, initial nur einen ersten Überblick zu geben und den Interessierten im Verlauf der Planningtage die Details an separaten Kioskständen im Dialog zu vermitteln. Alle relevanten Informationen sollten natürlich generell für alle auch digital transparent abgelegt sein.
Der letzte Sprint eines PIs, die sogenannte Innovation and Planning Iteration (IP) zielt darauf ab, dass die Teams Zeit bekommen – Zeit, um Neues auszuprobieren, um letzte Arbeiten abzuschließen („leftover work“) und sich auf das nächste PI vorzubereiten.
Unsere Erfahrung ist hier, dass viele Mitarbeitende die Sinnhaftigkeit und Nutzung der IP-Iteration unklar sind. Hier gilt es insbesondere seitens Managements und Scrum Mastern klar zu kommunizieren, dass diese Zeit als Wertschätzung gegenüber den Teams zu sehen ist und ihnen Zeit geschenkt wird, die sie frei verplanen können.
PIs sind in der Regel 8-12 Wochen lang. Vor der Definition des Ausgangsdatums ergibt es Sinn, vorab einen Blick auf den Kalender zu werfen, um zum Beispiel PI Plannings im weiteren Jahresverlauf zu kritischen Zeiten wie Messen, Urlaubszeiten, Feiertagen usw. möglichst zu vermeiden. Dadurch werden erhöhtes Fehlen bei erfolgskritischen Events vermieden.
Im Idealfall arbeiten SAFe Teams ausschließlich in ihrem Agile Release Train, um den Aufwand des Kontextwechsels zu verringern. In der Realität ist es jedoch oft der Fall, dass intern besetzte Rollen (z.B. Product Owner) weiterhin Parallelaufgaben aus der Linienorganisation verantworten müssen. Zum Teil ist es auch der Fall, dass man PI Plannings sowohl im Agile Release Train als auch in der Linienorganisation durchführt.
Wie also kann man kurzfristig die Situation entspannen?
Gerade die Proxys für Product Owner sind zu Beginn ein sehr wichtiges Asset des Programms und übernehmen viele Tätigkeiten im agilen Setup. Es sollte dennoch darauf geachtet werden, dass Proxys als initiale Coaches zu sehen sind und sie sukzessive die Aufgaben an interne Schlüsselrollen weitergeben. Unserer Erfahrung nach sollte ein Proxy nicht länger als zwei Jahre in der Position bleiben. Bis dahin sollte die interne Schlüsselrolle kapazitär für den Agile Release Train verfügbar sein und die benötigten Grundlagen eines Projektes nach SAFe verstehen.
Ein langer Atem ist gefragt, wenn ein Projekt über mehrere Jahre hinweg geplant ist. Gerade in solchen Projekten sind Solution Roadmaps unabdingbar, um die Teams motiviert zu halten und die Disziplin über lange Zeiträume zu gewährleisten. Es sollten „Zwischenerfolge“ gefeiert werden, bei IT-lastigen Projekten beispielsweise durch Release Partys.
Auch darf gerade bei überwiegend remote arbeitenden Teams Abwechslung in den Alltag eingebracht werden – etwa durch ein Onsite PI Planning, Sprintwechsel vor Ort, oder Konferenzformate zum Wissensaustausch. Hier sind der Kreativität der Scrum Master keine Grenzen gesetzt. Im Austausch mit anderen Scrum Mastern in internen, wie externen Zirkeln kann ein Scrum Master auf viele bereits verprobte Ideen zurückgreifen oder einfach mal in den Teams nachfragen, was ihnen Spaß macht und was für sie „Wertschätzung“ bedeutet.
Einer unserer Scrum Master überraschte uns zuletzt mit der Idee, eine Retro im Stile von Star Wars aufzusetzen. Das eingespielte, inzwischen „Retro-müde“ Team, war begeistert und durch den völlig anderen Blickwinkel kamen Probleme zum Vorschein, die mit Standard-Retro-Formaten nur schwer entdeckt worden wären. Nutzen Sie also Ihre Fantasie.
Tools lösen keine prozessualen oder methodischen Probleme. Sie können jedoch die Zusammenarbeit stärken, wenn der Nutzungsumfang pro Tool klar ist, Schnittstellen zwischen den Tools existieren und der Zweck der verschiedenen Tools einen Mehrwert für Mitarbeitende liefern.
Von daher möchten wir dazu raten, zuerst vom funktionalen Bedarf auszugehen und auf Basis dessen ein Tool auszuwählen. So vermeiden Sie „Tool-Hopping“ – ein Beispiel ist hier die Darstellung von Impediments seitens der Scrum Master. Hier gab es auf einem Projekt verschiedene Möglichkeiten, etwa Online-Whiteboards, Jira Boards oder Wiki-Formate wie Confluence. Es wurde mehrfach das Tool gewechselt, weil im Nachhinein gemerkt wurde, dass wesentliche Funktionalitäten in dem entsprechenden Tool nicht abgedeckt wurden (so bspw. das Abbilden von Metriken).
Außerdem und gerade in komplexen IT-Projekten sollte es ebenso unabdingbar sein, sich für ein einheitliches Planungstool für alle Arbeitsebenen (Epics, Features, User Stories) zu entscheiden. Je komplizierter die Tool-Landschaft, umso mehr leidet darunter die Qualität der definierten Arbeitspakete und manuelle Fehler entstehen. Je länger eine Konsolidierung bestehender Toollandschaften hinausgezögert wird, desto größer werden die Widerstände und Aufwände. Hier empfehlen wir unseren Kunden eine frühzeitige Entscheidung und Fahrplan für die Migration.
Die oben genannten Themen und Beispiele sind nur einige ausgewählte Erfahrungen aus aktuellen Kundenprojekten, die sich gerade mitten in der agilen Transformation – oft nach dem SAFe Framework oder dessen Adaption – befinden.
Falls Sie sich ebenfalls mit diesen Herausforderungen beschäftigen oder diese erst auf sich zukommen sehen, fragen Sie uns gerne ganz unverbindlich an.
Wir bieten Ihnen Erfahrungsaustausch und Referenzbesuche mit anderen Kunden mit ihrem Szenario, Workshops für schnelle Bearbeitung einzelner kritischer Themen und natürlich auch langfristige Beratungsleistungen während ihrer Transformation.
