Es gibt verschiedene Frameworks, mit denen sich agile Arbeitsweisen und Frameworks skalieren lassen. Agile Skalierung wird notwendig, wenn mehrere Teams an einem Produkt arbeiten sollen. Hierdurch steigt die Bedeutung der Abstimmung zwischen den Teams und den Produktteilbereichen. Im allgemeinen gibt es mehrere Frameworks für die verschiedenen Formen von agiler Skalierung.

Welche agilen Skalierungsframeworks gibt es?

Die fünf wohl bekanntesten Skalierungsframeworks sind:

• Scaled Agile Framework (SAFe)

• Large-Scale Scrum (LeSS)

• Nexus

• Scrum@Scale

• Scaling Agile ("Spotify Modell")

Horizontale und vertikale Skalierung agiler Unternehmen

Sobald Unternehmen von einzelnen agilen Projekten oder Produkten zu einer ganzheitlichen agilen Arbeitsweise transformieren, wird in den meisten Fällen eine Form der Skalierung nötig, damit das selbstbestimmte Arbeiten in den Teams auch organisationsübergreifend funktionieren kann.
Hier unterscheidet man in der Regel zwischen horizontaler und vertikaler Skalierung.

Die vertikale Skalierung findet statt, wenn sich die agile Arbeitsweise innerhalb einer Wertschöpfungskette des Unternehmens verbreitet. Meistens ist dies zumindest beim Beginn der agilen Transformation der Fall. Hier startet die Arbeit mit agilen Methoden und Frameworks z.B. in einem Software-Team und breitet sich von dort auf andere Software Teams aus. Agiles Arbeiten findet bei dieser Form der Skalierung aber nur innerhalb der Softwareentwicklung statt und ist somit vertikal.

Bei der horizontalen Skalierung findet die Verbreitung agiler Arbeitsweisen auch in anderen Teams und Bereichen des Unternehmen statt. Dies können zunächst technische Bereiche sein, aber auch Sales, Marketing, HR oder User Experience und Design können die agile Arbeitsweise annehmen und somit die agile Skalierung horizontal vorantreiben.

Wie funktioniert eine Skalierung mit Large-Scale Scrum (LeSS)?

Erfunden wurde LeSS von agile100 Speaker Bas Vodde (die Aufnahme seiner "Geschichte von LeSS" gibt es im Wissensbereich) und Craig Larman. LeSS basiert auf der Annahme, dass maximal acht Scrum Teams an einem Produkt arbeiten und es einen Product Owner für alle Teams sowie ein gemeinsames Produkt Backlog gibt.
Die Idee hinter dem Large-Scale Scrum ist, dass die Teams durch die gemeinsamen Rituale ein hohes Maß an Vertrauen und Transparenz untereinander haben. Informations-Silos werden genauso verhindert wie doppelte Arbeiten. Zudem erhöht die gemeinsame Arbeit an demselben Produkt, dass die Teams Verantwortung für das Gesamtergebnis und nicht nur einen Teil übernehmen.

Aufgrund der Struktur und der Reduzierung von redundanten Rollen erschafft LeSS (englisch für weniger) bei der Skalierung eine neue Organisationsstruktur, die allerdings nur funktionieren kann, wenn die notwendigen Fach- und Führungskräfte bereits Erfahrung mit agiler Arbeitsweise und vor allem der agilen Führung gemacht haben. Wie generell bei der agilen Transformation ändert sich sowohl die Art der Führung als auch der Anspruch an die Führungspersonen. Je besser diese sich bereits in agilen Managementmetoden auskennen, desto besser.

Trainings zu LeSS kannst du in unseren Deep Dives finden.

Exkurs: Agile Führung und Organisationsentwicklung

