On Lean and Agility

Bild: Wikimedia Commons / JCS - CC BY 3.0

Sobald agiles Arbeiten über die Teamebene hinaus in einem Unternehmen etabliert werden soll, stossen praktisch alle agilen Frameworks auf das immer gleiche Problem: oberhalb der Teams und um die Teams herum gibt es vor allem in grösseren Firmen eine unberschaubare Zahl von Management-Rollen. Teilprojekt-, Projekt- und Programmleiter, Test-, Release- und Security Manager, Heads of Legal, Product und Sales, Team- Abteilungs- und Bereichsleiter und viele, viele mehr. Was macht man jetzt mit denen?

In den meisten Fällen gibt es darauf keine klaren Antworten; Scrum, Kanban, DevOps und fast alle weiteren agilen Vorgehensmodelle befassen sich einfach nicht mit diesem Thema, was Unklarheit und Unsicherheit zur Folge hat. Schlimmstenfalls erwächst aus dieser Unklarheit sogar ein Konflikt - wenn den verschiedenen Managern gesagt wird, dass sie im Umfeld selbstorganisierter Teams bald nicht mehr benötigt werden, werden die meisten von ihnen natürlich um ihren Status und ihre Karriere kämpfen.

Und auch das gehört dazu: viele der bisherigen Management-Aufgaben können nicht so einfach dezentral in alle Teams delegiert werden. Irgendjemand muss die grossen strategischen Entscheidungen treffen, irgendjemand muss Ansprechpartner für Gehaltsverhandlungen, Beförderungen, Versetzungen und Eskalationen sein, und irgendjemand muss letzten Endes die Verantwortung tragen, wenn es um zivilrechtliche Haftungsfragen geht, etwa wegen Verstössen gegen Arbeitsschutz oder Compliance.

Das meines Wissens nach einzige agile Framework, dass diese Umstände in seinem Regelwerk berücksichtigt (wenn man von einigen offensichtlich nur halb-ernst gemeinten Management-Rollen in Extreme Programming absieht) ist das Scaled Agile Framework/SAFe, in dem eine Rolle enthalten ist, die einen Grossteil der oben genannten Verantwortungen enthalten kann - wenn auch nicht in jedem Fall enthalten muss. Die Rede ist von dem Business Owner (BO).

Auf der entsprechenden Website beschreibt SAFe fünf Aufgabenbereiche, die ein BO haben kann: Leading by Example, Engaging in Lean Portfolio Management, Aligning Priorities & PI Planning, Realizing Business Outcomes und Sponsoring Relentless Improvement. Wie vieles andere in diesem Framework ist das im Folgenden gleichzeitig hinreichend unkonkret um individuell ausgestaltet zu werden und spezifisch genug um "agile Puristen" zu provozieren.

Zu den hinreichend unkonkreten Formulierungen, mit denen die fünf Aufgabenbereiche beschrieben werden, gehören beispielsweise mehrere, in denen davon die Rede ist, durch eigenes Verhalten ein Vorbild zu sein, Visionen zu kommunizieren, anderen Führungsrollen zu helfen, den Geschäftskontext zu vermitteln, den Teams Feedback zu geben und andere zu motivieren. Dahinter kann sich alles Mögliche verbergen, von der Sonntagsrede bis zur Hands On-Unterstützung.

Provozierend für agile Puristen sind weitere Formulierungen, die implizieren, dass die Business Owner Aufgaben übernehmen können, die auch von selbstorganisierten Teams direkt übernommen werden könnten. Das Vermitteln bei internen Konflikten und Widerständen gehört dazu, das Organisieren teamübergreifender Communities of Practice, Stakeholdermanagement, Abhängigkeitsmanagement, die Beseitigung von Impediments, die Definition von KPIs und die Optimierung von Arbeitsflüssen.

Während diese beiden Aufgabenbereiche diskutierbar und ggf. verzichtbar sind, gibt es aber einen dritten, der unverzichtbar und entscheidend ist - das Schaffen optimaler Rahmenbedingungen: Business Owner sind zuständig für die Bereitstellung von ausreichend Budget, Personal und Ressourcen, für das Setzen und Anpassen strategischer Ziele sowie für das Beseitigen demotivierender Vorschriften und Prozesse. Das sind Schlüsseltätigkeiten, auf deren Basis Selbstorganisation überhaupt erst möglich ist.

