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.

Bild: Flickr / Marco Verch - CC BY 2.0

Es gilt als eines der Erkennungsmerkmale von SAFe, ist aber als verbreitete Praktik auch in anderen agilen Skalierungsframeworks zu finden, und sogar in manchen klassisch aufgestellten Organisationen als Teil ihrer Jahres- oder Quartalsplanung. Die Rede ist vom Big Room Planning oder BRP (mittlerweile in SAFe in PI Planning umbenannt), einer Veranstaltung die genutzt wird um die Backlogs oder Roadmaps der beteiligten Teams aufeinander abzustimmen.

Wichtig zu seinem Verständnis ist, dass es aus puristisch agiler Sicht eigentlich Ausdruck einer Dysfunktion ist, bzw. diese kompensiert. Agil arbeitende Teams sollen möglichst crossfunktional sein, d.h. alle zum Abschluss ihrer Vorhaben nötigen Fähigkeiten und Berechtigungen selbst besitzen. Dort wo das gegeben ist gibt es für übergreifende Planungsstrukturen keine Notwendigkeit. Da das in der Realität oft aber nicht gewollt oder möglich ist wurde das Big Room Planning erfunden.

Als eine agile Praktik wird es deshalb angesehen, weil es zwei Sachen anders macht als traditionelle Planungspraktiken. Zum einen werden von einander abhängige Arbeitspakete nicht sequentiell abgearbeitet (wie häufig in Gantt-Charts zu sehen) sondern weitgehend parallelisiert. Die zusammengehörigen Aufgaben werden dabei von den Teams in den selben Sprints oder Wochen eingeplant um bereits in ihnen zusammengeführt und integriert zu werden.

Das zweite agile Merkmal der Big Room Plannings ist, dass die Koordination der Teams nicht von einem dafür zuständigen Management übernommen wird sondern von den jeweiligen Teammitgliedern selbst. Um das möglich zu machen führen die beteiligten Teams ihre Planungsaktivitäten gemeinsam in einem grossen Raum durch (daher der Name)¹ um sich bei Bedarf schnell besuchen und unbürokratisch miteinander abstimmen zu können.

Ein typischer Ablauf sieht so aus, dass bereits im Vorfeld grob geklärt wurde welche Arbeitspakete externe Zulieferungen benötigen (ggf. in teamübergreifenden Refinements). Basierend darauf können diese in einer initialen teamübergreifenden Vorstellungsrunde hervorgehoben werden, wodurch der Bedarf klargemacht wird. Zusätzlich können alle anderen überprüfen ob auch sie ebenfalls davon betroffen sein könnten.

In einer ersten Planungsrunde erarbeitet und priorisiert danach zuerst jedes Team für sich die eigenen Anforderungen und Zulieferungen, in einer zweiten Phase werden diese Ergebnisse den anderen Teams mitgeteilt und diesen wird die Möglichkeit zu Feedback und Änderungsvorschlägen gegeben, in einer dritten passt jedes Team basierend darauf seine Pläne an. Dieser Wechsel von Einzelplanung und Abstimmung kann so lange wiederholt werden bis ein gemeinsamer Plan herauskommt.

Als zusätzlicher Effekt können durch ein Big Room Planning nicht nur die Umsetzungs- sondern auch die Planungszeiträume deutlich verkürzt werden. Die teamübergreifend gemeinsame Terminierung, die direkte Kommunikation und die kurzen Wege können in Stunden oder Tagen ermöglichen, was vorher mitunter Wochen und Monate gedauert hat.² Natürlich unter der Voraussetzung, dass alle Mitglieder aller beteiligten Teams für die gesamte Dauer der Veranstaltung zur Verfügung stehen.

Bereits für eine effizientere Durchführung der Planungen für bestehende Teams kann ein Big Room Planning auf diese Weise einen erheblichen Mehrwert liefern, zu einer nachhaltigen Agilisierung des Unternehmens trägt es aber paradoxerweise dadurch bei, dass es sich selbst nach und nach abschafft. Die in ihm offensichtlich werdenden Abhängigkeiten lassen sich nämlich festhalten und auf langfristige Muster untersuchen, die dann grundlage für Prozessverbesserungen sein können.

Wenn beispielsweise alle Teams jedesmal von einem einzelnen abhängen kann überlegt werden dessen Skills und Berechtigungen auf die anderen zu übertragen (wenn es ein Spezialistenteam ist) oder seine Systeme für die Bearbeitung durch andere zu öffnen (wenn es ein Komponententeam ist). Andere denkbare Verbesserung wären die Vergrösserung von Flaschenhals-Teams oder das Aufteilen eines Teams (und seiner Systeme) analog zu fachlichen Domänen.

Als Folge derartiger Optimierungen werden Big Room Plannings häufig mit der Zeit kleiner oder teilen sich in voneinander unabhängige "Small Room Plannings" auf. Umgekehrt kann ein mit der Zeit immer grösser werdendes Big Room Planning ein Zeichen dafür sein, dass die Zahl der Abhängigkeiten zwischen den Teams wächst und die Gesamtorganisation dadurch schwerfälliger wird. Sicherlich eine weitere interessante Transitionsmetrik.

Bild: Pexels / Andrea Piacquadio - Lizenz

Über die Herausforderungen und Fallstricke die sich ergeben wenn man versucht das Scaled Agile Framework (SAFe) in einem Grossunternehmen einzuführen¹ ist mittlerweile so viel gesagt worden, dass man darüber ganze Bücher schreiben könnte. Die meisten davon würden sich aber sehr einseitig um die Debatte drehen ob ein Konstrukt mit so viel Regulierung und so vielen Rollen überhaupt agil sein kann² und einen weiteren, vermutlich sogar tiefgreifenderen Aspekt dabei erstaunlich vernachlässigen.