Die Rolle der Führungskräfte ändert sich durch die selbstorganisation agiler Teams beträchtlich. Dies ist sicherlich auch der Grund, warum die meisten Unternehmen schon bei der Einführung von Scrum oder anderen agilen Frameworks auf Hersuaforderungen treffen.
Grundlegend für alle agilen Frameworks und festgehalten im agilen Manifest ist die selbstorganisation der Teams unumgänglich. Bei der Umsetzung sind aber neben den historisch bedingten Managementformen vor allem die Art und Weise der Selbstorganisation wichtig. Nicht jedes Team ist in derselben Form organisiert und strukturiert (vgl. Selbstorganisierte Teams - so klappt's im Wissensbereich).

Führungskräftetraining, damit die agile Transformation funktionieren kann!

Die Rolle des Managements oder C-Levels wird im Scrum Guide nicht aufgegriffen oder beschrieben. Daher wird diese Rolle der agilen Führungskraft gerne außer Acht gelassen. Damit du dich aber auch als Führungskraft mit agilen Managementmethoden und der beginnenden Selbstorganisation deiner Teams bei der agilen Skalierung vertraut machen kannst, empfehlen wir dir die Teilnahme der kostenlosen Info Events zum Thema Agile Führung, oder die Zertifizierung als agile Führungskraft durch ein Certified Agile Leadership Training.

Wie skaliert man mit dem Scaled Agile Framework (SAFe)?

Das Scaled Agile Framework (SAFe) wurde von Dean Leffingwell entwickelt. Mittlerweile gibt es verschiedene Ausführungen und Konfigurationen von SAFe, die vor allem auf die drei Ebenen: Team, Portfolio und Programm ausgelegt sind. Stellenweise wird aber auch hier als vierte Ebene die Gesamtorganisation oder auch der Wertstrom mit eingebunden.

Im Rahmen von SAFe ist vor allem das Wort "ART" (Agile Release Train) von Bedeutung. Beim Scaled Agile Framework werden die Teams bzw. die Arbeit skaliert, indem das Produkt inkrementell über den Agile Release Train ausgeliefert wird. Hierdurch ergeben sich in SAFe auch leichte Abwandlungen der aus Scrum bekannten Rollen. So spricht man bei SAFe eher von Programmmanager, Release-Train Engineer und Systemarchitekt.
Zudem nutzt SAFe mehrere agile Frameworks für die Skalierung. Oftmals findet neben Scrum auch Kanban oder Lean Development eine Anwendung bei der Skalierung mit SAFe. Dies führt dazu, dass das Framework bei unsachgemäßer anwendung schnell unübersichtlich werden kann und man ggfs. Überschneidungen von Teams übersieht. Durch die verschiedenen Ebenen und Konfigurationsformen, ist bei SAFe eher eine Auswahl passender Methoden, die zum Unternehmen passen wichtig.

Was ist Nexus?

Nexus ist das dritte der bekanntesten Skalierungsframeworks. Es wurde von Ken Schwaber, dem Gründer von scrum.org entwickelt und dient zur Entwicklung einzelner Produkte, also eher der vertikalen Skalierung. Genau wie bei LeSS dient das Framework vor allem der Skalierung auf drei bis neun Scrum Teams und basiert auch auf einem gemeinsamen Produkt Backlog.
Allerdings erweitert Schwaber bei Nexus die Anzahl der Rollen, Meetings und Artefakte sowie der Verantwortlichkeiten einzelner Teammitglieder. So ist bei Nexus das NIT, das Nexus Integration Team, vor, welches aus dem Product Owner, dem Scrum Master und einzelnen Teamvertretern zusammengestellt ist.

Das Nexus Integration Team ist dabei variabel und wird je nach Anwendungsfall bzw. Integrationshürde und zu suchender Lösung neu zusammengestellt. Hierdurch gewinnen die Koordinierungsmeetings, die als offizielles Event dieser Skalierungsart zählen, an Bedeutung (vgl. den Nexus Guide auf Scrum.org).

Zusätzlich zur Rolle des NIT gibt es noch Erweiterungen bzw. Ergänzungen zu den aus Scrum bekannten Events und Artefakten wie "(Nexus) Sprint Backlog", "(Nexus) Sprint Goal", "(Nexus) Sprint Planning", "(Nexus) Daily Scrum", "(Nexus) Sprint Review" und "(Nexus) Sprint Retrospektive"). Die Abläufe und Bedeutungen sind denen aus dem Scrum Framework sehr ähnlich. Meistens werden die Meetings aufgeteilt und angereichert. So besteht das "Nexus Sprint Planning" zum Beispiel aus zwei Schritten bzw. Meetings. Zunächst trifft sich das gesamte Nexus Team zum Planning. Ziel dieses Meetings ist es vor allem mögliche Abhängigkeiten zwischen den Teams zu klären und zu dokumentieren. Anschließend findet das aus dem Scrum Framework bekannte klassische Sprint Planning im Team statt.
Bei der Retrospektive sind in Nexus sogar drei Schritte vorgesehen: Zunächst trifft sich das NIT mit dem Product Owner und Scrum Master. Anschließend trifft sich jedes Scrum Team zur klassischen Scrum Retrospektive und am Ende werden die Ergebnisse dieser Retrospektiven vom NIT im dritten Schritt zusammengetragen.

