SAFe-Fallstudien: Transformationshinweise aus der Praxis

Dieser Artikel ist Teil drei von Toptals Serie zur agilen Skalierung, die Projektmanager bei ihren Bemühungen zur Teamerweiterung anleiten soll. Lesen Sie auf jeden Fall Teil 1, „5 Agile Scaling Frameworks im Vergleich: Welche sollten Sie verwenden?“ und Teil zwei, „Agile Skalierung: SAFe Best Practices für Scrum Master“.

Laut dem 15. Annual State of Agile Report wird Agilität in irgendeiner Weise von 94 % der Unternehmen praktiziert. Aber die Forschung zeigt auch, dass 90 % der Organisationen mit der unternehmensweiten Agile-Implementierung zu kämpfen haben. Typischerweise ist es die Arbeit von Agile-Coaches, Scrum-Mastern und anderen Projektmanagement-Experten, diese Bemühungen zu leiten und zu organisieren. Oft arbeiten sie mit veränderungsresistenten Teams oder Abteilungen in einer schwer verständlichen Unternehmenskultur.

In diesem Roundtable diskutieren drei Toptal-Projektmanager die Herausforderungen bei der Führung agiler Transformationen. Da ihre Lösungen mit dem Scaled Agile Framework (SAFe) kompatibel sind, sprachen wir auch mit Dean Leffingwell, dem Schöpfer von SAFe. Ihre kollektiven Erkenntnisse verdeutlichen die Notwendigkeit für SAFe-Praktiker, eine klare Vision davon zu erstellen, was Agilität ist, und einen Führungsplan, der widerspenstige Teams an Bord bringen kann.

Sprechen Sie mit dem Schöpfer des Frameworks über SAFe

SAFe, ein von Scaled Agile formalisiertes Framework, stammt aus dem Jahr 2014. Aber für Leffingwell begann die Arbeit, als er Anfang der 2000er Jahre zum ersten Mal auf agile Teams traf. Als Softwareentwicklungsmethodologe war er beeindruckt von den Ergebnissen agiler Praktiken in Entwicklungsteams und begann sofort zu untersuchen, wie die Denkweise auf ein gesamtes Unternehmen angewendet werden könnte. Wenn ein agiles Team Ergebnisse produzieren könnte, was könnte dann ein Team aufeinander abgestimmter agiler Teams produzieren? Wie können agile Praktiken für umfassende Transformationsprojekte in nationalen oder internationalen Unternehmen eingesetzt werden? Wie Leffingwell es ausdrückt: „Ich liebe Softwareentwicklung. Ich liebe Agilität. Ich will es einfach groß haben.“

Seitdem haben Unternehmen die Vorteile von SAFe erkannt, darunter kürzere Lieferzeiten, höhere Produktqualität, größere Effizienz und engagiertere Mitarbeiter. Im Jahr 2021 nutzten mehr als ein Drittel der Organisationen auf der ganzen Welt SAFe, und zu den wichtigsten Aspekten gehören die gemeinsamen Prozesse und die einheitliche Sprache, die es bietet. Wenn zum Beispiel ein Team denkt, dass ein Sprint zwei Wochen dauert und ein anderes, dass es 30 Tage sind, entsteht das, was Leffingwell als „Turm zu Babel-Problem“ beschreibt. Es ist schwierig für Teams, darüber zu diskutieren, welche Features hinzugefügt werden sollen, wenn sie sich nicht einmal darauf einigen können, was „Feature“ bedeutet. „Man [braucht] Leute, die auf eine gemeinsame Art und Weise arbeiten, wenn man große Lösungen entwickeln will“, sagt er. „Es gibt keinen Begriff in unserer Branche, der nicht überladen wäre, wie ‚Iteration' oder ‚Sprint' oder ‚Backlog'. Das ist nicht hilfreich, wenn man versucht, über Team- und Regionsgrenzen hinweg zu arbeiten.“

Agile Erfolgsgeschichten

