Agile Skalierungsframeworks

Zusammenfassung
Sobald Unternehmen erkennen, dass agile Arbeitsweisen enorme Auswirkungen auf die Time-to-Market, die Kundenzufriedenheit und das Engagement der Mitarbeiter haben können, beginnen sie über die Skalierung von Agilität nachzudenken.

Es gibt das Missverständnis, dass man als große Organisation einen skalierten Ansatz braucht. Das stimmt nicht unbedingt, denn Skalierung ist in erster Linie für die Fälle relevant, in denen das Produkt zu groß für ein kleines Team ist, um es zu entwickeln.

Wie man Produkte aufteilt und ob man skaliert oder nicht, sind wahrscheinlich wichtigere Fragen als die, welche Art von Skalierungs-Framework man wählen sollte. Leider stellen sich zu wenige Unternehmen diese Fragen - vielleicht aufgrund des großen Andrangs von Skalierungsframeworks durch Berater.

Wenn eine Organisation skalieren muss, gibt es viele Skalierungsframeworks, aus denen man wählen kann, darunter SAFe, LeSS, Scrum@Scale und ein paar andere. Aber keines dieser Frameworks sollte "out of the box" angewendet werden.

Wir sind der festen Überzeugung, dass sich Unternehmen von diesen Frameworks inspirieren lassen sollten, aber anstatt sie zu kopieren, sollten sie sich an einer Reihe von Prinzipien orientieren, wie z.B. Dezentralisierung der Entscheidungsfindung, Lean Thinking und Empirie inkl. kontinuierlicher Verbesserung.

Damit jede Art von Veränderung erfolgreich sein kann, einschließlich der Skalierung agiler Arbeitsweisen, ist es für Führungskräfte unerlässlich, ihre Arbeitsweise anzupassen. Für die meisten von ihnen bedeutet dies, von der Arbeit in der Organisation zur Arbeit an der Organisation überzugehen.

Der primäre Fokus liegt auf dem Empowering (Ermöglichen von Entscheidungen) und Enabling (Aufbau von Fähigkeiten zur Entscheidungsfindung) von Teams und Einzelpersonen. Damit dies gelingt, müssen Manager/Führungskräfte neben der systematischen Entwicklung ihrer Teams und Teammitglieder damit beginnen, die Strukturen, Richtlinien und Metriken ihrer Organisation zu verändern.

Einführung in die Skalierung agiler Arbeitsweisen

In fast jedem Workshop, den ich durchführe, fragen mich die Teilnehmer, wie man Scrum oder agile Teams skalieren kann. Der Grund, warum sie fragen, ist, dass in ihren Organisationen selten nur 10 Personen oder weniger arbeiten - meistens sind es viel mehr.

Viele von ihnen kommen aus großen Unternehmen, sei es aus dem Finanzdienstleistungssektor, der Automobilindustrie, der Pharmazie oder der Medizintechnik. In vielen großen Konzernen haben sie große Produkte, z.B. ein Auto, an dem viele, d.h. hunderte von Menschen arbeiten.

In vielen großen Konzernen haben sie große Produkte, z.B. ein Auto, an dem viele, d.h. hunderte von Menschen arbeiten.

Der Irrglaube dabei ist, dass sie denken, dass die Anzahl an Leuten automatisch zu einem skalierten Ansatz führt. Dies muss aber nicht stimmen. Eine Organisation kann viele Menschen und viele Teams haben, aber solange jedes dieser Teams an einem individuellen Produkt arbeitet, müssen sie nicht unbedingt skalieren - zumindest im traditionellen agilen Sinne, wie wir den Begriff Skalierung verwenden.

Was bedeutet agile Skalierung?

Agile Skalierung wird nämlich erst relevant, wenn mehr als ein Team am gleichen Produkt arbeitet. Es lohnt sich, dies noch einmal zu betonen: viele Teams arbeiten an demselben Produkt! Um also festzustellen, ob Sie einen skalierten Ansatz benötigen, ist es wichtig, sich zunächst Ihre Produktdefinition anzusehen.

Wie kann man ein Produkt definieren?

Es gibt viele Möglichkeiten, dies zu betrachten. Eine Möglichkeit ist aus der Kundenperspektive. Was sehen meine Kunden als Produkt an, d.h. was sind sie bereit, für z.B. Microsoft Office zu bezahlen?

Eine andere Perspektive ist eine eher interne: Was sind die verschiedenen Komponenten eines Produkts, die wir weitgehend unabhängig entwickeln können, z. B. Microsoft Excel oder Funktionen innerhalb von Excel.

