Agile Skalierung – Voraussetzungen, Prinzipien & Frameworks

Wenn Du vor der Herausforderung stehst, mit mehreren Teams an ein und demselben Produkt zu arbeiten, führt an der agilen Skalierung kein Weg vorbei. Aber worauf solltest Du dabei achten und welche Möglichkeiten gibt es überhaupt?

In diesem Artikel erfährst Du mehr über die Voraussetzungen und Grundprinzipien, auf die Du achten solltest, bevor Du skalierst. Außerdem stelle ich Dir die gängigsten Frameworks zur Skalierung agiler Teams vor und verrate Dir außerdem, von welchen Ansätzen Du besser die Finger lassen solltest.

Bevor Du überlegst, welches Framework Du für die agile Skalierung Deiner Produktentwicklung nutzen möchtest, solltest Du darüber nachdenken, ob die Zeit dafür überhaupt schon reif ist. Generell gilt, dass Du immer so spät wie möglich skalieren solltest.

Ich möchte Dir das anhand eines kleinen Beispiels verdeutlichen.

Stell Dir vor, Du bist Trainer einer Fußball-Mannschaft, deren Ziel es natürlich ist, möglichst viele Tore zu schießen. Deine Mannschaft funktioniert aber noch nicht so richtig gut. Das heißt, sie ist überhaupt nicht eingespielt. Beispielsweise sind die Laufwege häufig nicht klar, sodass es immer wieder zu Fehlpässen kommt. Außerdem glänzen Deine Spieler nicht gerade durch herausragende Fitness. Es mangelt Deiner Mannschaft auch an Ausrüstung und dergleichen mehr.

Obendrein spielen Deine Spieler noch in anderen Teams, sodass Ihr immer wieder zu wenig Spieler habt. (Sowohl beim Training als auch bei einem echten Spiel.)

Manchmal kommt sogar jemand vorbei und nimmt Euch den Ball weg, weil er woanders gebraucht wird.

Du hast also eine Mannschaft, die überhaupt nicht gut funktioniert und die unter sehr schlechten Bedingungen spielen muss.

Würdest Du in diesem Fall zwei weitere Mannschaften aufstellen, um mehr Tore zu schießen?

Nein, würdest Du nicht. Weil Du dann drei nicht funktionierende Mannschaften hättest. Deine Probleme und Herausforderungen würden sich ebenfalls verdreifachen. Du hättest drei Mannschaften, die nicht eingespielt sind. Drei Mannschaften, bei denen Pässe nicht funktionieren. Und drei Mannschaften, denen Spieler, Ausrüstung und manchmal sogar der Ball fehlt.

Für die agile Skalierung gilt das Gleiche wie für das Fußballteam aus dem obigen Beispiel. Wenn Du ein agiles Team hast, das beispielsweise unter Abhängigkeiten leidet oder das derzeit (noch) nicht in der Lage ist, nach jedem Sprint wertvolle Software auszuliefern, dann multiplizierst Du durch eine zu frühe agile Skalierung Deine Probleme.

Auch wenn es vielleicht eigentlich selbstverständlich ist, möchte ich es trotzdem kurz erwähnen: Eine vernünftige agile Skalierung ist darauf ausgelegt, die Vorteile, die durch agile Teams entstehen, zu erhalten. Eine erfolgreiche Skalierung muss deshalb Mittel und Wege finden, die gemeinsame Arbeit vieler Teams an ein und demselben Produkt zu organisieren.

Der zweite Grundsatz, den Du bei der agilen Skalierung beherzigen solltest, ist: Autonomie schlägt Kollaboration.

Wenn mehrere Teams gemeinsam an einem einzigen Produkt arbeiten, dann kommt es schnell dazu, dass diese Teams (aus den verschiedensten Gründen) gemeinsam Probleme und Herausforderungen angehen. (Sehr oft werden sie dann leider auch noch von agilen Coaches und Scrum Mastern darin bestärkt.)

