"Scaled Agile" bedeutet, dass eine Organisation agile Arbeitsweisen bzw. Methoden in mehreren ihrer Teams oder Bereiche einführt. Das kann z.B. notwendig sein, weil Projekte zu groß bzw. Produkte zu komplex werden, um von einem Team alleine bearbeitet zu werden. In einer solchen Organisation haben zuvor zumindest einzelne Teams erste Erfahrungen mit agilen Arbeitsweisen und Methoden gesammelt.
"Scaled Agile" bedeutet, dass eine Organisation agile Arbeitsweisen bzw. Methoden in mehreren ihrer Teams oder Bereiche einführt. Das kann z.B. notwendig sein, weil Projekte zu groß bzw. Produkte zu komplex werden, um von einem Team alleine bearbeitet zu werden. In einer solchen Organisation haben zuvor zumindest einzelne Teams erste Erfahrungen mit agilen Arbeitsweisen und Methoden gesammelt.
Prinzipiell bedeutet "Skalierung" das Verändern der Größe, (verkleinern oder vergrößern). Der Begriff leitet sich vom italienischen Wort "scalae" ab, was Treppe bedeutet. Skaliert werden können z.B. Schrift- und Bildgrößen oder Software-Lösungen, z.B. eine Datenbank, die bei wenigen Anfragen genauso gut und schnell funktioniert wie bei vielen Requests. Ein Geschäftsmodell ist skalierbar, wenn das Unternehmen seinen Umsatz steigern kann, ohne seine Fixkosten zu erhöhen und in den Ausbau seiner Infrastruktur investieren zu müssen, was häufig für internetbasierte Geschäftsideen gilt.
Scaled Agile beginnt da, wo mehr als ein agil arbeitendes Team zur Auslieferung eines Produkts benötigt wird. Daraus folgt, dass das Team Abstimmungsprozesse auf verschiedenen Ebenen benötigt (z.B. mit anderen Teams oder Abteilungen), um an den Kunden etwas auszuliefern, es kann seine Entscheidungen also nicht mehr autonom treffen. Zur Koordinierung und Synchronisierung der Arbeit ist es besser, wenn idealerweise die gesamte Organisation agil arbeitet, statt dass "agile Insel" bestehen (z.B. in der Produktentwicklung).
Agile Skalierung ist eine große Herausforderung. Im Zuge dessen müssen Abhängigkeiten minimiert werden, damit die Teams autonomer agieren können. Zudem sollte der Zeitpunkt zum Skalieren gut gewählt sein, damit die Organisation die damit einhergehenden Veränderungen bewältigen kann.
Vereinfacht gesagt geht es bei Scaled Agile darum, die agilen Werte und Prinzipien auf der Ebene der Organisation umzusetzen, und diese Kulturveränderung durch geeignete Prozesse, Methoden und Artefakte zu unterstützen, wie Meeting-Formate (z.B. aus der Holokratie) oder Methoden zur Zielerreichung wie OKR.
Organisationen die diesen Change angehen wollen, haben zwar bereits erste Erfahrungen mit agilen Methoden und Arbeitsweisen gesammelt, allerdings gilt dies nur für einen (oft kleinen) Teil der Belegschaft. Eine agile Skalierung funktioniert also ähnlich wie eine agile Transition, da das agile Mindset noch von der Mehrheit der Menschen verstanden und verinnerlicht werden muss.
Arbeitet die gesamte Organisation agil, kann sie die bereits agil arbeitende Produktentwicklung ideal unterstützen. Die Teams können dann weiterhin weitgehend autonom Entscheidungen treffen und die Kundenbedürfnisse rasch befriedigen. Arbeiten mehrere Teams an einem Produkt, bietet ein agiles Framework Abläufe zur Abstimmung unter den Teams. Zudem kennen agile Organisationen ihre Kunden allgemein besser und entwickeln für diese passgenauer Produkte, entwickeln bestehende rascher weiter und entscheiden in der Regel schneller und besser.
Viele Organisationen folgen dem agilen Trend und planen eine umfassende Agilisierung, ohne dass diese benötigt und/oder auf breiter Front gewünscht ist. Jede Organisation sollte sich daher zunächst fragen: Welche Herausforderungen und Dysfunktionalitäten haben wir in der aktuellen Organisationsstruktur und in unseren Prozessen, die wir durch die Einführung eines Skalierungsframeworks lösen wollen. Mit den Antworten auf diese Frage kann dann ein geeignetes Skalierungsframework ausgewählt oder ein eigenes entwickelt werden.
Mittlerweile gibt es eine Vielzahl von Frameworks für Scaled Agile. Verbreitete Skalierungsframeworks sind Scrum of Scrums (SoS), Large Scale Scrum (LeSS), The Scaled Agile Framework® (SAFe®), und das Spotify-Modell.
Das Scrum of Scrums Framework ist der erste strukturierte Ansatz zur Skalierung von Agilität der beiden Scrum-Erfinder Jeff Sutherland und Ken Schwaber. Der Scrum of Scrum Ansatz eignet sich hauptsächlich für Kontexte, in denen zwei bis acht Teams gemeinsam ein größeres Produkt entwickeln. Die Arbeit dieser Teams wird anhand eines skalierten Daily Meetings geordnet, dem Scrum of Scrums-Meeting (SoS). Bei diesem SoS treffen sich Entsandte (in der Regel sind dies Teammitglieder) aus den verschiedenen Teams, um kontinuierlich Abhängigkeiten zu klären und eine gemeinsame Basis für die Zusammenarbeit zu schaffen.
Nexus ist ein Rahmenwerk zum Entwickeln und Betreiben von skalierten Produkt- und Softwareentwicklungsprojekten. Es verwendet Scrum als seinen Grundbaustein und gilt vielen als Weiterentwicklung des SoS. Drei bis neun Scrum Teams arbeiten gemeinsam an einem Produkt und teilen sich dazu ein Produktbacklog. Dadurch kommt es in der Regel zu diversen Abhängigkeiten, die sich in Reibungsverlusten, technischen Schulden und Qualitätsproblemen äußern.
Um diese Abhängigkeiten kümmert sich das Nexus Integration Team. Dieses Team besteht aus Scrum Master:in, Product Owner:in sowie jeweils mindestens einem Teammitglied aus den Entwicklungsteams. Das Integration Team dient als Schnittstelle zu den Entwicklungsteams. Der:die Scrum Master:in achtet darauf, dass die Nexus-Methodik beachtet wird. Der:die Product Owner:in pflegt das Backlog und kümmert sich darum, dass die richtigen Dinge entwickelt werden. Durch eine erhöhte Aufmerksamkeit gegenüber Abhängigkeiten sowie Risiken und Chancen der skalierten Zusammenarbeit soll es gelingen, in jedem Sprint zumindest ein integriertes fertiges Inkrement auszuliefern.
Scrum@Scale beschreibt ein Rahmenwerk innerhalb dessen ein ganzes Netzwerk von Scrum Teams (bis zu fünf Teams) oder sogar mehrere Netzwerke komplexe adaptive Aufgabenstellungen angehen kann, und das die Teams in die Lage versetzt, kundenorientierte und kreative Produkte auszuliefern. Der Ansatz setzt dazu auf eine skalierungsfreie Architektur, die sich durch eine minimal überlebensnotwendige Bürokratie auszeichnet. Scrum@Scale betrachtet den Scrum Guide als sein minimales Feature Set, an das sich die Teams konsequent halten. Dieser Minimalismus führt zu maximaler Flexibilität und radikaler Transparenz; beides steigert Innovativität, Kundenzufriedenheit, Leistungsfähigkeit und Teamzufriedenheit. Scrum@Scale verwendet zwei verschiedene Zyklen (SM Cycle und PO Cycle), die sich an den Stellen Product & Release Feedback, Metrics & Transparency und Team Level Processes überschneiden:
LeSS ist ein Rahmenwerk, das genau wie SoS stark auf Scrum als Prozessmodell aufbaut. Es eignet sich ebenfalls für zwei bis acht Teams und bietet für größere Vorhaben mit LeSS Huge eine skalierbare Lösung. LeSS setzt auf sogenannte Feature Teams – echte funktions- und komponentenübergreifende Full-Stack-Teams, die unabhängig voneinander Produktinkremente liefern können.
Eine Besonderheit ist das so genannte Multi-Team Scrum: Bei LeSS gibt es genau eine:n Product Owner:in, die:der mit Hilfe genau eines Product Backlogs genau ein Produkt verantwortet, welches von bis zu acht Teams geliefert wird. Diese Teams entwickeln das Produkt in einem Sprint gleichzeitig (iterativ und inkrementell). Am Ende jeder Iteration steht dann genau ein Potentially Shippable Product.
Für LeSS benötigen die Teammitglieder Erfahrung im agilen Arbeiten, zumindest auf der Teamebene. Bestehende agile Strukturen werden skaliert (z.B. Sprint Planning 1, Sprint Review und Overall Retrospective; diese finden mit allen Projektmitgliedern gleichzeitig statt).
SAFe® bietet einen strukturierten Ansatz zur Skalierung von Agilität, der sich an die eigenen Geschäftsanforderungen anpassen lässt und sich über die folgenden Ebenen erstreckt:
SAFe® ist das umfassendste Skalierungsframework und wird in der Regel in Konzernen und Kontexten mit vielen Teams und Personen (ab 100 Personen) eingesetzt.
Dieses Modell ist kein klassisches Skalierungs-Framework sondern lediglich eine Momentaufnahme aus dem skalierten agilen Unternehmensumfeld von Spotify aus dem Jahr 2012, welche dort durch konsequentes Verfolgen der vier Werte Autonomie, Kommunikation, Verantwortlichkeit und Qualität erreicht wurde. Mittlerweile entwickeln Unternehmen wie die ING DiBa das Modell weiter, entsprechend ihrer Anforderungen.
Der Fokus liegt auf der Kultur der Zusammenarbeit sowie darauf, wie eine ideale Aufbauorganisation für die agile Zusammenarbeit von Teams aussehen kann. Die einzelnen Teams (Squads genannt) entscheiden selbst, welche Meetings und Prozesse sie durchführen, um ihre Aufgaben bestmöglich zu erledigen.
Um sicherzustellen, dass die Squads gemeinsame Ziele verfolgen, organisieren sie sich in "Tribes" und "Guilds". Jeder Tribe besteht aus mehreren Squads und verfügt über einen "Tribe Lead" der dafür Sorge trägt, dass sich der Tribe gut mit den anderen Tribes abstimmt. Guilds dagegen sind lose organisierte Interessengruppen zu bestimmten Themen, die allen offenstehen; am ehesten sind Guilds vergleichbar mit Communities of Practices.
Soziokratie 3.0 kann gemäß seiner Erfinder (Bockelbrink, Priest und David) auf eine lange Geschichte beziehungsweise Denkschulen zurückblicken, darunter Soziokratie gemäß Boeke und Endenburg sowie Holakratie gemäß Robertson. Alle drei Ansätze sind nach vier Grundprinzipien strukturiert
Um diese Prinzipien anzuwenden, liefert Soziokratie 3.0 eine große Sammlung an Praktiken, die z.T. auch unabhängig voneinander angewendet werden können. Dazu gehört z.B. das Logbuch, die Domäne oder auch die Pfirsich-Organisation. Durch die Integration von Prinzipien aus Lean und Agile sind die Anwendungsmöglichkeiten sehr breit und deshalb auch interessant für die Anwendung in IT und Produktentwicklung.
Ein Nachteil ist, dass es wenig Anleitungen gibt, wie die Elemente zusammenpassen – hier hilft entweder ein Blick in den Praxisleitfaden oder die Begleitung durch eine Person, die die verschiedenen Elemente kennt. Eine weitere Hürde ist eine hohe Komplexität bei der Implementierung aufgrund der Vielzahl an Elementen.
Wie Sie einige der hier vorgestellten Frameworks für Ihre Teams und Anforderungen verwenden können, erfahren Sie im E-Book "Agil im Großen - Frameworks für den Wandel". Beiträge zur Produktentwicklung mit dem Large Scale Scrum-Framework (LeSS) und der Kombination aus LeSS und SAFe (Scaled Agile Framework) veranschaulichen detailliert, wie der Einsatz in der Praxis aussieht. Was die Führung zum hierfür notwendigen agilen Wandel beitragen kann, erfahren Sie im abschließenden Kapitel.
Agile Skalierungsframeworks beschreiben die Bausteine, die Organisationen benötigen, um als Gesamtorganisation agil arbeiten zu können, also schnell Entscheidungen zu treffen, synchron ein Produkt auszuliefern sowie dieses kontinuierlich zu verbessern.
Sie beruhen auf den agilen Werten und Prinzipien wie Offenheit, Mut und Commitment sowie den agilen Prinzipien wie das der kontinuierlichen Verbesserung.
Skalierungsframeworks müssen einer Organisation u.a. dabei helfen
Für die Auswahl eines für die eigene Organisation geeigneten Frameworks benötigen die Beteiligten und das Top-Management Grundkenntnisse über die verschiedenen Skalierungsframeworks.
Mittlerweile sprechen sich mehrere unserer Autoren für das Kombinieren mehrerer Frameworks aus, um eine maßgeschneiderte Lösung erstellen zu können, ähnlich wie die Kombination agiler und klassischer Methoden im hybriden Projektmanagement.
Einer dieser Autoren ist Dominik Maximini. Er setzt auf vier Lösungsprinzipen:
Auch außerhalb der IT-Entwicklung greifen diese Prinzipien und führen zu positiven Ergebnissen bei Scaled Agile.
Carsten Rasche und Konstantin Engeler stellen Ihnen in unserer Websession sechs Erfolgsfaktoren agiler Skalierung vor und zeigen, wie Sie mittels einer Framework-übergreifenden Toolbox ein Framework zusammenstellen, das auf die individuellen Ziele und Probleme Ihrer Organisation zugeschnitten ist.
Prinzipiell bedeutet "Skalierung" das Verändern der Größe, (verkleinern oder vergrößern).
Scaled Agile beginnt da, wo mehr als ein agil arbeitendes Team zur Auslieferung eines Produkts benötigt wird.
Arbeitet die gesamte Organisation agil, kann sie die Produktentwicklung ideal unterstützen. Die Teams können dann weiterhin weitgehend autonom Entscheidungen treffen und die Kundenbedürfnisse rasch befriedigen.
Agile Skalierungsframeworks beschreiben die Bausteine, die Organisationen benötigen, um als Gesamtorganisation agil arbeiten zu können, also schnell Entscheidungen zu treffen, synchron ein Produkt auszuliefern sowie dieses kontinuierlich zu verbessern.
Mittlerweile gibt es eine Vielzahl von Frameworks für Scaled Agile.
