Scaling Agile & Lean – Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe)

Das Scaled Agile Framework (Abkürzung: SAFe) ist ein umfangreiches, deskriptives Framework, um Agile/Lean auf der Team-, Programm- und Portfolio-Ebene zu ermöglichen und für große Organisationen handhabbar zu machen. Hierzu beschreibt es Strukturen, Rollen, Prozesse und Artefakte die relevant sind für ein agiles/lean Programm- und Portfoliomanagment. Eine komplette interaktive Beschreibung von SAFe befindet sich auf der Webseiten des Frameworks:  http://scaledagileframework.com/.

Adressierte Problemfelder

Mit SAFe werden vielfältige Herausforderungen adressiert, die für große Vorhaben und Organisationen nicht unüblich sind. Hierzu gehören:

  • Entropie / Varianz und lokaler Optimierung: Agilität auf der Team-Ebene mit sich selbst organisierenden Teams und nicht koordinierten Product Ownern führt zu einer hohen Entropie / Varianz. Kurz: Es kommt zu lokaler Optimierung die einer organisationsweiten Optimierung entgegenwirkt.
  • Intransparenz: Hohe Freiheitsgrade und mangelndes Alignment führt unternehmensweit gesehen zu einer geringen Transparenz. Die möglicherweise gesteigerte Produktivität einzelner agiler Einheiten kann nicht mehr übergreifend gebündelt werden und Steuerungsmechanismen versagen. Dies wiederum führt zu einer Gegenbewegung und Fehlentscheidungen.
  • Agilität bei Großkonzernen: Viele agilen Frameworks fokussieren in ihren Implementierungspraktiken auf die Team-Ebene als Kern des Wertschöpfungsprozesses. Vereinfachte Konzepte wie „PO definiert Business Value“ versagen jedoch in einem skalierten Umfeld, in dem der PO aufgerieben wird zwischen Anforderungen aus der Trägerorganisation, Kontakt zu Markt/Kunden und Verfügbarkeit für das Team.

Basierend auf Praxiserfahrungen wurden im SAFe Konzepte und Vorgehensweisen definiert, die auch in einem skalierten Umfeld tragfähig sind.

Ursprünge des Scaled Agile Frameworks

Die Grundlagen des Scaled Agile Frameworks wurden in einem viele Jahre dauernden Prozesses entworfen bzw. zusammengefügt. Historisch gesehen hat SAFe seine Wurzeln in iterative-inkrementellen Frameworks wie dem Rational Unified Process (RUP), so war der „Vater“ von SAFe, Dean Leffingwell zu Beginn auch an der Ausgestaltung und Verbreitung von RUP maßgeblich beteiligt. Leffingwell wurde wurde später zu einem Anhänger agiler Frameworks wie Scrum und (nach einer Phase der Skepsis) eXtreme Programming. Er kombinierte diese Ansätze mit Lean Thinking sowie den von Donald Reinertsen formulierten Prinzipien zum Lean Product Development (Buch „The Principles of Product Development Flow: Second Generation Lean Product Development„). Das so entstandene Framework wurde inkrementell entwickelt und in der Praxis verprobt. Frühe Elemente sind in den beiden Büchern „Scaling Software Agility: Best Practices for Large Enterprises (2007)“ und „Agile Software Requirements: Lean Requirements for Teams, Programs and the Enterprise (2011)“ sowie in dem Blog „Scaling Software Agility“ beschrieben. Die Arbeit an der publizierten Version von SAFe (damals noch „SAF“) begann Ende 2011 (Blog Post von Alex Yakyma) und Anfang 2012 wurde das Framework mittels der interaktiven Webseite und einem Trainings- und Zertifizierungsprogramm der Öffentlichkeit zugänglich gemacht.

Ursprünge des Scaled Agile Frameworks
Ursprünge des Scaled Agile Frameworks

Lean Management / Lean Thinking House

