Das Scaled Agile Framework® (SAFe®) besteht aus einer Reihe von Organisations- und Workflow-Mustern zur Implementierung von Agile-Praktiken im gesamten Unternehmen. Das Framework ist eine Wissenssammlung mit strukturierten Leitlinien zu Rollen und Zuständigkeiten, zur Planung und Verwaltung von Aufgaben und zu förderungswürdigen Werten.
SAFe fördert die Abstimmung, Zusammenarbeit und Ausführung über zahlreiche Agile-Teams hinweg. Im Mittelpunkt stehen dabei drei Themenbereiche: Agile-Softwareentwicklung, Lean-Produktentwicklung und Systemdenkweise.
Wenn Unternehmen wachsen, liefert SAFe einen strukturierten Ansatz zur Skalierung von Agile. Es gibt vier SAFe-Konfigurationen für verschiedene Skalierungsebenen: Essential SAFe, Large Solution SAFe, Portfolio SAFe und Full SAFe.
Dean Leffingwell und Drew Jemilo haben SAFe im Jahr 2011 veröffentlicht, um Unternehmen die Entwicklung besserer Systeme und besserer Software in Abstimmung mit den sich ändernden Kundenanforderungen zu ermöglichen. Bis zu diesem Zeitpunkt nutzten Teams herkömmliche Projektmanagementprozesse für die Softwareentwicklung. Als es jedoch immer wichtiger wurde, schnell auf veränderte Marktbedingungen zu reagieren, entstanden neue Frameworks zum Verbessern der Lösungsbereitstellung im gesamten Unternehmen. Damit war SAFe geboren. Heute ist SAFe eines der meistverwendeten Frameworks für die skalierte Agile-Bereitstellung, und eine weltweite Anwender-Community arbeitet ständig an seiner Weiterentwicklung.
Grundlegende Prinzipien und Werte
Grundlegende Werte
Die grundlegenden Werte von SAFe beschreiben eine Kultur, die Führungskräfte fördern müssen, und die von den Mitarbeitern innerhalb dieser Kultur erwarteten Verhaltensweisen, die zu einer effektiven Nutzung des Frameworks beitragen.
Abstimmung
SAFe verlangt feste Rhythmen für die Planung und Reflexion auf allen Ebenen des Unternehmens. Sind diese gegeben, kennen alle Mitarbeiter den aktuellen Stand und die Ziele des Unternehmens und wissen, wie alle gemeinsam auf diese Ziele hinarbeiten können. Durch die regelmäßig stattfindende Abstimmung zwischen Mitarbeitern und Aktivitäten bleiben alle Ebenen des Portfolios konstant aneinander ausgerichtet Die Informationen fließen zeitnah von unten nach oben und umgekehrt. Dies unterscheidet SAFe von den herkömmlichen Top-Down-/Command-and-Control-Strukturen.
Integrierte Qualitätssicherung
Das SAFe-Framework gibt vor, dass Flexibilität niemals zulasten der Qualität gehen darf. Bei SAFe müssen alle Teams auf allen Unternehmensebenen definieren, was "erledigt" bei ihren Aufgaben jeweils bedeutet. Außerdem müssen sie Praktiken zur Qualitätssteigerung fest in allen Arbeitsvereinbarungen verankern. Gemäß SAFe gibt es fünf Dimensionen der integrierten Qualitätssicherung: "Flow", Architektur- und Designqualität, Codequalität, Systemqualität und Release-Qualität.
Transparenz
SAFe fördert vertrauensstärkende Verhaltensweisen wie das Unterteilen von Aufgaben in kleinere Elemente, damit Probleme schneller zutage treten. Außerdem soll der Backlog-Fortschritt auf allen Ebenen in Echtzeit einsehbar sein, und es werden Rituale zur Überprüfung und Anpassung verlangt.
Programmumsetzung
Die Programmumsetzung steht im Mittelpunkt von SAFe und bildet die Grundlage für alles andere im Framework. Teams und Programme müssen in der Lage sein, regelmäßig hochwertige, funktionsfähige Software auszuliefern und einen geschäftlichen Mehrwert zu schaffen.
Unternehmensführung
SAFe erfordert ein Führungsverhalten nach Lean-Agile-Prinzipien, weil nur die Führungskräfte das System ändern und eine für alle grundlegenden Werte vorteilhafte Umgebung schaffen können.
Die Prinzipien von SAFe
Ziel der Prinzipien des Scaled Agile Frameworks ist es, das Unternehmen als Ganzes zu optimieren, indem eine Entscheidungsfindung nach Lean-Agile-Prinzipien über funktionale und organisatorische Grenzen hinweg angeregt wird. Die Prinzipien sollen die Entscheidungsfindung nicht nur bei Führungskräften und Managern beeinflussen, sondern bei allen Mitarbeitern des Unternehmens. Außerdem sollen sie die Denkweise weg vom herkömmlichen Wasserfallmodell und hin zu Lean-Agile lenken. In diesem Zuge werden Praktiken wie das Lean Portfolio Management angewendet.
Prinzip 1: Ökonomische Sichtweise
Ausgehend von den Theorien zum Workflow der Produktentwicklung aus Donald Reinertsens erfolgreichen Büchern ist die kürzestmögliche Vorlaufzeit nur zu erreichen, wenn sich jeder Einzelne in der Entscheidungsfindungskette der wirtschaftlichen Auswirkungen möglicher Verzögerungen bewusst ist. Frühzeitige und häufige Auslieferungen sind nicht immer ausreichend. Laut SAFe sind alle im Unternehmen dafür verantwortlich, die Aufgabenabfolge optimal zu gestalten, ökonomische Kompromisse zu verstehen und mit knappen Budgets zurechtzukommen. Viele der Konzepte und Tools sind aus Reinertsens Theorie zum Workflow der Produktentwicklung abgeleitet.
Prinzip 2: Systemdenkweise
SAFe soll dazu anregen, in drei wichtigen Bereichen eine Systemdenkweise an den Tag zu legen: bei der Lösung selbst, bei dem das System entwickelnden Unternehmen und bei den Wertströmen. Mit "Lösungen" sind Produkte, Services oder Systeme für interne oder externe Kunden des Unternehmens gemeint.
Da umfangreiche Lösungen aus vielen miteinander verbundenen Einzelteilen bestehen, sollten die Teammitglieder eine Vorstellung davon haben, wie sich die von ihnen gelieferten Bestandteile in das große Ganze einfügen. In Bezug auf das Unternehmen, das ein System entwickelt, sollten laut SAFe die Mitarbeiter, das Management und die Prozesse des Unternehmens berücksichtigt werden. Wenn ein Unternehmen also die Arbeitsweise seiner Mitarbeiter optimieren möchte, müssen unter Umständen Silos beseitigt, funktionsübergreifende Abläufe eingerichtet und neue Arbeitsvereinbarungen mit Zulieferern und Kunden formuliert werden. Und schließlich sollte das Unternehmen durch Wertströme für die Entwicklung klar definieren, wie der Weg vom Konzept zur tatsächlichen Wertschöpfung aussieht. Die Unternehmensführung und das Management müssen den Wertstrom über Funktions- und Organisationsgrenzen hinweg optimieren.
Prinzip 3: Veränderlichkeit als Annahme; Offenhalten von Optionen
Das Entwickeln von Systemen und Software bringt immer ein gewisses Maß an Unsicherheit mit sich. Dieser Unsicherheit begegnet dieses Prinzip mit dem Konzept des Set-Based Design (SBD). Dabei wird im Entwicklungszyklus über längere Zeit eine höhere Anzahl an Anforderungen und Designoptionen beibehalten. In späteren Prozessphasen werden empirische Daten eingesetzt, um die endgültige Designoption einzugrenzen.
SBD fördert eine fundierte Entscheidungsfindung bei Unsicherheit, indem die Optionen und beabsichtigten Ergebnisse klar benannt werden – ähnlich wie bei strategischen Wetten. Das Konzept der Integration von "Informationsmeilensteinen", die Fristen für Entscheidungen vorgeben, ist bei SBD entscheidend: Je mehr Informationen die Teams mit der Zeit zusammentragen, umso mehr Wahlmöglichkeiten entfallen, und umso einfacher ist es, die richtige Vorgehensweise zu finden, die schließlich zum bestmöglichen Ergebnis für die Kunden führt.
Prinzip 4: Inkrementelle Entwicklung mit schnellen, integrierten Lernzyklen
Ähnlich wie bei Prinzip 3 werden Risiken und Unsicherheiten hier durch Informationsmeilensteine gemindert. Es genügt nicht, wenn die einzelnen Komponenten eines Systems funktionsfähig sind. Vielmehr müssen Teams das ganze System betrachten, um die Umsetzbarkeit der aktuellen Designoptionen zu bewerten. Zur Beschleunigung der Lernzyklen müssen regelmäßige Integrationspunkte eingeplant werden. Diese Integrationspunkte sind ein Beispiel für den auf Walter Andrew Shewhart zurückgehenden Demingkreis, ein Framework für kontinuierliche Qualitätsverbesserungen und ein Mechanismus zur Steuerung der Variabilität bei der Entwicklung. Shewarts Ideen und daraus abgeleitete Konzepte finden sich an vielen Stellen in SAFe wieder.
Prinzip 5: Meilensteine auf der Basis einer objektiven Bewertung der Arbeitssysteme
Eine Demonstration in Form eines echten, funktionierenden Systems ist eine bessere Basis für die Entscheidungsfindung als ein Anforderungsdokument oder ein anderes oberflächliches Erfolgskriterium. Werden Stakeholder schon früh in Machbarkeitsentscheidungen einbezogen, unterstützt dies den Aufbau von Vertrauen und die Systemdenkweise.
Prinzip 6: Visualisierung und Begrenzung von laufenden Arbeiten (Work in Progress, WIP), Verkleinerung von Batches und Management der Warteschlangenlänge
Wenn die laufenden Arbeiten begrenzt sind, können Stakeholder den Fortschritt besser beurteilen.
Die drei Elemente dieses Prinzips stehen für die wichtigsten Methoden zur Durchsatzmaximierung und Beschleunigung der Wertschöpfung – mit anderen Worten: zur Implementierung eines "Flows". Wie heißt es so schön? Auch große Ziele erreicht man in kleinen Schritten.
Übertragen auf die Softwareentwicklung bedeutet dies, Überschneidungen bei Aufgaben, die Komplexität der einzelnen Aufgabenelemente und den Gesamtumfang der parallel laufenden Arbeiten zu begrenzen. Werden die Batches klein gehalten, können Teams fortlaufend überprüfen, ob sie noch auf Kurs sind, und die Warteschlangen bleiben übersichtlich.
Dieses Prinzip liefert Anhaltspunkte zur Optimierung, damit die bestmöglichen Ergebnisse erzielt werden.
Prinzip 7: Fester Rhythmus, Abstimmung mit der bereichsübergreifenden Planung
Agile-Teams verfolgen automatisch einen festen Rhythmus, weil sie in Sprints oder Iterationen arbeiten. Wenn für alle Bereiche feste Rhythmen gelten, verringert dies die Komplexität, reduziert Unsicherheiten, stärkt das "Muskelgedächtnis", fördert die Qualität und unterstützt die Zusammenarbeit. Aufeinander abgestimmte Rhythmen sorgen dafür, dass die Mitarbeiter und Aktivitäten wie Zahnräder ineinandergreifen, wobei neu gewonnene Erkenntnisse als Grundlage für die Entscheidungsfindung und inkrementelle Planung dienen.
Prinzip 8: Förderung der intrinsischen Motivation von Wissensarbeitern
Dieses Prinzip geht auf den Managementberater Peter Drucker und den Autor Daniel Pink zurück und ist bei uns sehr beliebt. Es geht darum, das volle Potenzial aus Teams herauszukitzeln und den Führungskräften zu vermitteln, dass sie sich als Coaches im Auftrag ihres Teams sehen sollten und nicht als Bestandteil eines Command-and-Control-Systems.
Prinzip 9: Dezentrale Entscheidungsfindung
Durch die Verkürzung der Warteschlangen und die aus wirtschaftlicher Sicht sinnvolle dezentrale Entscheidungsfindung erhalten Teams die nötige Autonomie, um ihre Aufgaben effektiv zu erledigen. Die Führungskräfte sollten nur dann Entscheidungen treffen, wenn es um Themen mit strategischer Bedeutung geht. In allen anderen Bereichen sollten sie die Teams nur bei der eigenständigen Entscheidungsfindung unterstützen.
Wie funktioniert SAFe?
Unternehmen, die zur Implementierung von SAFe bereit sind, wissen in der Regel die Unternehmensführung hinter sich, haben gewichtige Argumente für die Umstellung und eine Grundlage für Scrum.
Scaled Agile, Inc. bietet eine Roadmap zur Implementierung von SAFe an, die ausführliche Anleitungen zu den ersten Schritten und zur Vorbereitung des Unternehmens auf die umfassende Einführung von SAFe in den verschiedenen Portfolios enthält. Folgende 12 Schritte werden zur Implementierung von SAFe empfohlen:
- Den Wendepunkt erreichen
- Mitarbeiter schulen, die Veränderungen nach Lean-Agile-Prinzipien vorantreiben sollen
- Führungskräfte, Manager und Teamleiter schulen
- Ein Lean-Agile-Exzellenzzentrum einrichten
- Wertströme und ARTs (Agile Release Trains) ermitteln
- Den Implementierungsplan erstellen
- Die ART-Einführung vorbereiten
- Teams schulen und den ART einführen
- Coaching zur ART-Durchführung anbieten
- Weitere ARTs und Wertströme einführen
- Auf das Portfolio ausweiten
- Pflegen und optimieren
Was unterscheidet SAFe von anderen Frameworks zur Skalierung von Agile?
Das Scaled Agile Framework® (SAFe®) ist in Unternehmen mit großen Softwareentwicklungsteams weit verbreitet. Dennoch haben mit der Zeit auch andere Frameworks zur Skalierung von Agile an Beliebtheit gewonnen. Allen diesen Frameworks sind fünf wichtige Komponenten gemein: Sie beruhen auf den 12 Prinzipien aus dem Agilen Manifest und geben einen festen Rhythmus, Abstimmung, Scrum und Praktiken zur Qualitätsentwicklung vor. Wenn ein Unternehmen die Grundlagen anderer Frameworks, die wichtigsten Unterscheidungsmerkmale und die Bedingungen für eine erfolgreiche Anwendung kennen, können sie besser entscheiden, welches Framework zu ihren Anforderungen passt.
Weitere Informationen über einige der gängigsten Frameworks zur Skalierung von Agile findest du im Agile Coach auf der Übersichtsseite zur Skalierung von Agile.
SAFe im Vergleich mit Scrum@Scale
Bei Scrum@Scale (S@S) sind alle Mitarbeiter Teil eines austauschbaren Scrum-Teams. Je nach Ziel kommt ein Netzwerk aus Scrum-Teams zusammen und bildet ein Ökosystem. Zweck von S@S ist es, dieses Netzwerk aus Scrum-Teams mittels einer "skalierungsfreien Architektur" zu erreichen. Das heißt, die grundlegenden Scrum-Rollen und -Ereignisse werden linear skaliert, ohne neue Prozessdynamiken einzuführen. Wenn beispielsweise ein Scrum of Scrums (SoS) für ein sehr komplexes Produkt mit 25 Scrum-Teams nicht ausreicht, ist möglicherweise ein Scrum of Scrum of Scrums (SoSoS) mit einem Scrum of Scrum of Scrums Master (SoSM) erforderlich.
Insgesamt sind die Vorgaben bei S@S weniger strikt, aber es gibt eine wichtige Frage, mit der Unternehmen ermitteln können, ob sie bereit für die Skalierung sind: Wenn weitere Mitarbeiter zum System hinzukommen, steigt dann die Leistung exponentiell, oder leidet die Produktivität?
Ähnlich wie bei SAFe finden sich bei S@S online Referenzinhalte, darunter ein umfassender Leitfaden zu Scrum@Scale, der sich zunehmender Beliebtheit erfreut.
Unter diesen Bedingungen ist S@S am effektivsten:
- Der Technologie-Stack ist objektorientiert (d. h. vertikale User Storys können innerhalb von zwei Wochen geliefert werden).
- Das Unternehmen hat Feature-Teams mit "T-Shaped Professionals", produktorientierten Werten und wenig Bürokratie.
- Ein Tool für Agile oder Agile Lifecycle Management (ALM) wird erst benötigt, wenn die entsprechenden Praktiken schon fest etabliert sind.
- Das Führungsteam ist gewillt, Scrum zu praktizieren und Hindernisse für das Unternehmen aus dem Weg zu räumen.
SAFe im Vergleich mit Large-Scale Scrum (LeSS)
Large-Scale Scrum (LeSS) verfolgt einen minimalistischen Ansatz für Rollen, Strukturen und Artefakte. Während SAFe je nach Teamgröße und Lösungskomplexität vier Konfigurationen vorsieht, gibt es bei LeSS nur zwei Konfigurationen: LeSS für zwei bis acht Teams und LeSS Huge für mehr als acht Teams. LeSS verlangt für Produktinhaber die alleinige Entscheidungsbefugnis über Inhalte und strategischen Einfluss, wohingegen SAFe einen demokratischeren Ansatz fördert. Bei SAFe fließen viele Faktoren in Strategieentscheidungen ein, bei LeSS dagegen ist ein kundenorientierter Ansatz mit Schwerpunkt auf zahlenden Kunden entscheidend.
Ähnlich wie bei S@S erfolgt die Skalierung bei LeSS ausgehend von Scrum-Ereignissen, -Artefakten und -Rollen. Bei SAFe und LeSS spielen eine Systemdenkweise, Lean-Denken und ähnliche Leitprinzipien eine wichtige Rolle. Allerdings liegt der Schwerpunkt bei LeSS auf der Reduzierung unnötiger Arbeiten und Elemente im Unternehmen zum Zwecke der kontinuierlichen Verbesserung.
Unter diesen Bedingungen ist LeSS am effektivsten:
- Die Scrum-Teams sind Experten für Scrum.
- Die Unternehmensführung ist bereit, zur fortlaufenden Optimierung immer wieder umzustrukturieren und zu experimentieren.
- Es herrscht Übereinstimmung über die Definition des Produkts.
- Es herrscht Übereinstimmung über die Definition von "erledigt".
- Externe Coaches arbeiten mit Gruppen aus dem Unternehmen, Teams und technischen Vertretern zusammen.
- Es sind Feature-Teams statt Komponententeams mit "T-Shaped Professionals" vorhanden.
- Das Unternehmen ist bereit, sich vollständig von Projektmanagementparadigmen zu verabschieden.
SAFe im Vergleich mit Disciplined Agile (DA)
Im Gegensatz zu den übrigen hier beschriebenen Frameworks ist Disciplined Agile (DA) ein Toolkit, mit dem Unternehmen selbst entscheiden können, welche Arbeitsweise am besten zu ihnen passt. Es bietet Agile-Governance in geringem Umfang auf der Grundlage von Scrum und Kanban. Hinzu kommen Informationen zur Transformation in Bereichen wie Personalwesen, Finanzen, Governance, DevOps und Portfoliomanagement. Bei DA wird die Skalierung je nach Projekt situativ angepasst. Der Schwerpunkt liegt auf Unterstützung bei der Entscheidungsfindung im Hinblick auf die strategische Ausrichtung.
Unter diesen Bedingungen ist DA am effektivsten:
- Einzelne Unternehmensbereiche möchten ihren eigenen Weg zur Skalierung von Agile festlegen.
- Einzelne Unternehmensbereiche möchten innerhalb des Unternehmens flexibel bleiben.
- Einzelne Unternehmensbereiche möchten ihre gewählten Prozesse und/oder Frameworks beibehalten.
SAFe im Vergleich mit Spotify
Das Spotify-"Modell" ist ein mitarbeiterzentrierter, autonomer Satz an Praktiken zur Koordinierung von Agile-Teams. Es war eigentlich nie als Modell oder Framework vorgesehen, wurde aber von einigen Unternehmen als solches implementiert. Im Mittelpunkt von Spotify stehen sich selbst organisierende, funktionsübergreifende Teams, die sich am selben Standort befinden. Sie werden als "Squads" bezeichnet und ähneln einem Scrum-Team. SAFe dagegen schreibt nicht vor, dass die Teams am selben Standort arbeiten müssen, empfiehlt dies jedoch für die PI-Planung.
Die Squads sind zu größeren Einheiten zusammengeschlossen, den sogenannten "Tribes". Es bestehen nur wenige Abhängigkeiten zwischen den Squads. Bei Bedarf werden Abhängigkeiten durch Scrum of Scrums gemanagt. Der Wissensaustausch wird durch informelle Gruppen ermöglicht, die nach Kompetenzen und Interessen zusammengestellt sind und als "Chapters" und "Guilds" bezeichnet werden.
Bei Spotify gibt es keine Online-Ressourcen, Schulungen oder Zertifizierungen abgesehen von einem öffentlich zugänglichen Blog und einigen von Spotify-Pionieren und -Fans erstellten Begleitmaterialien. Das Modell wird allerdings immer beliebter, sodass künftig mit weiteren Ressourcen zu rechnen ist.
Unter diesen Bedingungen ist Spotify am effektivsten:
- Das Unternehmen wendet die Ideen in seinem eigenen Kontext an.
- Im Mittelpunkt der Unternehmenskultur stehen ständiges Dazulernen, Fehlertoleranz und das Eingehen kontrollierter Risiken.
- Die Teams und Produkte sind "lose verbunden, aber eng aufeinander abgestimmt", um Abhängigkeitskonflikte zu vermeiden.
SAFe 5.0
Ein zentraler Grundsatz von SAFe ist die ständige Weiterentwicklung des Frameworks in Zusammenarbeit mit der weltweiten Anwender-Community. Vor Kurzem hat Scaled Agile, Inc. Version 5.0 von SAFe veröffentlicht. Zu den wichtigsten Neuerungen zählen das neue zehnte Prinzip "Organisation auf der Grundlage des Werts" und dass Schritt 12 von "Pflegen und optimieren" in "Beschleunigen" geändert wurde. Das ist aber noch längst nicht alles. Möchtest du noch mehr erfahren? Lies unseren Blog zu Neuerungen und Änderungen bei SAFe 5.0.
Fazit
Frameworks wie SAFe und die anderen oben genannten sind eine gangbare Option für Unternehmen, Agile effektiv zu skalieren und ihre geplanten Geschäftsergebnisse zu erreichen. Ebenso wichtig sind jedoch die Tools, die du auswählst, um deine bestehenden Praktiken zu erweitern und in den Genuss aller Vorteile dieser Praktiken zu kommen. An diesem Punkt kommt Jira Align von Atlassian ins Spiel, eine Enterprise-Plattform für die Agile-Planung, die speziell für SAFe konzipiert ist. Mit Jira Align kannst du die Transparenz, die strategische Ausrichtung und die Anpassungsfähigkeit des Unternehmens verbessern und so die digitale Transformation beschleunigen.