Es ist eine entmutigende Aufgabe, jeden in einem Unternehmen dazu zu bringen, eine einheitliche Art zu sprechen und Arbeit zu erledigen, selbst wenn Veränderungen dringend erforderlich sind. In etablierten Konzernen kann es schwieriger werden. Leffingwell führt aus: „Sie sehen sich die größten Unternehmen der Welt an, die viel Geld verdienen und unglaublich gut abschneiden und konkurrieren – und sie müssen sich ändern. Nun, die Frage für sie ist, warum sollten sie?“ Die hier vorgestellten Toptal-Projektmanager sind während ihrer eigenen Skalierungsaktivitäten auf Fragen wie diese gestoßen und haben jeweils ihre eigene Art und Weise gefunden, ihre agilen Transformationen mit SAFe zu bearbeiten.

Wert demonstrieren

Alvaro Villena, ein Toptal-Projektmanager in Santiago, Chile, hat kürzlich eine SAFe-Umstellung für ein Portfolio abgeschlossen, das eine geschäftsübergreifende Plattform entwickelt. „Der erste Meilenstein meiner Umstellung war die Durchführung eines Wertstrom-Workshops“, sagt er. Einfach ausgedrückt ist ein Wertstrom-Workshop ein Kickoff-Meeting, um den gesamten Geschäftsprozess vom Konzept bis zur Lieferung und alle Schritte, Benutzer, Systeme und Schmerzpunkte dazwischen zu identifizieren.

Die Einbindung von Vertretern des gesamten Unternehmens in den Workshop half Villena dabei, die Unternehmenskultur und seine Hindernisse zu verstehen. „Bevor wir den Workshop implementierten, gab es eine Struktur, in der ein Unternehmen sein Team hatte, ein anderes Unternehmen sein Team und das nächste Unternehmen sein Team – die drei sprachen nicht miteinander.“

Villena stellte fest, dass, obwohl alle Teams ähnliche Schmerzpunkte teilten, es keine Zusammenarbeit bei Lösungen gab. Obwohl beispielsweise jedes Unternehmen im Portfolio Produkte versendete, hatte nur eines ein Tracking-System entwickelt. Es gab keinen Grund, warum sie es nicht alle nutzen konnten, außer dass niemand das Wissen geteilt hatte. Sobald der Workshop sie zum Reden gebracht hatte, begann das Wissen zwischen Teams, Unternehmen und Product Ownern zu fließen. „Diese Art von Gespräch war wirklich, wirklich kraftvoll für das Programm. Es war ein guter Ausgangspunkt“, sagt Villena. Wenn DevOps, Design und Produkt alle wissen, was andere Teams tun, sehen sie, dass es Lösungen im Unternehmen gibt, die sie verwenden können. „Sie fangen an zu fragen: ‚Wie kann ich das haben?' Und da springen Sie ein und sagen: ‚Folgen Sie diesem Prozess.'“

„Niemand will Veränderung, bis er weiß warum. Also beginnst du mit einem Warum und gibst ihnen eine bessere Zukunft.“ Dean Leffingwell, Schöpfer von SAFe

Leffingwell weiß, dass Teams manchmal widerspenstig sind. „Niemand will Veränderung, bis er weiß warum“, sagt er zu Toptal. „Also beginnst du mit einem Warum und gibst ihnen eine bessere Zukunft.“ Teams einen Eindruck davon zu vermitteln, wie viel effizienter sie sein können, ist ein wirkungsvolles Werkzeug für Change Leadership.

Auch wenn alle begeistert an Bord sind, sollten Sie dennoch mit holprigen Starts rechnen. Teams, die beispielsweise an die traditionelle Wasserfallentwicklung und große Releases gewöhnt sind, haben möglicherweise Schwierigkeiten, zu einem iterativeren und agileren Entwicklungsprozess überzugehen, selbst wenn sie den Wert darin sehen. „Die erste Programmerhöhung, die wir durchgeführt haben, war für die Teams eine Art Desaster“, sagt Villena. „Und wir wussten, dass es so sein würde; Wir haben dem Kunden gesagt, dass er damit rechnen soll, dass die ersten drei Monate schwierig sein könnten.“ Um dies zu kompensieren, baute er am Ende des ersten Programminkrements (PI) eine einmalige einwöchige Iteration ein, in der die Teams ihren Fortschritt bewerten konnten. Er organisierte einen Sprint, der ausschließlich Prozessverbesserungen und -bewertungen gewidmet war, die über das übliche Prüfen und Anpassen hinausgingen. Er fand es nützlich, eine agile Denkweise nicht nur auf das Produkt, sondern auch auf den Geschäftsübergang anzuwenden, indem er sich die Zeit nahm, einen Schritt zurückzutreten, zu sehen, was funktionierte und was nicht, und sich entsprechend anzupassen.