Die Grundsätze des Lean Managements werden in SAFe mittels eines „Lean Thinking House“ visualisiert, welches im Grundsatz dem Lean Thinking House von Larman/Vodde (vgl. das Buch „Scaling Lean And Agile – Thinking Organizantional Tools„) entspricht, mit dem Unterschied, dass Donald Reinertsen’s Prinzipien (s.o.) die dort definierten 14 Prinzipien ersetzen (Säule 2):

  • Zielsetzung / Dach: Wertschöpfung, Wertsteigerung als Ziel einer Organisation
    • Konkret umgesetzt als: Kurze Durchlaufzeiten, Kundenzufriedenheit, Fokussierung auf Wertschöpfung, hohe Qualität, Kostensenkung, Sicherheit
  • Säule 1: Respektiere und achte Deine Mitmenschen
  • Säule 2: Lean Product Development Flow (Wirtschaftschaftlichkeitsbetrachtung, Warteschlangentheorie, kleine Los-Größen, schnelles Feedback, dezentralisierte Kontrolle und andere)
  • Säule 3: Andauernde Verbesserung
  • Grundlage / Basis: Moderne Führung, Managementunterstützung
Das Lean Thinking House im SAFe
Das Lean Thinking House im SAFe

Werte im Scaled Agile Framework

Grundsätze und Werte spielen in agilen Methoden eine wichtige Rolle, auch das Scaled Agile Framework verweist auf vier wichtige Werte:

  • Alignment bzw. einer übergreifenden Ausrichtung
    • um Entropie und lokale Optimierung zu minimieren
    • Ausrichtung auf das gleiche Ziel bei Anwendung gleicher Regeln für alle
    • Nutzung von Rahmenwerken für Entscheidungen
  • Transparency / Transparenz
    • als Voraussetzung, um Entscheidungen treffen zu können
    • Informationen fließen zwischen allen Ebenen vor allem ist die Rückmeldung aus den umsetzenden Einheiten sehr wichtig
  • Code Quality / Code Qualität
    • um Rückläufer und Störungen zu minimieren
    • Schlechte Qualität skaliert nicht
    • Verweis auf XP Engineering Practices bzw. Agile Software Engineering
  • Program Execution bzw. die erfolgreiche Umsetzung in Programmen
    • Ohne Ausführung ist Strategie nichts wert, Ausführung = Strategie
    • Fokussierung auf Programme als organisatorischer Rahmen für Wertschöpfungsketten
    • SAFe als Framework, welches den Fokus auf die Programm-Ebene legt
Core Values von SAFe
Core Values von SAFe

Big Picture und die drei Organisationsebenen

Die Beschreibung des Frameworks ist frei im Internet verfügbar, als Einstieg und zentraler Orientierungspunkt dient das „Big Picture„, welches die drei Ebenen Portfolio, Programm und Team unterscheidet.

Im Web: Scaled Agile Framework Big Picture
Im Web: Scaled Agile Framework Big Picture

Team-Ebene

Auf der Team-Ebene finden sich die klassischen Scrum-Elemente, wobei die Rolle des Product Owners (PO) etwas anders ausgelegt wird als im Scrum Guide: Der PO verantwortet die Realisierung von Software mit 1-2 Teams und wird auf der Programm-Ebene ersetzt durch einen Produktmanager (PM). Anforderungen in Form von Features (Programm-Ebene, verantwortet durch PM) werden für die Team-Ebene auf Stories heruntergebrochen (Aufgabe des POs). Für den aktuellen Release werden die Sprints im Rahmen einer Release-Planung vorgeplant, die Teams committen sich auf 4-6 Sprints, wobei der Fokus auf Einhaltung der formulierten Sprint-Ziele und Erreichung der Release Objectives liegt (ab Version 2.5 im Big Picture entsprechend visualisiert).

Sowohl die Aufgabentrennung PO/PM als auch diese Vorausplanung sind typische Kritikpunkte (Verringerung der Agilität), die jedoch gerade bei großen Unternehmen mit heterogenen Prozesslandschaften (nicht alles agil/lean) entsprechend Anklang finden.

Programm-Ebene