Insgesamt ergibt sich so ein für SAFe typisches Bild: mit der BO-Rolle werden Dinge thematisiert und formalisiert die wichtig sind, in anderen agilen Frameworks aber nicht erwähnt werden. Gleichzeitig sind sie aber eingebettet in eine Menge weiterer derartig unscharf formulierter Vorgaben, dass auf deren Basis praktisch alles möglich ist, unterstützender von Hilfe zur Selbstorganisation bis hin zu übergriffigem Hineinregieren in die Teams.

Um das Positive darin zu sehen - wenn man im Unternehmen ein Management mit einer (aus einer "agilen Perspektive") "richtigen" Einstellung hat, kann man seine Mitglieder als Business Owner auf passende, hilfreiche und sinnstiftende Weise einbinden. Wenn auf der anderen Seite eine eher "falsche" Einstellung vorherrscht, würde auch ein methodischer Rahmen ohne diese Rolle nur in begrenztem Ausmass für Verbesserung sogen. In diesem Sinn: gebt den BOs eine Chance.

Dass es von jedem agilen Framework in der Realität sehr unterschiedliche Ausprägungen gibt, dürfte jeder wissen, der verschiedene agil arbeitende Unternehmen gesehen hat. Zu den Gründen dafür gehört zum einen ein bewusst offen gelassener Gestaltungsspielraum, zum anderen aber auch versehentliche oder absichtliche Verfremdungen der ursprünglichen Idee. Das trifft auf Scrum zu, auf Kanban, auf OKRs, aber auch auf das Scaled Agile Framework (SAFe).

SAFe ist dabei aber in einem Aspekt deutlich anders als die anderen Frameworks: während sich deren Variantenvielfalt u.a. daraus ergibt, dass sie sich in einem Spannungsfeld zwischen einem praxisnahen Graswurzel-Ursprung und einer später entstandenen starken Kommerzielisierung bewegen, ist SAFe bereits in seinen Ursprüngen kommerziell angelegt. Sämtliche seiner Varianten sind dadurch Teil des Beratungs- und Zertifizierungs-getriebenen agil-industriellen Komplexes.¹ Hier sind sie:

The Little Agile Release Train

Die vielleicht häufigste Variante, wenn auch oft mit anders benannten Namen und Rollen.² Drei bis zehn Teams arbeiten in synchronisierten Sprint-Rhythmen, es gibt eine übergreifende Quartalsplanung und oberhalb der Product Owner und Scrum Master einen Produktmanager / Chief Product Owner und Release Train Engineer / Chief Scrum Master, der ihnen jeweils übergeordnet ist. Für sich genommen eine noch relativ schlanke, agile und halbwegs unbürokratische SAFe-Umsetzung.

The Feature Factory

Die Grössenordnung, die die Aussenwahrnehmung von SAFe am stärksten prägt. Ab einer Größe von mehr als zehn Teams ist ein Release Train nicht mehr ausreichend, es werden mehrere parallel zueinander eingerichtet, über denen dann eine zusätzliche Hierarchieebene mit einem Solution Manager und einem Solution Train Engineer entsteht. Feedback-Schleifen und Nähe zwischen Entwicklern und Anwendern sind nur noch schwer möglich, es werden vor allem Feature Requests abgearbeitet.

Disruptive SAFe

Während der einzelne Release Train und die Feature Factory die alten Strukturen einer Firma noch weitgehend unangetastet lassen, hat SAFe einige optionale Elemente, deren Anwendung einiges durcheinanderwerfen würde, z.B. die Koppelung der Budgetierung an Teams statt an Features oder die Ausrichtung der Planungen an Value Streams statt an Roadmaps. Aus einer "agilen Perspektive" sehr wünschenswert, kommt aber in der Realität nur sehr selten vor.

Absorbed SAFe