Es handelt sich um die Frage ob die oft negative Wahrnehmung von SAFe nicht mittlerweile Züge einer selbsterfüllenden Prophezeihung hat. Von der überwältigenden Mehrheit der vom Konzept der Agilität überzeugten Angehörigen der unteren Hierarchie-Ebenen schlägt SAFe heute eine hohe Skepsis entgegen, zum Teil sogar eine vehemente Ablehnung.³ Wie berechtigt das ist, ist dabei gar nicht relevant, wichtig ist die Wahrnehmung selbst.

Deren mittlerweile weite Verbreitung resultiert darin, dass auf Team- oder Abteilungsebene selbstorganisierte Optimierungsbemühungen praktisch nie dazu führen, dass dort SAFe als Lösungs- oder Verbesserungs-Option für Koordinations- oder Alignment-Probleme genannt wird. Wenn es diskutiert wird dann fast ausschliesslich auf Betreiben von Beratern oder Managern. Aus Sicht der umsetzenden Einheiten kommt es damit "von Aussen".

Wer bereits Change Management in grossen Organisationen betrieben hat wird das an derartigen Stellen entstehende Risiko kennen: das Gefühl von Aussen eine ungewollte Änderung aufgedrückt zu bekommen kann zu Abstossungsreaktionen führen, manchmal in Form von aktivem Widerspruch und Widerstrand, oft durch passive und ausweichende Handlungsmuster wie dem ständigen Melden von Verständnis-Poblemen, Dienst nach Vorschrift und brauchbarer Illegalität.

Alle Varianten sind bereits für sich genommen problematisch, im Kontext des agilen Arbeitens, das stark auf freiwillige Kooperation und Eigeninitiative aller Beteiligten angewiesen ist, sind sie es nochmal in besonderer Form. Die in vielen SAFe-Umsetzungen zu findenden hohen Ausmasse am Konfliktlastigkeit, Ineffektivität und Ineffizienz lassen sich in weiten Teilen damit erklären, ggf. noch verschärft durch Versuche die Einführung zu erzwingen oder den Mitarbeitern ihre Bedenken auszureden.

¹Für kleinere Einheiten ist es nicht gedacht 
²Was weniger einfach zu beantworten ist als viele denken
³Eine Entwicklung die durch skeptische Äusserungen vieler "Thought Leader" befeuert wird

Bild: Pixabay / Geralt - Lizenz

Es ist nicht so, dass der Einsatz von SAFe grundsätzlich Proble nach sich ziehen würde, sinnvoll eingesetzt kann dieses Framework in vielen Organisationen zu Verbesserungen im Vergleich zum Ist-Zustand führen. Es ist aber leider so, dass bestimmte Probleme doch immer wieder auftreten. Eines davon kann besonders schwerwiegende Folgen haben, und  um das soll es heute gehen: auf viele traditionell sozialisierte Manager wirkt die grosse Prozess- und Rollenübersicht auf (je nach Blickwinkel) verlockende oder fatale Weise bekannt.

Unabhängig davon was die eigentliche Intention des Frameworks ist, in den verschiedenen organisatorischen Ebenen lassen sich die alten Hierarchien wiedererkennen. Ganz unten die (SAFe-)Scrum-Teams mit ihren (SAFe-)Scrum Mastern und (SAFe-)Product Ownern¹, ganz oben die Epic Owner und Solution Manager, dazwischen ein Mittelbau aus Release Train Engineers, Business Ownern, System Engineers und Product Managern - das alles weist grosse Ähnlichkeiten zu dem klassischen unteren, oberen und mittleren Management auf.

Alleine dieses Gleichsetzungs-Potential wäre schon problematisch genug, es wird aber noch um eine weitere Dimension erweitert: auf jeder der mittleren und oberen Ebenen ist zwischen den Rollen ein horizontaler Aufgabenschnitt erkennbar. Business Owner, Product Manager, Release Train Engineers und System Engineers können als Entsprechung bekannter tayloristischer Aufteilungen in Anforderungsmanagement, Projektmanagement, Prozessmanagement und technisches Management gesehen werden. Die Gefahr besteht, dass hier wieder die Verteter der alten Silos zusammensitzen und ihre jeweiligen Partikularinteressen vertreten.

Auch auf der Zeitebene kann ein (scheinbarer) Wiedererkennungseffekt eintreten. Programm-Incremente die über Monate hinweg erstellt werden haben ähnliche Zeithorizonte wie die alten Release- oder Quartalspläne, Feature- und Enabler-Epics können so verstanden werden, dass Komponententeams getrennt von einander auf eine späte Integration hinarbeiten und den ganz rechts abgebildete "Release on Demand" kann man auch so verstehen, dass es einen Big Bang-Release ganz zum Schluss gibt, da es ja vorher keinen Bedarf nach halbfertigen Lösungen gibt.

Die Problematik dieser und ähnlicher Gleichsetzungen ist offensichtlich - Wenn sie zu der Ansicht führen, dass man nur die bestehenden Strukturen umbenennen muss um sich erfolgreich in Richtung Agil zu transformieren steht am Ende eine Mischung aus Missverständnis und Etikettenschwindel, aber ganz sicher kein Erfolg. Und um es noch einmal zu betonen: ein derartiges Ergebnis ist sicher nicht im Sinn von SAFe, es ist aber eines das dadurch sehr wahrscheinlich wird, dass traditionell sozialisierte Manager in der grossen Prozess- und Rollenübersicht vieles erkennen werden was ihnen fatale Weise bekannt vorkommt.

¹Ganz bewusst mit diesem Präfix, um zu zeigen, dass das nicht die gleich benannten Rollen/Verantwortlichkeiten aus Scrum sind