Kleine Siege schaffen

Es ist wichtig, auf unerwartete Hindernisse bei Ihrer SAFe-Einführung vorbereitet zu sein. Vor einigen Jahren stellte Toptal-Projektmanager Miroslav Anicin in Belgrad, Serbien, ein Telekommunikationsunternehmen auf SAFe um. Das Unternehmen hatte seine gesamte Softwareentwicklung ausgelagert. Die Einbindung eines Offsite-Teams war keine besonders mühselige Aufgabe – die damit verbundenen Probleme waren hauptsächlich logistischer Natur. Aber die Bemühungen führten zu unvorhergesehenen Herausforderungen bei der Umstellung des Unternehmens selbst. „Ich war auf der Suche nach den Kompetenzen, die wir im Entlassungszug brauchen“, sagt er. „Und alle Leute, aus denen ich wählen musste, kamen aus dem Marketing, aus der Rechtsabteilung, aus dem Produktbereich, aus dem Finanzbereich – ihnen fehlte völlig die agile Denkweise oder sogar jegliche Erfahrung in Agile.“

Es zeigte sich, dass das Management keine Erfahrung im Umgang mit agilen Teams hatte. Verteilte Entscheidungsfindung erfordert, dass Manager einen Teil der Kontrolle abgeben, eine Tatsache, vor der Führungskräfte zurückschrecken können, wenn sie keine Erfahrung mit agilen Frameworks haben. Um dies zu lösen, musste Anicin von unten nach oben und von oben nach unten trainieren und Führungskräfte zusammen mit ihren Teams coachen.

Ein solcher Übergang zu einer stärker dezentralisierten Entscheidungsfindung erfordert „eine Änderung der Arbeitsweise von Befehl und Kontrolle über dienende Führung hin zu dieser ermächtigenden Kultur des Lernens und der agilen Kultur – und der Fähigkeit, Fehler zu tolerieren“, sagt Leffingwell.

Anicin begann den Prozess der schrittweisen Skalierung – mit kleinen Agile-Projekten, die in einzelnen Teams durchgeführt wurden, nicht innerhalb eines SAFe-Frameworks – damit einzelne Teams praktische Erfahrungen sammeln konnten. Diese Projekte mussten unwesentlich und klein genug sein, damit das Unternehmen keinen Schaden erleidet, wenn beim ersten Versuch etwas schief geht, aber nützlich genug, um dem Team zu zeigen, was mit dem Ansatz erreicht werden kann. Beispielsweise erstellte das Marketingteam eine interne Marketingkampagne, während der Anicin ihnen die Grundlagen von Scrum beibrachte. Ähnlich wie in Villenas Workshop demonstrieren diese kleineren Projekte den realen Wert von Agile, sodass Teammitglieder und Führungskräfte die Vorteile kurzer Releases und kontinuierlicher Verbesserungen vor dem vollständigen Übergang erkennen können.

Erfüllen Sie die Bedürfnisse Ihrer Teams

Als Imane Marouane, Toptal-Projektmanagerin mit Sitz in Paris, eine Transformation für ein großes, multinationales Finanzinstitut leitete, trat sie in ein chaotisches Umfeld ein, in dem einzelne Teams solide Arbeit leisteten, aber keine unternehmensweite Vision teilten. „Jedes Team hatte seine eigene Priorität. Jeder Produktmanager wollte, dass sein Produkt zuerst geliefert wird.“

Die Lösung von SAFe für dieses Problem findet sich im Weighted Shortest Job First (WSJF)-Modell. WSJF bietet einen Standard für die Priorisierung von Aufgaben. Wenn es also an der Zeit ist, zu entscheiden, was die nächste Aufgabe sein sollte, beinhaltet der erste Schritt keine Streitigkeiten darüber, wie man die Wichtigkeit einordnet. In einem Flow-basierten Agile-System müssen Sie sich keine Gedanken darüber machen, alles auf einmal zu liefern, denn wie Leffingwell sagt: „Das Wichtigste ist, welche Aufgabe als Nächstes zu erledigen ist. Und diese Frage ist viel einfacher zu beantworten als die Frage, was der wertvollste Job ist.“ SAFe bietet eine Möglichkeit, Abhängigkeiten zwischen Teams aufzulösen – die Reihenfolge der Aufgaben ist für dieses Ergebnis unerlässlich.