Dort, wo (warum auch immer) alles in einem einzigen, grossen agilen Framework organisiert werden soll, die Auswirkungen von disruptivem Safe den Verantwortlichen aber zu weit gehen, ist es eine häufige Reaktion, so lange Anpassungen vorzunehmen, bis zentrale Elemente des bisherigen Vorgehens nicht mehr angetastet werden. Das Ergebnis können Hybrid-Frameworks wie SpotiSAFe sein, ggf. aber auch einfach eine Erweiterung oder Beschneidung des SAFe-Umfangs an entscheidenden Stellen.

Post-SAFe

Mittlerweile erstaunlich häufig anzutreffen sind Unternehmen, die sich irgendwann entschlossen haben, nicht mehr nach SAFe zu arbeiten, da die damit verbundenen Erwartungen nicht erfüllt werden konnten. Mitunter werden aber einzelne funktionierende Elemente beibehalten, z.B. das PI Planning oder die Rolle des Release Train Engineers. Man erkennt durch sie noch, dass SAFe hier einmal im Einsatz gewesen ist, der aktuelle Zustand hat aber nur noch eingeschränkt damit zu tun.

Und viele mehr ...

Wie immer bei solchen Aufzählungen ist auch diese hier nicht vollständig, in den Unternehmen dieser Welt kann man mit Sicherheit noch weitere SAFe-Varianten finden. Wichtig ist an dieser Stelle vor allem die zentrale Botschaft: es gibt verschiedene Ausprägungen dieses Frameworks, die sich z.T. sehr deutlich voneinander unterscheiden, wodurch es viel weniger eindeutig und einheitlich ist, als es auf den ersten Blick erscheinen mag.

Irgendwann zwischen 2015 und 2020 hat ein zunächst merkwürdig anmutender Trend begonnen. Waren die Berichte aus den agilen Methoden-Implementierungen grosser Konzerne bis dahin entweder von den Buzzwords aus SAFe oder denen aus dem Spotify Model durchsetzt, gab es ab diesem Zeitraum plötzlich viele, in denen beides vermischt wurde. Tatsächlich taucht seitdem in immer mehr Unternehmen ein Hybrid aus beiden Ansätzen auf, häufig als "SpotiSAFe" bezeichnet.¹

Um zu verstehen wie es dazu gekommen ist, muss man sich eine Besonderheit von SAFe vor Augen halten: als einziges agiles Framework gestaltet es auch die Budgetierung um. Während klassische projektorientierte Organisationen Pools gleichartiger Spezialisten finanzieren (Entwickler, UX-Designer, etc.), von denen die Projekte ihre Teammitglieder "mieten" müssen,² geht das SAFe Lean Portfolio Management einen anderen Weg und budgetiert die Value Stream-basierten Release Trains direkt.

Wenn eine Organisation aber ihre Matrix-Organisation aus Spezialisten-Pools und Projekt-/Produktteams beibehalten will, sei es aus schlechten Gründen (haben wir schon immer so gemacht) oder aus guten (zur Förderung fachlicher Exzellenz oder zur Ermöglichung langfristiger Personalentwicklung über mehrere Projekte hinweg), dann muss sie SAFe an dieser Stelle anpassen. Wenn aber vorgegeben ist, "dass alles agil werden soll"³ braucht es in diesem Fall auch eine "agile Variante der Matrix-Organisation".⁴

Und an dieser Stelle kommt das Spotify Model ins Spiel, dass ja nichts anderes als eine derartige Matrix ist. Die Spezialisten-Pools heissen in ihm Chapter und die "entleihenden" Einheiten sind die "Squad" genannten Teams, bzw. die aus mehreren Squads bestehenden Tribes. Dadurch, dass diese Chapter jetzt auch in SAFe eingeführt werden, so dass die Release Trains aus ihnen ihre Mitglieder beziehen können, entsteht auch dort eine Matrix-Organisation in Form von SpotiSAFe.

Je nachdem wie weit die "Spotifyisierung" von SAFe getrieben werden soll können auch noch weitere Elemente aus SAFe nach vergleichbaren Einheiten aus dem Spotify Model umbenannt werden, so dass z.B. aus den Teams die Squads werden, aus den Release Trains die Tribes und aus den Communities of Practice die Gilden. Der zentrale Punkt bleibt aber die Kombination von SAFe und Matrix-Organisation (mit irgendwie "agil klingenden" Namen).