SAFe Programme werden um Wertschöpfungsketten herum aufgesetzt. Die Planung und Steuerung der Umsetzung findet aus Sicht der Auftraggeber auf der Programm-Ebene statt. Auf Ebene des Programms werden die (Zwischen-) Releases / Potential Shipable Increments (PSI) geplant und die Umsetzung in sogenannten „Agile Release Trains (ART)“ organisiert.

Zur Umsetzung werden die Geschäftsziele und größen Anforderungsblöcke (Epics) in Features heruntergebrochen und auf einen Zeitstrahl verortet.

Die Programm-Ebene dient zur Integration und dem Alignment der sich im Tagesgeschäft weitgehend selbst organisierenden agilen Teams. Die Informationen aus den beteiligten Teams werden über die Programm-Ebene aggregiert und transparent gemacht, damit ein Soll-/Ist-Abgleich für das gesamte Vorhaben durchgeführt werden kann.

Auf der Programm-Ebene werden hierzu einige neue Rollen eingeführt, u.a. ein Produktmanagement (PM), welches für das Programm die Aufgaben des Product Owners übernimmt (s.o.). Andere wichtige Rollen sind die des Releasemanagements, des Systemarchitekten und des Systemteams.

Portfolio-Ebene

Auf der Portfolio-Ebene werden die Programme anhand ihrer Bedeutung für die Unternehmensstrategie mit Mitteln versorgt (“Investment Themes”) und es werden geschäftliche Zielvorgaben formuliert (“Epics”). Diese Epics sind häufig strategischer Natur („Wir wollen Marktführer beim Videostreaming werden…“). Im Gegensatz zu vielen anderen agilen Methoden werden größere technische Maßnahmen bzw. Entscheidungen hinsichtlich technologischer Ausrichtung und grundlegender Architekturentwürfen explizit aufgeführt (transparent gemacht) und unterliegen den gleichen Mittelzuweisungsprozessen (und damit auch einer Wirtschaftlichkeitbetrachtung und Priorisierung) wie die inhaltlichen / geschäftlichen Zielstellungen.

Auf der Portfolio-Eben findet eine Überwachung und über die Mittelzuteilung auch eine Steuerung der Programme statt.

 

Rollen im Scaled Agile Framework

Im Vergleich zu Frameworks wie Scrum gibt SAFe auf den unterschiedlichen Ebenen relativ viele Rollen vor.

SAFe - mehr Rollen als andere agile Frameworks
SAFe – mehr Rollen als andere agile Frameworks

Die Rollen im Scaled Agile Framework werden in einem Folgeartikel genauer betrachtet.

Artefakte im Scaled Agile Framework

Im SAFe werden mehr Artefakte im Big Picture aufgeführt als in den meisten anderen agilen Framework.

Wichtige Artefakte im Scaled Agile Framework
Wichtige Artefakte im Scaled Agile Framework

Die Artefakte im Scaled Agile Framework werden in einem Folgeartikel genauer betrachtet.

Architektur und technische Investitionen

In Abgrenzung zu einigen anderen agilen Vorgehensweisen werden Fragestellungen, die sich aus der Technik und Architektur ergeben, auf allen Ebenen explizit gemacht und transparent behandelt. Es gibt Rollen wie Enterprise Architect (Portfolio-Ebene) und System Architect (Programm-Ebene) sowie ausgewiesene „Arbeitspakete“ (Architectural Epics, Architectural Feature, Spikes/Refactors) die bewusst budgetiert werden und nicht hinter geschäftlichen Anforderungen „versteckt“ werden. Damit wird die Transparenz verbessert und Entscheidungen vereinfacht.

Wie bereits erwähnt, unterliegen technische Fragestellungen ebenfalls Prozessen in denen Mittelzuweisungen (Portfolio-Ebene) und Prioritäten geklärt werden.

SAFe & Architektur
SAFe & Architektur

Im Scaled Agile Framework wird unter dem Stichwort „Architectural Runway“ das Investment in technische Themen verstanden, um später verlässlich geschäftliche Initiativen zu realisieren oder Erfordernisse der umgebenden Organisation zu erfüllen.

Trainings, Zertifizierungen und Community