Eine Perspektive, die viele Unternehmen einnehmen, ist weder das eine noch das andere. Vielmehr betrachten sie die verschiedenen architektonischen Teile eines Produkts und teilen die Teams darauf hingehend ein. Dieser Ansatz führt meist zu Silos und einer Menge Abhängigkeiten zwischen den Teams.

Die zweite Option kann in vielen Fällen zu vielen kleinen Teams führen, die größtenteils unabhängig voneinander arbeiten, so dass kein formaler Skalierungsansatz erforderlich ist. Aber selbst wenn ein Skalierungsansatz erforderlich wäre, ist es viel einfacher, die einzelnen Teams und die teamübergreifende Arbeit zu koordinieren, da die Produktgrenzen klar definiert sind.

Wie skalieren wir?

Weiter unten in diesem Artikel werden wir die gängigsten Skalierungsansätze zusammenfassen. Doch bevor wir dazu kommen, möchten wir die Frage klären, wie wir skalieren und welche Prinzipien uns helfen können, besser zu skalieren.

Jedes agile Team, z. B. ein Scrum-Team, hat drei verschiedene Verantwortlichkeiten: Was bauen wir? Wie bauen wir es (technisch)? Wie arbeiten wir zusammen (Methodik)? Der größte Unterschied zwischen den verschiedenen Skalierungsansätzen ist, ob sie die gesamte Einheit, d.h. das Scrum-Team mit all seinen Verantwortlichkeiten, skalieren oder ob sie nur die Wie-Verantwortlichkeiten skalieren.

Diese Unterscheidung ist wichtig, da sie sich direkt auf eines der wichtigsten agilen Prinzipien bezieht, nämlich die Dezentralisierung der Entscheidungsfindung an den Ort, an dem die Arbeit und die Kundeninteraktion stattfindet. Sie ist auch deshalb wichtig, weil dadurch bestimmt wird, wie viele neue Rollen geschaffen werden und welche Rolle die Führung außerhalb dieser Teams einnimmt.

Welche Arten von agilen Skalierungsframeworks gibt es?
Es gibt viele Möglichkeiten, die agile Entwicklung innerhalb einer Organisation zu skalieren. Keiner dieser Ansätze deckt vollständig ab, wie eine Organisation strukturiert sein sollte. Sie decken meist nur die Produktentwicklungseinheit einer Organisation ab.

Alle unterstützenden Abteilungen innerhalb eines Unternehmens, wie Finanzen, Recht, HR und Einkauf werden von keinem der Skalierungsframeworks abgedeckt. Obwohl einige - auch Berater, die diese Frameworks verkaufen - behaupten, dass dies der Fall ist, ist es in Wirklichkeit nicht so.

Im folgenden Abschnitt wollen wir mit dir einen allgemeinen Überblick über die am häufigsten verwendeten Skalierungs-Frameworks teilen. Aber sei dir bewusst, dass 'am meisten verwendet' nicht gleichbedeutend mit 'am besten' ist. Wir sind der festen Überzeugung, dass jedes dieser Frameworks einige deutliche Vorteile, aber auch erhebliche Nachteile hat.

Besser als nur eines der Rahmenwerke zu kopieren, ist es, die Schlüsselprinzipien für die Skalierung der agilen Entwicklung zu verstehen und etwas innerhalb deiner Organisation zu schaffen, das sich durch regelmäßige und häufige Überprüfung und Anpassung ständig weiterentwickelt. Jede Organisation ist einzigartig in ihrer Kultur und ihren Herausforderungen... deine Arbeitsweise sollte das widerspiegeln.

Scaled Agile Framework (SAFe)

Das Scaled Agile Framework - auch bekannt als SAFe - ist das wohl am besten dokumentierte agile Skalierungs-Framework. Es wurde von Dean Leffingwell erfunden und wird regelmäßig aktualisiert. Die neueste Version können Sie sich hier ansehen.

SAFe ist wahrscheinlich auch das präskriptivste aller Skalierungs-Frameworks. Vielleicht ist das der Grund, warum viele große Unternehmen ihre Skalierungsreise mit SAFe beginnen. Wie bereits erwähnt, bedeutet das nicht unbedingt, dass SAFe das Skalierungsframework der Wahl sein sollte. Tatsächlich habe ich noch keine erfolgreiche SAFe-Implementierung gesehen.