Das ist es also, das SpotiSAFe Model, das seit etwa einem Jahrzehnt von den McKinseys, Boston Consultings und anderen Beratungen in einem Konzern nach dem anderen eingeführt wird. Es zu bewerten ist nicht eindeutig möglich, wie oben gesagt gibt es sowohl gute als auch schlechte Gründe für eine Beibehaltung eines Matrix-Aufbaus. Wie immer gilt also auch hier, dass es auf den jeweiligen Einzelfall ankommt - und darauf, wie gut man "agile Buzzwords" verträgt.⁵

Bild: Unsplash / wocintechchat - Lizenz

Mit wenig kann man sich in der agilen Community so einfach Applaus und Zustimmung abholen wie mit SAFe-Bashing. Die mit diesem Framework verbundenen Risiken und Probleme sind auch fraglos vorhanden, so dass die Ursache dieser Ablehnung häufig nachvollziehbar ist. Was dabei aber zu leicht untergehen kann: SAFe macht auch einige Sachen richtig, und das vor allem in einer Richtung: in der, in der sich das Management befindet.

Ein bisschen Kontext: die meisten klassischen agilen Frameworks (vor allem Scrum, XP und teambasiertes Kanban) konzentrieren sich mit ihren Rollen, Regeln, Meetings und Artefakten auf die Umsetzungs- und Team-Ebene. Die darüber liegenden Management-Schichten werden weitgehend ignoriert, und wenn sie thematisiert werden, dann überwiegend in dem Zusammenhang, dass sie bitte die Team-Autonomie oder die Ownership des Product Owners zu respektieren haben.

Im Rahmen von Transitions-Vorhaben führt das oft zu nicht zielführendem Umgehen mit vor allem mittleren Managern. Teilweise werden sie (ohne bösen Willen) ignoriert oder vergessen, teilweise werden sie bewusst ausgegrenzt, schlimmstenfalls wird ihnen konfrontativ der Verlust von Einfluss, Status, Budget oder Karriere in Aussicht gestellt. Dass das einen Widerstand gegen die anstehenden Veränderungen zur Folge hat, ist wenig überraschend.

Und auch wenn das Management sich bewusst darauf einlässt, den ab jetzt selbstorganisierten Teams möglichst viele Entscheidungen zu überlassen, kann das in Probleme führen: ob aufgrund fehlender Erfahrungen oder wegen nicht klar definierter Zuständigkeitsgrenzen, immer wieder wird es zu Situationen kommen, in denen doch wieder das Management um Entscheidungen gebeten werden wird - was schlimmstenfalls den Eindruck erwecken kann, "dass Selbstorganisation nicht funktioniert".

Der Weg den SAFe gefunden hat um mit diesen Risiken umzugehen ist der, dass direkt zu Beginn einer Transition (in Phase zwei der "Implementation Roadmap") explizit auch die "Executives, Managers and Leaders" trainiert werden müssen. Ganz bewusst soll diesen dabei sowohl vermittelt werden, dass an vielen Stellen ein Loslassen stattfinden muss, als auch, dass das nicht bedeutet, nicht mehr verantwortlich zu sein und sich aus den Veränderungen herausnehmen zu können.

Bei der Frage wie das zu geschenen hat bleibt zwar ausgerechnet das sonst oft sehr deskriptive SAFe erstaunlich wolkig. Auf der entsprechenden Website wird vor allem vermerkt, dass es keine Ausnahmen geben soll und dass die Vermittlung der Haltungen "Thinking Lean" und "Embracing Agility" im Mittelpunkt stehen sollen. Fairerweise muss man aber auch sagen, dass detailliertere Anleitungen den meisten Einzelfällen nicht gerecht werden würden.

Dass jemand, der eine (berechtigte oder unberechtigte) Abneigung gegen SAFe hat, auch die "SAFe Implementation Roadmap" nicht mögen wird, dürfte wenig überraschend sein - und man muss sie ja auch nicht benutzen. Alternativ sollte man dann aber eine andere Art finden, das Management von Beginn an einzubinden. Denn zur Zeit ist es ein Alleinstellungsmerkmal von SAFe, diese Einbindung verbindlich formalisiert zu haben.¹