Zum Scaled Agile Framework gibt es mit der ScaledAcademy eine Organisation, die Trainings und Zertifizierungen anbietet. Aktuell werden drei verschiedene Zertifizierungen angeboten, die die Teilnahme an bestimmten Trainings voraussetzen:

Leading SAFe (SAFe Agilist)

In dem zweitägiger Kurs „Leading SAFe“ wird den Teilnehmen das notwendige Wissen vermittelt, um mit Hilfe des Scaled Agile Frameworks und den zugrundeliegenden Prinzipien (Lean Thinking, Product Development Flow) eine unternehmensweite Einführung von Agilität zu leiten. Die Teilnehmer dieses Kurses sind nach erfolgreicher Teilnahme und bei Erfüllung der Voraussetzungen dazu berechtigt den Online-Test zum Scaled Agile Framework Agilist (SAFe Agilist) abzulegen.

SAFe ScrumXP (SAFe Practitioner)

Der zweitägige Kurs SAFe ScrumXP für Teams geht über Scrum hinaus. Er vermittelt Grundlagen zu Lean Thinking Tools, Rollen, Prozesse und benötigte Software- Entwicklungspraktiken, um Scrum in einem Unternehmenskontext zu skalieren.

Die Teilnehmer dieses Kurses sind nach erfolgreicher Teilnahme und bei Erfüllung der Voraussetzungen dazu berechtigt den Online-Test zum Scaled Agile Framework Practitioner (SAFe Practitioner) abzulegen.

SAFe Program Consultant (SPC)

Durch ein erweitertes Leading SAFe Training (nur angeboten durch Dean Leffingwell und 1-2 anderen Trainer) sowie eine Prüfungsvorbereitung, können Teilnehmer zu SAFe Program Consultants (SPC) ausgebildet werden, vorausgesetzt sie bestehen einen umfangreichen Test. Diese SPCs sind wiederum berechtigt die beiden Einstiegstrainigs LeadingSAFe und SAFe ScrumXP zu lehren.

Community

Neben geschlossenen Gruppen, die beispielsweise den zertifizierten Teilnehmern der offiziellen Kurse zugänglich sind gibt es immer mehr öffentliche Communities zum Thema Scaled Agile Framework. Für den deutschsprachigen Raum gibt es beispielsweise die Community SAFeDACH, die sich momentan hauptsächlich via Google+ und Xing organisiert.

Kritik an SAFe

Während SAFe von vielen Praktikern aus großen Unternehmen grundsätzlich positiv bewertet wird, gibt es auch viele Agile Coaches, die dem Framework sehr ablehnend gegenüberstehen. Ein gutes Beispiel für die ablehnende Haltung finde sich im dem Artikel „The horror of the Scaled Agile Framework„:

Scrum scales perfectly well without this framework, thank you very much! […] Why synchronise the whole frigging organisation’s product development?! Yeah like that will work. Means any one team can’t adapt their process because it’s locked in to the organisation’s “Agile” framework.

Typische Kritikpunkte

SAFe ist zu schwergewichtig

SAFe erscheint vielen Verfechtern agiler Methoden im Vergleich zu Scrum und Kanban als schwergewichtiges Framework. Es gibt deutlich mehr Rollen, mehr Artefakte und mehr Vorgaben.

Die Frage ist jedoch, welche alternativen Frameworks existieren. Ein genauer Blick in verschiedene Enterprise Scrum Implementierungen bringt ebenfalls neue Rollen und Abstimmungsprozess zu Tage.

SAFe vernachlässigt kulturelle Aspekte

Ein Kritikpunkt aus der agilen Community ist, dass SAFe sich zum großen Teil auf Strukturen und Prozesse konzentriert und kulturelle Aspekte vernachlässigt. SAFe würde Unternehmen dazu bringen “Agile zu machen” aber nicht “Agile zu sein”. Schnell wird deshalb ein Widerspruch mit dem agilen Manifest vermutet (People & Interaction vs Processes & Tools).

An diese Stelle ist wahrscheinlich die Umsetzung entscheidend. Im SAFe Lean Thinking House sind explizit kulturelle Werte verankert, diese gilt es jedoch auch bewusst aufzugreifen und im Unternehmensalltag zu verankern.

