Viele agile Regelwerke bieten einen Prozessrahmen für Einzelteams, die hochgradig agil arbeiten möchten. Sie helfen aber nicht, wenn ganze Unternehmen agiler werden möchten bzw. um Projekte mit großen oder mehreren Teams abzuwickeln. Hier kommt das SAFe Scaled Agile Framework ins Spiel. Dieses soll als Skalierungsansatz Unternehmen auf dem Weg in agile Arbeitsweisen unterstützen.
Lesen Sie in diesem Artikel, wie das gelingen kann und erhalten Sie Tipps zur konkreten Umsetzung mit Links zu mehr Informationen. Sie erfahren in drei Teilen:
- Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?
- Teil 2: SAFe – Voraussetzungen, Aufbau, erste Schritte
- Teil 3: Unterschied SAFe zu anderen Skalierungs-Rahmenwerken
- Könnte SAFe der richtige Ansatz für Ihr Unternehmen sein?
- Zusammenfassung
Legen wir los mit der Definition von SAFe Scaled Agile Framework.
Definition SAFe Scaled Agile Framework
Die Abkürzung SAFe steht für „Scaled Agile Framework“. Es bietet ein Rahmenwerk für größere Unterfangen oder Unternehmen, die agiles Projektmanagement leben wollen und sich in einer agilen Transformation befinden. SAFe gehört aktuell zu den beliebtesten Skalierungslösungen und eignet sich auch für hybrides Projektmanagement.
Hinter SAFe steht die Organisation Scaled Agile Inc., die auch Zertifizierungen im Zusammenhang mit SAFe anbietet. Gegründet wurde sie von Dean Leffingwell. Er schrieb in seinem Buch „Agile Software Requirements“ bereits 2010, wie man agile Ansätze unternehmensweit skalieren kann.
Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?
In den letzten Jahrzehnten ist die Zahl der agil arbeitenden Teams stark angestiegen. Das gilt nicht nur für IT-Abteilungen, die lange eine Art Vorreiterstellung hatten. Jetzt sind auch immer mehr andere Bereiche in Organisationen betroffen.
Die Landschaft agiler Ideen wirkt dabei oft wie ein Flickenteppich: So vielseitig wie die verschiedenen Methodenwerke Scrum, Kanban oder Extreme Programming – XP u.a. sind, so unterschiedlich arbeiten auch die Teams bei der Umsetzung.
Die Vielfältigkeit der Vorgehensweisen macht es schwer, sich untereinander und mit Kunden abzustimmen. Außerdem werden häufig auf Teamebene bereits viele Veränderungen umgesetzt und gelebt, aber wenig davon dringt in der Unternehmenshierarchie weiter nach oben.
Zudem geben Leitfäden (z.B. der Scrum Guide) keine Auskunft, wie bei Projekten mit mehr als einem Umsetzungsteam von drei bis neun Leuten vorzugehen ist. Ganz zu schweigen von untereinander abhängigen, parallellaufenden Projekten.
Dies liegt daran, dass der Scrum Guide versucht, Antworten auf eine ganz bestimmte Fragestellung zu geben: Welche Prozesse eignen sich für agile Arbeitsweisen?
Andere Fragen, wie etwa „welche gedanklichen Einstellungen müssen dahinterstehen?“ oder „welche Techniken wenden wir an, um hohe Qualität der Ergebnisse sicherzustellen?“ bleiben weitestgehend unangesprochen.
Skalierungs-Frameworks wie SAFe bieten hier einen Ansatz, methodische Lücken zu schließen: Sie vereinheitlichen die unternehmensweite Einführung agiler Ideen und Methoden auf eine Weise, die ein systematisches Vorgehen erleichtert.
Auch wenn inzwischen die Auswahl der Skalierungs-Ansätze selbst etwas unübersichtlich wird, ist SAFe das derzeit beliebteste und am meisten verbreitete Skalierungs-Rahmenwerk.
Auf einen Blick: Was unterscheidet Scrum von SAFe?
Warum die Umsetzung agiler Methodenwerke oft scheitert
In einzelnen Teams agile Arbeitsweisen einzuführen, das kann bereits ein Umdenken bewirken. So können Sie vor allem auf Einzelteam- bzw. Einzelprojektebene Erfolge erzielen. Und Prozesse, Innovationen oder die Beteiligung von Teams und Stakeholdern lassen sich bereits deutlich beweglicher gestalten – sofern es Ihr Umfeld erlaubt.
Aber: Die große Herausforderung ist, dass Pionierteams intern und bei der Zusammenarbeit mit anderen Firmen schnell auf Hindernisse stoßen.
Diese Hindernisse liegen oft an unterschiedlichen Auffassungen, dem „Mindset“.
Versucht ein neues Scrum Team sich im Projekt an die agilen Prozesse, Rollen und Arbeitsweisen zu halten, gibt es häufig folgende Reibungspunkte:
- Fehlendes methodische Verständnis: Internen Stakeholdern, Kunden oder Nutzer:innen des entwickelten Produkts ist oft nicht oder nicht ausreichend bewusst, was das Scrum Team tut und warum.
Beispiel: Ein Kunde soll zu Ende jedes Sprints zum Review-Meeting Feedback zum bis dato entwickelten Produkt abgeben. Er kann dies aber kaum bis gar nicht einrichten. Oder: Ein Scrum-Team braucht eine Person mit speziellen Entwicklungskenntnissen in Vollzeit, um Deadlines einhalten zu können. Diese Person wird aber auch von anderen dringend gebraucht. - Ungeeignete Verträge: Kundenaufträge sind nicht auf Bedürfnisse von Scrum Teams zugeschnitten.
Beispiel: Manche Vertragsmodelle für agile Projekte sehen eine Teilung nicht verbrauchten Rest-Budgets nach Projektbeendigung vor. Dies soll die Kostenrisiken fairer aufteilen und für ein konstruktives Streben nach gemeinsamen Zielen sorgen. Budgetplanungs-Prozesse in vielen großen Unternehmen geben eine solche Freiheit allerdings gar nicht her. Daher sind solche Vertragsklauseln nicht umsetzbar. - Ungeeignete Unternehmensorganisation: Viele Firmen sind nach wie vor stark in Silos organisiert.
Beispiel: Ein Scrum Team möchte möglichst abteilungsübergreifend an einer neuen Lösung arbeiten. Kolleg:innen in diesen Abteilungen sind eine solche Art der Zusammenarbeit aber nicht gewohnt. Und es fehlen auch die räumlichen Möglichkeiten, sich kollaborativ auszutauschen. - Klassische strategische Ausrichtung: Firmen, die in Projekten zusammenarbeiten, haben manchmal völlig unterschiedliche Vorstellungen von Agilität und auch verschiedene Reifegrade.
Beispiel: Ein Dienstleister für Softwareentwicklung hat viel Erfahrung in agilen Methoden und möchte mit dem Kunden für ein neues Projekt zunächst eine Produktvision mithilfe von neuen Methoden wie Lego Workshops entwickeln. Der Kunde reagiert irritiert und ist zögerlich in der Bereitschaft, an einem solchen Workshop überhaupt teilzunehmen. Er zieht es vor, schwer verständliche Use Cases per E-Mail zu schicken. - Projekt- statt Produktorientierung: Die Produktorientierung, die agile Teams für ihre Motivation und zielgerichtete Arbeit brauchen, ist vielen Firmen noch völlig fremd.
Beispiel: Ein Scrum Team plant seine Sprints so, dass jeder im Team die selbst gesetzten Ziele im Sprint kennt. Vorgesetzte des Product Owners haben jedoch andere Vorstellungen davon, woran die Leute im Team genau jetzt arbeiten sollten – Sie „funken“ mit abweichenden Anforderungen dazwischen. Da der Product Owner um seinen Job fürchtet, wenn er sich nicht an die Anweisungen hält, gibt er diese ungefiltert weiter. In der Folge sinkt die Motivation des Teams bezüglich der eigenen Planung von Sprint zu Sprint – da dies sowieso nicht haltbar sein wird.
Diese Liste ließe sich weiter fortsetzen. Die Szenarien aus den Beispielen sind so alle bereits vorgekommen und ereignen sich häufig.
Wie können Skalierungs-Frameworks hier helfen?
Im Prinzip geht es darum, bei allen Beteiligten ein „agiles Bewusstsein“ zu schaffen:
- Führungskräfte eines Unternehmens verschreiben sich bestimmten Werten des agilen Mindsets. Damit können einzelne Teams und am Ende die ganze Organisation erfolgreicher sein.
- ALLE Projektbeteiligten und Stakeholder leben diese Einstellung täglich bei ihrer Arbeit – das gilt auch für Kundenfirmen und Dienstleister.
- Teams innerhalb der Organisation ziehen alle am gleichen Strang, anstatt bei der Zusammenarbeit in Konkurrenz zu treten.
- Bei weltweit verteilten Standorten gibt es eine gemeinsame und durchdachte Strategie.
SAFe bietet viele Ansätze, wie ein wichtiges und großes Vorhaben gelingen kann. Es ist damit aber – wie andere Skalierungs-Frameworks auch – nicht als Blaupause zu verstehen.
Teil 2: SAFe – Voraussetzungen, Aufbau und erste Schritte
Wichtige Voraussetzung für SAFe
SAFe liefert konkrete Vorschläge, wie Sie mit der hohen Komplexität bei Prozessskalierungen umgehen. Dabei ist wichtig zu wissen, dass die Umsetzung Zeit sowie eventuell Schulungen erfordert.
Tipp: Greifen Sie zu Beginn Ihres Weges in die Agilität Ihrer Organisation auf jeden Fall auf Menschen mit Erfahrung und Kenntnissen in Scrum und skalierenden Ansätzen zurück.
Der „State of Agile“-Bericht nennt bei der Einführung von Skalierungs-Frameworks die folgenden fünf Top-Erfolgsfaktoren:
Wie ist SAFe aufgebaut?
SAFe basiert auf neun Prinzipien, angelehnt an Ideen und Prinzipien aus dem Agilen Manifest. Der wesentliche Unterschied zu den klassischen Richtlinien liegt im Aufbau der einzelnen Rollen und Ebenen pro Ausbaustufe (Anforderungen an Projekt- bzw. Teamgröße / Anzahl der Teams).
Die Ausbaustufen von SAFe
Möchten Sie SAFe als Rahmenwerk einführen, sollten Sie sich zunächst zwei Dimensionen bewusst machen:
- Wie stufen wir unsere Vorhaben im Hinblick auf Komplexität und Größe ein? Hier können Sie die untenstehende Tabelle zu Rate ziehen. Das „Essential SAFe Toolkit“ bietet weitere Anhaltspunkte zur Selbsteinordnung. Auch erfahrene SAFe Berater:innen können dabei helfen. Bei Unsicherheit gilt: lieber erst einmal die Umsetzung der Prinzipien in der einfachsten Stufe ausprobieren, bevor ein Ansatz konzernweit ausgefahren wird.
- Welche Ebenen sollen einbezogen werden? Geht es uns mehr um die Einzelteam- und Programmebene? Oder betrachten wir unsere Arbeitsweisen gleich auf Portfolioebene? Oder gar für einen ganzen Großkonzern (Large Solution und bei international agierenden auch Full SAFe)?
SAFe bietet je nachdem, wie Sie diese Frage für Ihre Situation beantworten, verschiedene Ausbaustufen hinsichtlich Projektkomplexität und -größe.
Tipp: Einen guten Überblick erhalten Sie mithilfe der Grafik auf scaledagileframework.com – klicken Sie dort auf die einzelnen Reiter, um das Diagramm für jede der Stufen zu sehen.
Zum besseren Verständnis gehen wir folgend näher auf die Ausbaustufen, einbezogenen Ebenen und Rollen in SAFe ein.
Die SAFe-Stufen im Einzelnen
Die Ebenen im Einzelnen
Je umfangreicher die Skalierung und je komplexer die Anforderungen, desto mehr Ebenen sollten Sie zur Erledigung der Aufgaben pro Stufe einbeziehen:
- Teamebene: SAFe nutzt das normale Scrum Team Setup und wandelt dies ein wenig ab. Pro Team kümmern sich fünf bis neun (statt in Scrum drei bis neun) Developer um die Umsetzung. Sie werden begleitet von einem Product Owner und einem Scrum Master für je circa 1-2 Umsetzungsteams. Außerdem arbeitet der PO dem übergeordneten Produktmanagement auf Programmebene zu. Die Teams arbeiten dabei funktionsübergreifend und weitestgehend selbstorganisiert.
- Programmebene: In SAFe arbeiten bis zu 10 Teams als sogenannte „Agile Release Trains“ für ein Programm zusammen. Produktmanager:innen sammeln und managen die Anforderungen, Product Owner brechen diese auf Teamebene umsetzungsnah herunter. So werden Programm- und Teamebene zusammengebracht. Eine Rolle „Release Train Engineer“ kümmert sich ab Ausbaustufe 2 um Abhängigkeiten und Integrationsaspekte.
- Portfolioebene: Auf dieser Ebene erfolgt die strategische Sicht auf Produktentwicklung, Budgetzuordnung und Abgleich mit Unternehmenszielen.
- Large-Solution-Ebene: Die allergrößten Projekte der Produktentwicklung erhalten mit dieser Ebene einen eigenen „Release Train“ zur Kontrolle des Wertstroms. So will SAFe den Anforderungen besonders großer und komplexer Programme gerechter werden.
Die SAFe-Rollen im Einzelnen
Die Rollen in SAFe sind auf Ebene 1 zunächst die normalen Scrum Teamrollen. Ab Ausbaustufe 2 gibt es zusätzlich folgende Rollen (ähnlich typischen Strukturen in klassischen Unternehmen):
- Ein Product Manager verantwortet das übergeordnete Product Backlog, das dann Program Backlog heißt
- Ein System Architect ist für die Systemgestaltung zuständig
- Ein Release Train Engineer kümmert sich als eine Art teamübergreifender Scrum Master für die Zusammenarbeit und Abhängigkeiten zwischen Teams
- Ein Business Owner behält den Blick auf ROI und Wertmaximierung sowie der Ausbalancierung von Kosten und Nutzen in der Produktentwicklung auf Systemebene; somit entlastet er den Product Manager etwas in dieser Hinsicht
- Natürlich darf auch der Kunde nicht zu kurz kommen – das ist der wichtigste Stakeholder.
Auf den Ebenen 3 und 4 kommen weitere Rollen hinzu, um der steigenden Komplexität gerecht zu werden.
Tipp: Die einzelnen Komponenten von SAFe sollten Sie vor Einführung auf ihre Sinnhaftigkeit in der gegebenen Umgebung prüfen. Genau dies ist die Motivation hinter Rahmenwerken, wie auch Scrum eines ist: einen Rahmen vorzugeben, innerhalb dessen sich Details situationsangepasst gestalten lassen.
Teil 3: Unterschied SAFe zu anderen Skalierungs-Rahmenwerken
Natürlich gibt es neben SAFe eine ganze Reihe Wettbewerber, die jeweils unterschiedliche Schwerpunkte haben. Der folgende Vergleich zeigt die wesentlichen Unterschiede:
Tipp: Die Frameworks in dieser Liste können zur Orientierung und Inspiration dienen; eine Umsetzung sollte aber immer mit Augenmaß dank entsprechender Erfahrung oder Beratung erfolgen. Auch unternehmensweite Ziele sollten Sie zunächst ausarbeiten und kommunizieren, damit sich keiner der Betroffenen überrumpelt fühlt.
Wie eingangs erwähnt nutzen die meisten Unternehmen das SAFe Framework als Inspirationsquelle für mehr Agilität in der Organisation. Warum ist das so?
Version One.
Die Vorteile von SAFe
SAFe trägt aktiv zu einem agileren Mindset bei. So wichtig eine agile Transformation ist – mit dem Ansatz „Holzhammer-Methode“ wird sie vermutlich scheitern. Dies gilt gerade in großen, gewachsenen Unternehmen, die nicht mit kleineren Start-ups zu vergleichen sind.
Deshalb versuchen sie sich lieber an hybriden Ansätzen, als große Veränderungen zu wagen und dabei an mangelnder Akzeptanz zu scheitern.
So weit, so gut.
Kritikpunkte an SAFe
Befürworter:innen klassischer agiler Methoden sehen SAFe nur als pseudoagiles Rahmenwerk. Zu den häufigen Kritikpunkten zählen:
- SAFe ist nicht agil genug
- Überholte Managementpraktiken bleiben bestehen
- Die Einführung zusätzlicher Ebenen widerspricht dem agilen Prinzip flacherer Hierarchien
- Andere Skalierungsansätze, wie etwa LeSS, sind schlanker gestaltet und näher an agilen Grundprinzipien.
Dennoch: Für viele Unternehmen ist es schwierig, einen Wandel ohne Übergänge zu gestalten. SAFe liefert hier den passenden Zwischenschritt:
- für das hybride Vakuum zwischen traditionellen und komplexen Organisationsstrukturen auf der einen, und
- möglichst agiler Selbstorganisation sowie leichtgewichtigen Prozesse auf der anderen Seite
Tipp: Es gibt kein klar definiertes Einsatzszenario, das für oder gegen eine Einführung von SAFe als agiles Rahmenwerk spricht. Hier wird kontrovers diskutiert. Da SAFe aber sehr detaillierte Vorgaben zur Strategie und Umsetzung liefert, gilt pinzipiell die Empfehlung: Je niedriger der agile Reifegrad der Organisation, desto geeigneter ist SAFe als Veränderungsansatz „Schritt für Schritt“.
Weitere Orientierungshilfe für die Methodenauswahl finden Sie hier: Die bekanntesten Skalierungsansätze im Überblick.
Könnte SAFe der richtige Ansatz für Ihr Unternehmen sein?
Wir empfehlen folgende erste Schritte zur Evaluierung bzw. Einführung nach dem SAFe Rahmenwerk:
- Sammeln Sie Argumente für eine Skalierung (z.B. unsere Projekte sind zu groß für kleine agile Einzelteams und wir wollen eine einheitliche Vorgehensweise)
- Holen Sie die relevanten Stakeholder an Bord, insbesondere auf den wichtigen Entscheidungsebenen
- Prüfen Sie das agile Mindset in der Firma und bei anderen Projektbeteiligten
- Finden Sie interne Experten / Expertinnen und / oder beauftragen Sie externe Berater:innen
- Stimmen Sie das weitere Vorgehen immer mit dem Management ab
Tipp: Ganz wesentliche Faktoren für eine erfolgreiche Einführung eines agilen Umfeldes: Sorgen Sie für die enge Kommunikation intern wie extern (mit Kunden- und Partnerfirmen) und richten Sie ein cleveres Change Management ein.
Zusammenfassung – SAFe Scalable Agile Framework
Sie haben in diesem Artikel gelernt, dass Sie mit dem Skalierungsmodell SAFe mehr Agilität in die Organisation und Prozesse Ihres Unternehmens bringen können.
Sie haben erfahren:
- Warum die Nachfrage nach Skalierungsansätzen wie SAFe so groß ist
- Wie sich SAFe von agilen Methoden unterscheidet
- Welche alternativen Ansätze existieren
- Was Sie beachten sollten, wenn Sie SAFe einführen möchten
- Wie SAFe aufgebaut ist und
- Welche Schritte Sie gehen können, um SAFe in Ihr Unternehmen zu bringen.
Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).
Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!
Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.
Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM
Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.