Bild: Pixabay / Tookapic - Lizenz

Für alle agilen Frameworks gilt grundsätzlich, dass sie für sich genommen nicht gut oder schlecht sind, sondern Werkzeuge. Wie sie eingesetzt werden hängt stark vom Benutzer ab. Es gibt allerdings Unterschiede: Scrum mit seinem Sprint-Rhythmus könnte ein Hammer sein, Kanban mit seiner langsamen Verbesserung eine Feile. Und SAFe? Wenn wir in derartigen Analogien verbleiben wollen passt eine besonders gut - SAFe ist eine Motorsäge.

Um diese Gleichsetzung plastischer werden zu lassen: Motorsägen sind kraftvolle Geräte, mit denen man umfangreiche Arbeiten stark vereinfachen und beschleunigen kann, etwa das Baumfällen. Richtig eingesetzt können sie aber auch filigrane und fragile Ergebnisse erzeugen, z.B. Eis-Skulpturen. Was aber jedem bewusst sein muss - ca. 90 Prozent der Menschheit sollten besser keine Motorsägen bekommen, das Risiko von Unfällen wäre viel zu gross.

Warum das eine passende Analogie auf SAFe ist, dürfte klar sein. Mit dieser Methode lassen sich gut Vorhaben organisieren, die für einzelne Scrum Teams zu klein wären - und die Ergebnisse können durchaus agil sein. Da es aber sehr einfach ist, die SAFe-Regeln versehentlich oder absichlich für Hierarchie-Aufbau, Langfrist-Planung und Gross-Releases einzusetzen, ist die "Unfallwahrscheinlichkeit" sehr hoch, wenn die Beteiligten nicht genau wissen wie Agilität funktioniert.

Für den Fall, dass solche Leute nicht verfügbar sind, SAFe aber trotzdem vorgegeben ist (warum auch immer), zeigt die Werkzeug-Analogie sogar einen Lösungsweg auf: in praktisch alles Firmen, in denen mit tendenziell gefährlichen Werkzeugen und Maschinen gearbeitet wird, gibt es regelmässige (Re)Sensibilisierungsprogramme, mit denen Unfällen vorgebeugt werden soll. Eines der bekanntesten unter ihnen ist der so genannte "Near Miss".

In Near Miss-Programmen werden Mitarbeiter regelmässig (z.B. einmal pro Monat oder Quartal) aufgefordert nachzudenken, wo es zu Unfällen hätte kommen können (Near Miss bedeutet Knapp verfehlt), wie diese Situationen entstanden sind und wie man versuchen kann zu verhindern, dass sie sich nochmal ergeben. Über die individuelle Verbesserung hinaus kann man dabei durch Aggregation der Ergebnisse auch auf verbreitete Probleme und Risiken aufmerksam werden.

Auf SAFe übertragen bedeutet dass, dass regelmässig darüber reflektiert werden sollte, wo in der letzten Zeit die angestrebten kurzen Entscheidungswege, schnellen Feedback-Schleifen und häufigen Mehrwert-Auslieferungen eher behindert als befördert wurden. Ein naheliegender Zeitpunkt dafür wären die Inspect & Adapt-Events am Ende jedes PI-Zyklus, in die man das Thema als kontinuierlich wiederkehrenden Punkt integrieren könnte.

Natürlich setzt all das voraus, dass Hierarchie-Aufbau, Langfrist-Planung und Gross-Releases im Rahmen der jeweiligen SAFe-Implementierung auch tatsächlich nicht angestrebt werden. Dort wo das offen oder verdeckt doch der Fall ist, wird eine Near Miss-Routine keine Wirkung entfalten. Allerdings ist sie dann auch nicht das wichtigste Thema an dem gearbeitet werden sollte.