SAFe nimmt eine Team-of-Teams-Sichtweise ein, die sie als Agile Release Train a.k.a. ART bezeichnen. Ein ART basiert auf mehreren Scrum- oder Kanban- oder wie auch immer agilen Teams. Auf der Teamebene gibt es Product Owner, Scrum Master und Entwickler. Auf der ART-Ebene gibt es ähnliche Rollen namens Product Management, Release Train Engineer (RTE) und System Architect/Engineer.

Das bedeutet, dass SAFe die gesamte Einheit eines Scrum-Teams skaliert, inkl. der What-Accountabilities, die dann beim Produktmanagement liegen. Dies führt zu erheblichen Herausforderungen, da ein Product Owner in SAFe nicht dasselbe ist wie ein Product Owner in Scrum. Der SAFe Product Owner ist meist eine Person, die das Backlog auf Teamebene verfeinert - was man nicht mehr wirklich als Product Backlog bezeichnen kann.

Einer der Hauptvorteile von SAFe ist, dass Unternehmen dazu neigen, weniger Widerstand bei der Umstellung auf SAFe zu leisten als bei jedem anderen Framework - zumindest ist das meine Erfahrung. Das kann gut sein, weil es dazu führt, dass Unternehmen den ersten Schritt zur Veränderung machen. Es kann aber auch schlecht sein, wenn sie glauben, dass die Implementierung von SAFe bereits das Ziel ist.

Eines der wichtigsten Dinge, die man im Hinterkopf behalten sollte, ist, dass ein Skalierungsansatz umso weniger zu unterschiedlichen Ergebnissen führt, je ähnlicher er Ihrer aktuellen Organisationsstruktur, Ihren Richtlinien und Metriken ist. SAFe zu implementieren ist also wahrscheinlich einfacher als einige der anderen Frameworks, aber höchstwahrscheinlich wird es Sie auch nicht viel näher an die Erreichung Ihrer Ziele bringen.

Large Scale Scrum (LeSS)

Large Scale Scrum - auch bekannt als LeSS - ist ein weiterer häufig verwendeter Skalierungsansatz. LeSS wurde von Craig Larman und Bas Vodde erfunden. Beide sind sehr erfahrene Personen und Systemdenker. Beide sind auch sehr eigenwillig.

Im Vergleich zu SAFe skaliert LeSS nur die Wie-Teile des Scrum-Teams, d.h. die Entwickler und teilweise den Scrum Master. LeSS in seiner einfachsten Form schafft keine Product Owner Hierarchie. Das bedeutet, dass ein LeSS Product Owner wirklich ein Product Owner (im Sinne von Scrum) ist und mit mehreren Teams zusammenarbeitet, um die Ziele von und für das Produkt zu erreichen.

Basierend auf dieser Definition braucht ein Product Owner in LeSS sehr reife Teams. Reif in ihrem Verständnis für den Kunden, reif in ihrem Verständnis, wie man Product Backlog Items aufschlüsselt und reif in Bezug auf die enge Zusammenarbeit mit den Stakeholdern.

Im Vergleich zu einem nicht skalierten Scrum Team, in dem normalerweise ein Product Owner den größten Teil des Product Backlog Refinements, der Kundeninteraktion und des Stakeholder Managements übernimmt, würde in LeSS nicht genug Zeit für eine einzelne Person zur Verfügung stehen, um dies für alle ihre Teams zu tun.

Da ich ein großer Fußballfan bin, verwende ich häufig Analogien aus der Welt des Fußballs, wenn ich mit Kunden spreche. LeSS zu implementieren ist wie in der Champions League zu spielen. Das sollte nicht jemand machen, der nicht schon eine großartige Scrum-Implementierung vorweisen kann.

Im Vergleich zu SAFe nimmt LeSS viel von der Bürokratie großer Organisationen und mit diesen vielen Managementebenen weg. Das fühlt sich für viele Leute unangenehm an, wenn sie es nur anschauen, geschweige denn anwenden.

Eine LeSS-Implementierung ist nicht einfach und im Vergleich zu dem, was andere Frameworks behaupten, erfordert LeSS wahrscheinlich die größte Veränderung in der Art, wie Manager führen und erfordert auch den meisten Fokus, Energie und Zeit in der Entwicklung von Menschen. Der Wechsel von Komponenten- zu Feature-Teams ist nur eines von vielen Beispielen.

