Sie möchten mehr Agilität im Unternehmen, wissen aber nicht, wie Sie den Schritt von klassischen zu agilen Arbeitsweisen schaffen sollen? Fakt ist: Viele agile Regelwerke bieten einen Prozessrahmen für Einzelteams, die hochgradig agil arbeiten möchten. Sie bieten aber keine Hinweise darauf, wie ganze Unternehmen agiler werden oder Projekte mit großen oder mehreren Teams abwickeln können.
Hier kommen Skalierungsansätze wie SAFe (Scaled Agile Framework) ins Spiel. Sie sollen die Lücke schließen und Unternehmen auf dem Weg in agile Arbeitsweisen unterstützen. Wie das gelingen soll, lesen Sie in diesem Artikel. Sie erfahren:
Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?
Teil 2: SAFe – Voraussetzungen, Aufbau, erste Schritte
Teil 3: Wie unterscheidet sich SAFe von anderen Skalierungs-Rahmenwerken?
Zudem erhalten Sie Tipps zur konkreten Umsetzung und Links zu weiterführenden Informationen. Viel Spaß beim Lesen!
Begriffsdefinition: Was ist SAFe? Die Abkürzung SAFe steht für „Scaled Agile Framework“. Im Gegensatz zu Ansätzen, die Einzelteams in den Vordergrund rücken, bietet SAFe 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 hybride Ansätze.
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, sondern immer mehr auch für andere Bereiche.
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, die diese Ideen umsetzen – oft sogar im selben Unternehmen. Das macht es ihnen 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.
Mit agilen Methoden arbeiten immer mehr Teams (hier ein Kanban-Board)
Zusätzlich geben Leitfäden wie der Scrum Guide keine Angaben dazu, wie man Projekte angehen kann, die mehr als ein Umsetzerteam von drei bis neun Leuten benötigen. 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, nämlich: 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.
Bild: Das Vorhaben bestimmt die Wahl der Methode
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
Es klingt sinnvoll: In einzelnen Teams agile Arbeitsweisen einzuführen, kann bereits ein Umdenken bewirken. So können Sie vor allem auf Einzelteam- bzw. Einzelprojektebene Erfolge erzielen und Prozesse, Innovationen oder Beteiligung von Teams und Stakeholdern bereits deutlich beweglicher gestalten – sofern es Ihr Umfeld erlaubt.
Denn die große Herausforderung dabei ist: Solche Pionierteams stoßen intern, wie in der Zusammenarbeit mit anderen Firmen, häufig schnell auf Hindernisse. Diese Hindernisse liegen oft an unterschiedlichen Auffassungen – also am vielzitierten „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, aber auch Kunden oder Nutzern des entwickelten Produkts ist 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, 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, um Kostenrisiken fairer aufzuteilen und für ein konstruktives Streben nach gemeinsamen Zielen zu sorgen. Budgetplanungs-Prozesse in vielen großen Unternehmen geben eine solche Freiheit allerdings gar nicht her, sodass solche Vertragsklauseln nicht umsetzbar sind.
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. Kollegen 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 höchst irritiert und ist sehr zögerlich in der Bereitschaft, an einem solchen Workshop überhaupt teilzunehmen, und zieht es vor, schwer verständliche Use Cases per E-Mail zu schicken.
Projekt- statt Produktorientiertung
Die Produktorientierung, die agile Teams brauchen, um motiviert und vor allem zielgerichtet arbeiten zu können, ist vielen Firmen noch völlig fremd.
Beispiel: Ein Scrum Team plant seine Sprints so, dass jeder im Team weiß, was die vom Team gesetzten Ziele im Sprint sind. Vorgesetzte des Product Owners haben jedoch andere Vorstellungen davon, woran die Leute im Team genau jetzt arbeiten sollten, und „funken“ mit abweichenden Anforderungen dazwischen. Da der Product Owner um seinen Job fürchten muss, wenn er sich nicht an die Anweisungen hält, gibt er diese ungefiltert weiter. In der Folge sinkt die Motivation des Teams, überhaupt noch etwas zu planen, von Sprint zu Sprint – da dies vermutlich 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.
Alle 14 Tage – der TPG Projektmanagement Podcast für Unternehmen. Schicken Sie uns doch gerne Ihre Themenwünsche und Feedbacks an podcast@theprojectgroup.com.
Wie können Skalierungsframeworks 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 einzelne Teams und am Ende die ganze Organisation erfolgreicher sein können
- ALLE Projektbeteiligten und Stakeholder leben diese Einstellung (das gilt auch für Kundenfirmen und Dienstleister)
- Teams innerhalb einer Firma, die zusammenarbeiten, ziehen alle am gleichen Strang – anstatt in Konkurrenz zu treten
- Bei weltweit verteilten Standorten gibt es eine gemeinsame, durchdachte Strategie
SAFe bietet viele Ansätze, wie so ein so wichtiges wie großes Vorhaben gelingen kann. Es ist damit aber – wie andere Skalierungsframeworks auch – nicht als Blaupause zu verstehen.
Teil 2: SAFe – Voraussetzungen, Aufbau, erste Schritte
Was ist SAFe?
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.
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. Greifen Sie in jedem Fall auf Menschen mit Erfahrung und Kenntnissen in Scrum und skalierenden Ansätzen zurück.
Ansonsten lohnt es sich, solches Wissen einzukaufen. Der „State of Agile“-Bericht nennt unter den Erfolgsfaktoren bei der Einführung von Skalierungs-Frameworks die folgenden Top Fünf:
Beratung, Konsistenz und Unterstützung durchs Management sind laut „State of Agile“ die wichtigsten Faktoren für eine erfolgreiche Skalierung agiler Prozesse und Denkweisen
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öchte man SAFe als Rahmenwerk einführen, sollte man 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 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. 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. Um es besser verstehen zu können, gehen wir im Folgenden auf die Ausbaustufen, einbezogenen Ebenen und Rollen in SAFe näher ein.
Die Stufen im Einzelnen
Die Ebenen im Einzelnen
Je umfangreicher die Skalierung und je komplexer die Anforderungen, desto mehr Ebenen sollten zur Erledigung der Aufgaben pro Stufe einbezogen werden:
- 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) Entwickler um die Umsetzung, begleitet durch einen Product Owner und einen Scrum Master für je circa 1-2 Umsetzerteams. 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 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 Produktentwicklungsunterfangen erhalten mit dieser Ebene einen eigenen „Release Train“ für die Kontrolle des Wertstroms. So soll SAFe den Anforderungen besonders großer und komplexer Programme gerechter werden.
Gesamtüberblick über das SAFe Modell (Quelle: https://www.scaledagileframework.com/)
Die Rollen im Einzelnen
Die Rollen in SAFe sind auf Ebene 1 zunächst die normalen Scrum Teamrollen. Ab Ausbaustufe 2 gibt es zusätzlich (ähnlich typischen Strukturen in klassischen Unternehmen) folgende Rollen:
- 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. Mehr dazu finden Sie hier!
Unser 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: Wie unterscheidet sich SAFe von 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:
Unser 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 zunächst ausgearbeitet und kommuniziert werden, sodass sich keiner der Betroffenen überrumpelt fühlt.
Laut dem 12. jährlichen „State of Agile“-Bericht ist SAFe am bekanntesten:
SAFe ist auf Platz 1 im 12. Bericht zur offenen Umfrage „State of Agile“ der Firma
Version One.
Wie eingangs erwähnt nutzen also die meisten Unternehmen SAFe als Inspirationsquelle für mehr Organisationsagilität. Warum ist das so?
Die Vorteile von SAFe
SAFe trägt aktiv zu einem agileren Mindset bei. So wichtig eine agile Transformation ist, so wenig erfolgreich ist sie manchmal, wenn sie mit der Holzhammer-Methode umgesetzt wird. 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 klassischer agiler Methoden hingegen 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
- Tatsächlich sind andere Skalierungsansätze wie etwa LeSS 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
Unser 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 finden Sie hier: Die bekanntesten Skalierungsansätze im Überblick.
SAFe könnte der richtige Ansatz für Ihr Unternehmen sein?
Dann empfehlen wir folgende erste Schritte zur Evaluierung bzw. Einführung:
- 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 und / oder beauftragen Sie externe Berater
- Stimmen Sie das weitere Vorgehen immer mit dem Management ab
Ganz wichtig dabei: Eine enge Kommunikation intern wie extern (Kunden- und Partnerfirmen ) und cleveres Changemanagement sind wesentliche Faktoren für eine erfolgreiche Einführung.
Fazit
Wie Sie in dem Artikel gesehen haben, können Sie mit dem Skalierungsmodell SAFe mehr Organisationsagilität in Ihr Unternehmen bringen.
Sie haben in diesem Artikel 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, sowie
- Wie SAFe aufgebaut ist und
- Welche Schritte Sie gehen können, um SAFe in Ihr Unternehmen zu bringen.
Wenn Sie es ausprobieren – lassen Sie uns gerne an Ihren Erfahrungen teilhaben! Wir freuen uns über Ihre Kommentare und Ihr Feedback.
Von Antje Lehmann-Benz