Marouanes Weg zur Auflösung von Abhängigkeiten wurde ungewiss: „Nach zwei Sprints, vor der ersten Inspektion und Anpassung, stellten wir fest, dass einige Teams unseren PI-Plan nicht befolgten.“ Abhängigkeiten, die im PI-Plan definiert waren, wurden nicht befolgt, sodass die Arbeit eines Teams nicht beginnen konnte, weil der Beitrag eines anderen Teams noch nicht fertig war.

„Da es sich um die erste Iteration handelte und die Teams an diese Art von Arbeit nicht gewöhnt waren, entschieden wir uns für eine zusätzliche Zeremonie – ein wöchentliches Treffen, um den Fortschritt bei den Abhängigkeiten zu besprechen“, sagt Marouane. „Eine Person aus jedem Team kam, um den Fortschritt ihrer Beiträge zu aktualisieren.“ Wenn Team A sagte, dass es nicht liefern könne, könnte Team B auf diese Weise im Voraus wissen und entsprechend planen, anstatt auf Beiträge zu warten, die zu Beginn ihres Sprints nicht zustande kommen würden.

Leffingwell mahnt zur Vorsicht bei derartigen Anpassungen von SAFe: „SAFe ist ein System von Verantwortlichkeiten. … Sie können es anpassen, aber Sie müssen wirklich vorsichtig sein.“ Obwohl das Framework anpassungsfähig sein soll, neigen Änderungen dazu, sich festzusetzen, wenn sie nicht neu bewertet werden. Die Essential SAFe-Konfiguration ist vorhanden, um sicherzustellen, dass alle Änderungen grundlegende Kriterien erfüllen.

Marouanes zusätzliche Zeremonie war wieder im zweiten PI enthalten, und beim dritten war sie auslaufen gelassen worden. Die Teams hatten nichts zu berichten, was nicht bereits kommuniziert worden war. Ein wenig zusätzliche Flexibilität ermöglichte es Marouane, die Teams wieder auf eine traditionellere Prozessschiene zu bringen. Sie stellte fest, dass der Übergang selbst eine agile Denkweise erforderte, um das Beste aus den Teams des Finanzinstituts herauszuholen. Und was noch wichtiger ist, die von ihr vorgenommene Änderung durch ihr Engagement für kontinuierliche Verbesserung diente letztendlich den Lean-Agile-Prinzipien, die die Grundlage von Essential SAFe bilden. Ihre Lösung verlieh dem Unternehmen die fehlende einheitliche Vision und ermöglichte es den Teams, gemeinsam auf dieselben Prioritäten hinzuarbeiten.

An die Zukunft anpassen

Jedes Framework, das in großem Maßstab betrieben wird, wird mit Herausforderungen einhergehen. Die Anzahl beweglicher Teile und konkurrierender Interessen ist immens. Aber die Vorteile sind ebenso groß, und ein gut durchgeführter Übergang gibt den Teams die Werkzeuge an die Hand, die sie benötigen, um auf gemeinsame Ziele hinzuarbeiten. Die Hindernisse, denen Sie bei einer so umfangreichen Implementierung begegnen, werden unvorhersehbar sein, und eine agile Denkweise half Villena, Anicin und Marouane, sich an unerwartete Herausforderungen anzupassen. Schließlich ist Continuous Delivery dafür da: Ihren Prozess mit den Tools auszustatten, mit denen er sich an das Unvorhergesehene anpassen kann.

Scaled Agile passt sich auch an neue Technologien und sich entwickelnde Industriestandards an und führt bei Bedarf neue Tools und Funktionen ein. Jeder muss agil bleiben und sich auf das Unerwartete vorbereiten. „Wir haben keine Kristallkugel“, sagt Leffingwell. „Wir rennen einfach schnell, führen hart und folgen hart – und schreiben so schnell wir können.“