Das bedeutet nicht, dass LeSS schlecht ist. Wenn ich mich für eines dieser Frameworks für meine Organisation oder für meine Kunden entscheiden müsste, wäre es wahrscheinlich LeSS. Aber LeSS braucht auch das meiste Engagement der obersten Führung und die meiste Zeit, um die Teams darauf vorzubereiten. Es wird wahrscheinlich auch zu den bedeutendsten Ergebnissen führen.

Für Produktentwicklungsinitiativen, die mehr als 8 Teams erfordern, hat LeSS eine spezielle Konfiguration namens LeSS Huge. Der einzige Unterschied ist, dass LeSS nun auch die Product Owner Rolle skaliert. Es gibt immer noch einen Product Owner, aber für verschiedene Bereiche gibt es sogenannte Area Product Owner.

Scrum@Scale

Scrum@Scale wurde von Dr. Jeff Sutherland, einem der Mitbegründer von Scrum, erfunden. Ähnlich wie bei SAFe skaliert Scrum@Scale die gesamte Einheit eines Teams, also das Was und das Wie.

Die Ebene oberhalb des Scrum Teams hat einen Chief Product Owner und einen Scrum of Scrums Master. Es gibt einen Product Owner Zyklus, der zum Executive Meta Scrum (EMS) führt und einen Scrum Master Zyklus, der zum Executive Action Team (EAT) führt.

Ähnlich wie LeSS legt Scrum@Scale viel Wert auf die Dezentralisierung der Entscheidungsfindung in die Teams. Jeff Sutherland selbst ist ein großer Verfechter davon, dass der Product Owner für die Wertschöpfung für den Kunden verantwortlich ist und nicht nur jemand, der an einem Backlog arbeitet.

Der Scrum@Scale Guide dokumentiert recht gut, wie das Framework grundsätzlich funktioniert. Ab und zu wird es etwas kryptisch, aber das Wesentliche ist, dass Scrum@Scale ein fraktaler Ansatz zur Skalierung von funktionierenden Scrum Teams ist. Daher sollte es auch nicht der Einstiegspunkt für jedes Unternehmen sein. Eigentlich kann man das über alle Skalierungs-Frameworks sagen.

Nexus

Nexus wurde von dem anderen Miterfinder von Scrum Ken Schwaber entwickelt. Als Framework scheint es LeSS sehr ähnlich zu sein, obwohl es einen deutlichen Unterschied gibt, nämlich das Nexus Integration Team. Ansonsten skaliert Nexus - ähnlich wie LeSS - in erster Linie die Wie-Verantwortlichkeiten und behält dabei einen einzigen Product Owner. Mehr über Nexus können Sie hier lesen.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery - auch bekannt als DAD - wurde von Scott Ambler und Mark Lines erfunden. Ich bin kein Experte für DAD und habe - obwohl ich mit vielen Organisationen zusammenarbeite - noch nie gesehen, dass es im wirklichen Leben angewendet wird. Das heißt nicht, dass DAD nicht angewandt wird und nicht funktioniert, sondern nur, dass ich es nicht gesehen habe. Sie können hier mehr darüber lesen.

Spotify-Modell

Dies ist ein interessantes Modell. Die wichtigsten Leute hinter dem Spotify-Modell - einer von ihnen ist mein Freund Henrik Kniberg - sagen, dass es kein Spotify-Modell per se gibt. Dennoch verkaufen viele der großen Beratungsunternehmen dies an ihre Kunden. Sie reden von Tribes, Squads und Guilds, während die meisten von ihnen (eigentlich alle) noch nie einen Fuß in Spotify gesetzt haben, um zu sehen, ob und wie dieses "Modell" funktioniert.

Das Spotify-Modell klingt lustig und cool, schließlich ist Spotify ein lustiges und cooles Unternehmen. Aber passt dieses Modell eines skandinavischen Musikstreaming-Startups - selbst wenn es existieren würde - wirklich zu einem deutschen Telekommunikationsunternehmen, einem Schweizer Pharmakonzern oder einer amerikanischen Versicherung? Persönlich bezweifle ich das stark.

Glücklicherweise behauptet niemand bei Spotify, dass dieses Modell universell anwendbar ist... eigentlich behaupten sie nicht einmal, dass es innerhalb von Spotify funktioniert. Wenn Sie genau hinhören, was Henrik in seinen Videos über Spotifys Entwicklerkultur erzählt, werden Sie hören, wie er sagt, dass sich das alles großartig anhört, dass es aber immer noch eine Menge Probleme bei Spotify gibt und dass sie kontinuierlich daran arbeiten, ihre Arbeitsweise zu verbessern. Es gibt also nicht das Modell bei Spotify ... es gibt nur Momentaufnahmen.