Was ist Scrum@Scale?

Scrum@Scale stammt mit Jeff Sutherland von einem der Erfinder von Scrum. Die Skalierung funktioniert hier nicht, wie bei den meisten anderen Frameworks durch feste Rollen oder vordefinierte Strukturen der Teams, sondern durch die lose Vernetzung aller SCrum Teams.
Der Fokus von Scrum@Scale liegt vor allem auf der Trennung der Verantwortung, wie sie schon in den Rollen des Scrum Guide definiert ist. Die Zuständigkeiten des "WAS" und des "WIE" werden konsequent voneinander getrennt und dadurch ohne entstehende Konflikte skalierbar.

Dies führt bei Scrum@Scale zu zwei Zyklen, welche die Verantwortung für das "WAS" (der Product Owner Zyklus) und das "WIE" (der Scrum Master Zyklus) aufteilen und an zwei Stellen vernetzen. Dem Team-Level Prozess und dem Produkt-/Release-Feedback. Zudem basiert Scrum@Scale auf einer wertebasierten Kultur, die empirisches Arbeiten forciert und Selbstorganisation sowie Transparenz und Working Agreements in den Fokus rückt.

Koordination findet bei dem "WIE" durch den Scrum Master und das Scrum of Scrums statt. Die Product Owner agieren als Team und koordinieren sich dabei selbstständig und durch die Abstimmung mit den Stakeholdern.

Der Scrum@Scale Guide gibt zudem genaue Beschreibungen der Arbeitsweisen mit dem Scrum of Scrums und innerhalb des Product Owner Teams. Empfehlungen zur Durchführung von Scrum of Scrums Meetings gibt es von unserem agilen Experten Mike Cohn im Wissensbereich der Agile Academy.

Skalierung mit Hilfe des Scaling Agile @ Spotify Ansatzes

Bereits im Oktober 2012 beschrieben agile100 Speaker und Produktexperte Henrik Kniberg, sowie sein damaliger Spotify-Kollege Anders Ivarsson, wie der Streamingdienst innerhalb kürzester Zeit agil skalieren konnte. Die Methode mit Tribes, Squads, Chapters und Guilds ist seitdem massenhaft kopiert, aber nie erreicht worden. Ein Grund hierfür ist, dass es DAS Spotify Modell so gar nicht gibt. Vielmehr beschrieben die beiden damals, wie es das schnell wachsende Startup geschafft hat innerhalb kürzester Zeit in der Produktentwicklung zu skalieren.

Wie von Henrik Kniberg selbst im Wissensbereich beschrieben, baut das System auf verschiedenen Ideen auf, die einer gewissen Kontrolle unterliegen. Dies sind neben den "Squad Health Check Modell") die Entwicklerkultur zur Softwareentwicklung und auch die generelle Unternehmenskultur (vgl. "Agile bei Spotify").
Die Besonderheiten bei Spotify und somit auch der Skalierung durch diesen Ansatz waren neben dem Produkt und der einheitlichen Technik im Unternehmen vor allem die kulturellen Faktoren. Experimentierfreude (die Henrik Kniberg mittlerweile bei Mojang Studios bzw. Minecraft u.a. in die Releasesteuerung einfließen lässt).