Dass das Scaled Agile Framework (SAFe) in der agilen Community eher kritisch gesehen wird dürfte sich mittlerweile herumgesprochen haben. Es zu bashen gehört mittlerweile fast schon zum guten Ton, was dazu führt, dass es leider nur noch sehr einseitig betrachtet wird. Man kann ihm nämlich auch positive Aspekte abgewinnen, darunter einen der auf den ersten Blick überraschend wirkt - SAFe ist einfach zu erklären und zu verstehen.

Überraschend ist das deshalb weil in der öffentlichen Wahrnehmung vor allem das grosse Wimmelbild auf der Startseite von scaledagileframework.com bekannt geworden ist. Das als Grundlage einer einfachen Erklärung zu nutzen wäre tatsächlich eine Herausforderung. Was dabei allerdings oft übersehen wird ist, dass diese Übersicht stark mit Elementen überladen ist die optional sind oder bei denen es sich um Implementierungsdetails handelt. Um SAFe zu verstehen braucht man nur wenige.

Fangen wir oben an, bei einem Teil der zentral ist und in keiner Umsetzungen vernachlässigt werden sollte: dem Portfolio Kanban. Sein Design kann sich zwar je nach Fall unterscheiden, wichtig ist aber, dass hier die grossen Arbeitspakete (Epics) der zur Zeit umgesetzten Initiativen von links nach rechts wandern. Idealerweise wird diese Übersicht genutzt um zu verhindern, dass zu viele gleichzeitig begonnen werden, so dass mehr Focus und weniger Multitasking entstehen.

Bei der Organisation der Umsetzung tritt eine zentrale Annahme von SAFe in den Vordergrund: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen. Aus diesem Grund wird eine doppelte Gruppierung vorgenommen - jeweils mehrere Teams arbeiten über mehrere aufeinanderfolgende Kurz-Zeiträume an einem solchen Arbeitspaket. Der Name einer solchen Gruppierung ist Release Train, die Zeitspanne nennt sich Program Increment (PI).

Damit die Teams eines Release Trains nicht nur gemeinsame Umsetzungszeiträume haben sondern auch an zusammengehörigen Themen arbeiten (und dabei die untereinander bestehenden Abhängigkeiten berücksichtigen) findet zu Beginn jedes Program Increments eine gemeinsame Planung statt, das PI Planning, bzw. Big Room Planning. Ggf. können begleitend dazu auch Retrospektiven stattfinden, entweder davor (für das letzte PI) oder danach (für das PI Planning selbst).

In der Theorie arbeiten die einzelnen Teams zwischen zwei PI Plannings nach Scrum (in mehreren Sprints), de facto ist dieser Arbeitsmodus aber stark beschnitten, da die Integration in einen Release Train dafür sorgt, dass die eigentlich vorgesehene Team-Autonomie nur noch eingeschränkt möglich ist. Vor allem die Kompetenzen des Product Owners und Scrum Masters werden zum Teil auf entsprechende Koordinationsrollen im Release Train übertragen, den Product Manager und den Release Train Engineer.

Und das ist sie auch schon, die einfache Erklärung von SAFe in nur vier Absätzen. Wendet man diesen Erklärungsansatz an hat das zwei Vorteile: zum Ersten den, dass erkennbar wird, dass sich hinter dem unübersichtlichen offiziellen Übersichtsbild eigentlich nur ein relativ einfacher Skalierungsansatz verbirgt. Hat man den erfasst wird es auch einfacher zu beurteilen welche der zahlreichen anderen Elemente man nutzen will und welche nicht.

Zum anderen kann man die zentrale Annahme von SAFe herausstreichen: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen, weshalb sie in Release Trains und Program Incrementen zusammengekoppelt werden. Und an dieser Stelle wird diese einfache Erklärung auch für die SAFe-Skeptiker interessant - wenn sie belegen können, dass die Teams dazu doch in der Lage sind, entfällt die Notwendigkeit SAFe einzuführen.

Umgekehrt betrachtet: dort wo einzelne Teams nicht in der Lage sind in einzelnen Sprints Mehrwert abzuliefern ist SAFe zumindest eine Option. Ob es die richtige ist muss sich im Vergleich mit anderen Skalierungsframeworks klären, deren Befürworter dann in der Lage sein sollten sie ähnlich einfach zu erklären wie das bei SAFe möglich ist.