Hierarchie & Alignment vs Netzwerkstruktur & Selbstorganisation

Viele Vertreter agiler Prozesse die sich auf die Team-Ebene konzentrieren stehen der hierarchischen Struktur (Portfolio > Programm > Team) kritisch gegenüber und bevorzugen sich selbst organisierende Systeme / Strukturen.

Diese Organisationsvarianten setzen jedoch eine ausreichend reife Organisation und Teams voraus, die in vielen Fällen (noch) nicht existieren sondern durch jahrelange Investitionen erst aufgebaut werden müssen. Die Kritiker stellen den Mehrwert von Standards und angeglichenem Vorgehen in Frage und ziehen die Erzeugung lokaler Optima vor. Dahinter steckt wohl auch, dass zu häufig die Ziele von Standardisierungsvorhaben nicht erreicht wurden.

Ein kleines Fazit

Das Scaled Agile Framework (SAFe) ist das aktuell am detailliertesten beschriebene Rahmenwerk für Agilität im Großen. Dies ist ein Vorteil (Guidance, Governance) und gleichzeitig auch in gewisser Weise eine Limitation, wenn es nicht gelingt via Inspect & Adapt die Vorgaben aus dem Standard an die eigenen Gegebenheiten anzupassen, Regeln zu verändern und ein agiles Mindset zu etablieren.

Das Scaled Agile Framework bietet ein sehr hilfreiches Rahmenwerk für große Unternehmen, die agiler arbeiten möchten. Selbst wenn man es bewusst nicht ein-/umsetzt, sollte man sich damit beschäftigten. Es enthält Antworten auf viele Fragestellungen, die in großen Unternehmen relevant sind. Auch wenn man diese Antworten nicht für richtig hält, so helfen sie doch dabei, die eigenen Ansätze dahingehend zu verifizieren, ob diese ebenfalls ausreichend Antwort auf die Fragestellungen geben. Kurz: SAFe gibt zu Fragestellungen großer Unternehmen eine passende Antwort – in der Praxis sind jedoch häufig noch viele andere Ansätze valide.

Quellen

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen in irgendeiner Form agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Über Felix Rüssel

Felix Rüssel is exploring Lean-Agile concepts since 2002 with a special focus on how to connect and align Business and Development on all levels of an organization. He likes to challenge established thinking patterns and structures to enable innovative approaches which help to deal with current and future challenges. Felix Rüssel is a Certified Scrum Professional (CSP-PO), a Certified LeSS Practitioner (CLP) and a SAFe Program Consultant Trainer (SPCT5).