Aber dieses Vorgehen bringt letzten Endes mehr Nachteile als Vorteile mit sich.

Natürlich ist kollaboratives Arbeiten ein wichtiger Ansatz, um komplexe Probleme zu lösen. Allerdings sollte diese intensive Kommunikationsform in erster Linie innerhalb eines Teams stattfinden. Kommt es zu permanenter teamübergreifender Kollaboration, dann ist das ein Indiz dafür, dass das Team gar nicht dazu in der Lage ist, eine Aufgabe eigenständig zu bewältigen. (Es kann also gar nicht autonom und selbstorganisiert arbeiten.)

Die Folge davon sind Abhängigkeiten und Verzögerungen, weil ein Team immer auf die Hilfe eines anderen Teams angewiesen ist.

Team Topologies sind ein Denkansatz von Manuel Pais und Matthew Skelton, der Dir Dich dabei unterstützt, die Probleme, die durch teamübergreifende Kommunikation entstehen, zu vermeiden.

Er basiert auf vier unterschiedlichen Teamtypen und drei Interaktionsformen, mit deren Hilfe Du den Aufbau und die Zusammenarbeit Deiner Teams visualisieren und überdenken kannst.

Dabei sind die Interaktionsformen besonders wertvoll, weil sie Dich auf problematische, teamübergreifende Kommunikation aufmerksam machen.

Ein weiterer großer Vorteil von Team Topologies ist der, dass sie universal funktionieren und Dir keine agile Methode oder Framework wie Scrum oder Kanban vorschreiben.

Die meisten Frameworks, die sich mit der agilen Skalierung beschäftigen, legen dabei das Scrum Framework zugrunde. Das liegt natürlich vor allem daran, dass Scrum der verbreitetste Ansatz in der agilen Produktentwicklung ist.

Nexus wurde von Ken Schwaber entwickelt und ist von allen agilen Frameworks zur Skalierung von Scrum wahrscheinlich dasjenige, das den Kern von Scrum am besten bewahrt.

Mit dem Nexus Framework können 3 bis 9 Scrum Teams gemeinsam an einem Produkt arbeiten, ohne dass sich dabei für die einzelnen Teams allzu viel verändert.

Damit jedoch am Ende eines jeden Sprints ein nutzbares Inkrement entsteht, existiert eine zusätzliche Rolle (bzw. Verantwortung): Das Nexus Integration Team.

Das Nexus Integration Team (kurz NIT) besteht aus dem Product Owner, einem Scrum Master und einem weiteren Vertreter für jedes Scrum Team des Nexus.

Gemeinsam ist es ihre Hauptaufgabe dafür zu sorgen, dass am Ende des gemeinsamen Sprints ein integriertes Inkrement entsteht.

Large-Scale Scrum (kurz LeSS) wurde im Jahr 2005 von Craig Larman und Bas Vodde entwickelt. Das Framework besitzt sehr viele Ähnlichkeiten und Gemeinsamkeiten mit Nexus und ist für die Zusammenarbeit von 2 bis 8 Teams ausgelegt. Für noch größere Projekte bzw. Produkte existiert darüber hinaus eine Erweiterung des Frameworks namens LeSS Huge.

Genau wie bei Nexus Scrum existiert auch in LeSS weiterhin nur ein Product Owner und ein Product Backlog. Außerdem ist die Definition of Done natürlich weiterhin für alle Teams gültig, die Teil von LeSS sind.

Allerdings gibt es auch kleinere und größere Unterschiede im Vergleich mit Nexus Scrum. Der wohl größte Unterschied ist das bereits erwähnte Nexus Integration Team, das im LeSS Framework kein adäquates Pendant besitzt.

Generell lässt sich sagen, dass das LeSS Framework im Vergleich zu Nexus sehr viel detaillierter ausgestaltet ist.