Wie kannst du dein Unternehmen agil skalieren?

Wenn wir mit Organisationen arbeiten, ist es unser Ziel, ihnen zu helfen, zu verstehen, dass sie zwar viele Einsichten und Inspirationen aus verschiedenen Skalierungs-Frameworks mitnehmen können, aber das Wichtigste ist, einige grundlegende Prinzipien der Skalierung der agilen Produktentwicklung zu verstehen und dann das Unternehmen ständig in Richtung dieser Prinzipien weiterzuentwickeln.

Einige der wichtigsten Prinzipien, die wir uns ansehen, sind die folgenden:
Skaliere nicht, wenn du es nicht musst, d.h. bevor du über Skalierung nachdenkst, schau dir an, ob du dein Produkt so aufteilen kannst, dass kleine Einheiten unabhängig daran arbeiten können, was die Skalierung irrelevant macht
Jedes Team und das Team-der-Teams sind so aufgestellt, dass sie idealerweise Kundennutzen liefern und kundenzentriert sind
Lean Thinking anwenden, d.h. Verschwendung durch Begrenzung des Work-in-Progress, rigoroses Prototyping (Discovery) und häufiges Kundenfeedback reduzieren
Kontinuierliche Verbesserung der Arbeitsweise durch regelmäßige und häufige Team- und teamübergreifende Retrospektiv-Meetings
Dezentralisiere die Entscheidungsfindung so weit wie möglich durch die Schaffung von Klarheit und die Entwicklung von Kompetenz innerhalb der Teams
Umarme die Ungewissheit und schaffe eine Mentalität der Empirie sowohl für das, was gebaut wird, als auch für das, wie es gebaut wird

Diese Liste ist bei weitem nicht erschöpfend. Aber wenn eine Organisation und ihr Führungsteam sich diese Prinzipien zu Herzen nehmen, haben wir gesehen, dass sie die organisatorische Agilität sowie die Kundenzufriedenheit und das Engagement der Mitarbeiter enorm verbessern.

Was müssen Führungskräfte über die agile Skalierung wissen?

In zu vielen Fällen habe ich erlebt, dass Führungskräfte glauben, dass sie nicht mehr gebraucht werden, sobald sich ein Unternehmen in Richtung Agilität bewegt. Dies ist einer der Gründe, warum sich viele Führungskräfte gegen organisatorische Veränderungsinitiativen wehren - die Angst, ihren Status oder sogar ihren Job zu verlieren.

Ich glaube, dass keine organisatorische Veränderung ohne das Management stattfinden wird, sowohl das Top- als auch das mittlere Management. Diese Gruppen sind diejenigen, die an der Organisation arbeiten, im Vergleich zu allen anderen, die hauptsächlich in der Organisation arbeiten.

Die Organisation selbst ist wie ein Produkt. Sie muss entwickelt werden. Und in Anbetracht der sich schnell verändernden Umwelt für die meisten Unternehmen, ist es meine feste Überzeugung, dass jedes Unternehmen - ähnlich wie die meisten Produkte - ein work in progress ist, d.h. kontinuierlich verbessert werden muss. Dies ist die Aufgabe von Managern/Leitern in den Organisationen.

Für die meisten Leiter bedeutet dies, dass sich ihre Arbeit deutlich verändert. Für diejenigen, die bisher ihre Teams micromanaged haben, bedeutet es, die Teams zu ermächtigen und zu befähigen, mehr und mehr Entscheidungen zu treffen. Für diejenigen, die direkt in Produktentscheidungen involviert waren, bedeutet es, dass sie sich entscheiden müssen, ob sie in einer produktfokussierten Rolle bleiben wollen oder ob sie in eine Rolle der Organisationsentwicklung wechseln wollen. In jedem Fall müssen die meisten Manager/Führungskräfte anpassen, was sie selbst tun und wie sie es tun, d.h. die meisten müssen durch eine persönliche agile Leader Journey gehen.

Basierend unserer Erfahrung ist es wirklich hilfreich, ein Modell zu haben, das dir hilft, deine persönliche Reise systematisch zu strukturieren und sie Schritt für Schritt mit Hilfe eines großartigen Coaches zu gehen. Wenn du mehr darüber erfahren möchtest, wie das gehen kann, dann schau dir unsere Certified Agile Leadership Trainings an.