6 Gedanken zu „Scaling Agile & Lean – Scaled Agile Framework (SAFe)

  1. Ich habe den Artikel gerade offen gesagt nur überflogen, aber aus meiner Sicht erwähntest du einen der größten Kritikpunkte nicht, der unter anderem im oben verlinkten „Horror“-Artikel erwähnt wurde:

    Unternehmen die SAF einsetzen, werden scheinbar agil, praktisch bleibt jedoch zu viel beim Alten um die wirklichen Vorteile der Agilität zu erhalten. Statt also einen agilen Wandel anzustreben und durchzuführen, kann SAF eben genau den gegenteiligen Effekt bewirken.

    Das ist nicht mein Standpunkt, sondern nur eine Zusammenfassung häufigerer Standpunkte zum Thema. Ich selbst habe mit SAF noch keine Erfahrungen gesammelt.

    Ansonsten scheint es sich bei dem Artikel um einen der besten Überblicke zum Thema zu handeln, die ich bis jetzt gesehen habe. Interessanterweise habe ich mich gestern Abend ein wenig ins Thema eingelesen, bin dabei auch über den „Horror“-Artikel gestolpert und heute finde ich das Thema bei dir im Blog. Zufälle gibt es :)

  2. Sehr schöne Darstellung und Zusammenfassung — mir gefällt auch, dass Du einige Kritikpunkte mit aufführst. Ohne SAFe schon live im Einsatz gesehen zu haben, erscheinen mir diese durchaus gerechtfertigt. Ich habe zudem den Eindruck, dass manche Konstrukte im SAFe einfach an vielfach vorgegeben Strukturen orientiert sind, wie bspw. die Existenz von dedizierten Release Management Teams oder den Enterprise Architekten. Das ist auf der einen Seite gut, weil es oft den Gegebenheiten entspricht und dennoch eine Einordnung im Rahmen eines insgesamt agilen Verfahren erlaubt, andererseits aber sehe ich da etwas wenig intrinsische Motivation für den Bedarf an diesen Rollen. Das führt auch bei mir zum Bild, dass das alles etwas schwergewichtig ist.

    Wenn ich aber höre, dass der kleinste SAFe-Kunde von Dean ca. 450 Entwickler hat, ergibt sich die Motivation dafür fast von alleine. An der Stelle kommen die Fragen nach den kulturellen Aspekten und dem Grad der Selbstorganisation dann fast von alleine. Wenn ich höre (Vortrag von Dominik Maximi auf der Goto Zürich), dass Kulturwechsel zwischen 7 und 10 Jahren dauern, dann frage ich mich genau bei diesen Kritikpunkten, was eine Einführung von SAFe eigentlich für eine Organisation zum Ziel hat. Es wäre sicher interessant zu sehen, wie SAFe „in echt“ gelebt wird und wie die Auswirkungen in der täglichen Arbeit sind. Da kann ich mir zwischen „oh, alles wird komplizierter“ und „oh, endlich gibt es mal genügend Klarheit“ alles vorstellen.

  3. Hallo Jan,
    Du hast Recht, dies erwähne ich ggf. nicht deutlich genug sondern umschreibe es mit „kulturelle Aspekte“ und den hierarchischen Strukturen.
    Aber bei einer Sache kannst Du Dir sicher sein: Es gibt jede Menge nicht agiler „Scrum“ Implementierungen da draussen! Ist somit kein Problem von SAFe, wobei SAFe durch die vielen Rollen und Artefakte sowie der hierarchischen Grundstruktur natürlich anfälliger dafür ist.
    Umso wichtiger ist deshalb eine Einführung in SAFe durch Personen, die einen richtigen Agile/Lean Mindset haben und alles und jedes in Frage stellen.

    Kurz: Du kannst mit SAFe agile unterwegs sein, kannst es aber auch als RUP mit agilem Anstrich implementieren. Muss nicht schlecht sein – nur eben nicht wirklich agile. Letztendlich zählt doch das Ergebnis (Werterzeugung, zufriedene Kunden & MItarbeiter) und nicht, ob wir Agile oder Lean oder RUP oder Wasserfall erfolgreich implementiert haben ;-)

  4. Pingback: SAFe Mind Map 0.5
  5. > Die Frage ist jedoch, welche alternativen Frameworks existieren.
    > (English) The question is , what alternative frameworks exist?

    Large Scale Scrum has been in existence since about 2008, and is a far superior framework to scaling Scrum and Agile than SAFe, IMO.

    http://agileatlas.org/articles/item/large-scale-scrum-less-is-more

    In short, IMO, SAFe is way too prescriptive and relies on the user to tailor the framework, just like RUP did — and RUP has not exactly had widespread adoption, success, or sustainable success. It also encourages top down command and control architecture by having ivory tower architecture commanders.

  6. Hi Charles,

    thanks for your feedback. I know and really like the scaling approach of Larman. The two books with the principles around this scaling model are a great source of inspiration and insights.

    However I saw several implementation of this model fail – even at a quite small scale. Reasons were mainly that some parts of the organization were not able to work in the expected way (as defined by the scaling model).

    The visuals / flow charts used in this model also tend to imply that a PO can handle several team. That is fine for some combination of tech/business domains but wont work in other domain.

    Additionally the visuals dont tell the whole story. Without the principles and tools described in their books it wont work.

    So knowing this model and understanding the principles allows you to see the chances and risks of this approach.
    For me the scaling model suggested by Larman is a valuable contribution to the topic of how to scale agility. It is not a silver bullet and it will work in some domains while it will fail in others.

Kommentare sind geschlossen.