LeSS ist zwar immer noch sehr offen, folgt jedoch einem logischen Aufbau von Principles, Frameworks, Guides & Experiments. Dieser Aufbau bietet Dir bei Deiner eigenen agilen Skalierung deutlich mehr Orientierung als Nexus. Denn Nexus gibt Dir (wie Scrum) lediglich einen 10-seitigen Guide an die Hand.

Während Ken Schwaber die agile Skalierung von Scrum durch Nexus entwickelte, erschuf der zweite Scrum-Urvater Jeff Sutherland einen Ansatz, der sich Scrum@Scale nennt. Auch wenn dieses Framework einige interessante Ansätze besitzt, wird das Scrum Framework (im Vergleich zu Nexus bzw. LeSS) stark erweitert.

Beispielsweise werden in Scrum@Scale die Rollen des Chief Product Owners und des Scrum of Scrums Masters eingeführt.

Eine weitere Besonderheit dieses Skalierungs-Frameworks sind der Scrum Master Cycle und der Product Owner Cycle.

Neben den oben genannten Frameworks zur agilen Skalierung kursieren leider auch einige Modelle und Ansätze, die Dir letzten Endes mehr schaden als helfen werden. Dazu zählen beispielsweise das Spotify-Modell, das relativ junge unFIX-Modell von Jurgen Appelo und auch das SAFe Framework.

2014 stellte Henrik Kniberg vor, wie zu diesem Zeitpunkt die Softwareentwicklung bei Spotify organisiert war.

Obwohl er darauf hinwies, dass es niemals als Vorlage für andere Unternehmen gedacht war, sorgte sein Vortrag für Furore und ist seitdem auch als Spotify-Modell bekannt.

Doch wenngleich darin einige sehr gute und hilfreiche Ansätze zu finden sind, besitzt das Spotify-Modell manche blinde Flecken und Probleme, die es für Deine eigene agile Skalierung zumindest bedenklich (wenn nicht gar unbrauchbar) machen.

Seit einiger Zeit geistert auch das sogenannte unFIX-Modell von Jurgen Appelo durch den digitalen Äther.

unFIX bedient sich großzügig verschiedenster Elemente aus anderen Frameworks und Ansätzen und verquirlt das Ganze dann zu einem halbgaren Baukastensystem.

Damit kannst Du Dir dann jede erdenkliche Organisationsstruktur zusammenbasteln, die Dir vorschwebt. Ohne Dir allerdings klare Prinzipien an die Hand zu geben, ob die agile Skalierung, die Du Dir ausgedacht hast, wirklich sinnvoll ist oder gar in der Praxis funktioniert.

Auch wenn das Scaled Agile Framework (kurz SAFe) einen beeindruckenden Marktanteil von 40 Prozent besitzt und quasi der Platzhirsch unter den Skalierungs-Frameworks ist, solltest Du meiner Ansicht nach die Finger davon lassen.

SAFe erzeugt eher einen „verbesserten Wasserfall“ als eine (schlechte) agile Skalierung.

Es gibt mittlerweile viele Erkenntnisse, dass das Framework sein Versprechen, Organisationen agiler zu machen, nicht einhalten kann. Vielmehr sorgt SAFe dafür, dass alles noch langsamer und komplizierter wird.

Zusammenfassend lässt sich festhalten, dass über das Thema agile Skalierung das letzte Wort noch nicht gesprochen ist. Das lässt sich schon alleine daran erkennen, dass mit SAFe der am „wenigsten agile“ Ansatz derzeit die größte Verbreitung findet. Daneben existieren einige vielsprechende Ansätze, die jedoch ebenfalls noch keinen durchschlagenden Erfolg verbuchen konnten und miteinander konkurrieren.

Der wichtigste Schritt in die Richtung einer wirklich funktionierenden, agilen Skalierung  ist sicherlich erst vor einigen Jahren mit den Team Topologies von Skelton & Pais erfolgt. Es bleibt abzuwarten, wie sich das Thema in den nächsten Jahren entwickeln.