PDF - Greenpaper Agile Skalierung

Agile Skalierung
Laut einer Umfrage von GULP werden in Zukunft Projekte zum größten Teil agil oder zumindest hybrid durchgeführt. Methoden wie Scrum und Kanban haben längst bewiesen, dass sie die Effektivität von Projekten deutlich steigern. Agile Methoden
sind jedoch per Definition für kleine Teams ausgelegt und haben den Ruf nur in kleinem Rahmen zum Erfolg zu führen.
Sobald die Aufgabenlast steigt oder die Anzahl der Teams wächst, stehen Unternehmen aber vor einer neuen Herausforderung:
Die Arbeit trotz steigender Komplexität nach wie vor so effizient wie möglich zu gestalten. Unterschiedliche Vorgehensmodelle bieten Lösungsansätze für eine agile Skalierung. Im diesem Paper werden die vier bekanntesten Modelle „Scrum of
Scrums“ (SoS), „Nexus“, „Large Scaled Scrum“ (LeSS) und „Scaled Agile Framework“ (SAFe) erläutert und verglichen.
Bevor mit der Skalierung von agilen Methoden begonnen werden kann, empfehlen wir, dass das Unternehmen zunächst einen
Kulturwandel hin zur Agilität bereits vollzogen und nachhaltig gezeigt hat, dass es auch in einem kleinen Rahmen agil arbeiten
kann. Die agile Kultur der Offenheit, Kundenorientierung und Kooperation kann durch Referenzprojekten ausgebreitet werden.
1.
WIE SIEHT EINE SKALIERUNG
THEORETISCH AUS?
Hat ein Unternehmen erste Erfahrungen
und Erfolge mit agilen Methoden wie
Scrum gemacht, gilt es das Erlernte im
Unternehmen weiter auszurollen und
das Arbeiten an Projekten mit mehr als
nur einem Team zu ermöglichen. Dies
kann auf zwei Skalierungsarten erfolgen: vertikal und horizontal.
Die horizontale Skalierung beschreibt
die Zusammensetzung der Teams in
Bezug zur Wertschöpfungskette. Bei
einer horizontalen Skalierung werden
also Teams aus Mitarbeitern unterschiedlicher Fachbereiche geformt um
interdisziplinär an Produkten zu arbeiten. Ein Entwicklerteam könnte durch
einen Spezialisten aus der Marketingabteilung ergänzt werden, damit sichergestellt ist, dass das Softwareprojekt stets mit der aktuellen Marketingstrategie konform ist. Je mehr Spezialisten aus unterschiedlichen Zuständigkeitsbereichen ein Team bilden,
desto komplexer wird das zielgerichtete
Management. Einerseits könnten interdisziplinäre Teams verantwortlich für
die Erstellung und Wartung von Software sein, andererseits könnten durch
solche Teams Aufgabenbereiche wie
Marktforschung, der Entwurf von Produkten und der Vertrieb dieser zusammengebracht, effizienter geregelt und
aufeinander abgestimmt werden.
Die vertikale Skalierung beschreibt die
Anzahl der Teams mit denselben Aufgabenbereichen bzw. Verantwortlichkeiten (z.B. Erstellung oder Wartung
von Software). Wenn von einem für die
Erstellung von Software verantwortlichen Team auf fünf Teams erhöht wird,
hat eine vertikale Skalierung stattgefunden.
2.
AGILE SKALIERUNGSARTEN
Die beiden Skalierungsarten bergen
Chancen und Risiken für ein Unternehmen. Besonders bei der horizontalen
Skalierung ist zu beachten, dass es nicht
immer sinnvoll ist, alle Mitarbeiter in
agilen Teams arbeiten zu lassen. Standardisierte Prozesse, bzw. Regelprozesse die keine Unsicherheiten bergen,
profitieren von der Agilität tendenziell
nicht, da kein Wissenstransfer notwendig ist und keine neuen Produkte entstehen.
Die Skalierung sollte stufenweise zu-
gleich vertikal als auch horizontal vorgenommen werden (siehe Abbildung
1), damit die Mitarbeiter sich an die
neue Arbeitsform gewöhnen können.
Steigt die Anzahl der Teams zu schnell,
sind Redundanzen in den Ergebnissen
auf der Unternehmensebene unvermeidbar. Wenn die Teams ohne zureichendes Coaching Mitglieder aller
Teile der Wertschöpfungskette zugewiesen bekommen, wird die Selbstorganisation nicht funktionieren.
Als Unterstützung und Leitfaden für
den Weg zum skalierten agilen Unternehmen gibt es mehrere Frameworks,
von denen im Folgenden vier vorgestellt werden. Die Detailinformationen
zu den Frameworks sind den offiziellen
Seiten der Frameworks zu entnehmen
(siehe Quellenverzeichnis).
Abbildung 1: Horizontale und vertikale Skalierung
Project Partners Management GmbH | Nördliche Münchner Straße 16 | D-82031 Grünwald
T: 089/ 62 00 95-70 | www.project-partners.de
3.
AGILE SKALIERUNGSFRAMEWORKS
3.1. SCRUM OF SCRUMS (SOS)
Scrum of Scrums ist eins der bekanntesten und vom Ansatz her einfachsten
Frameworks für die agile Skalierung.
Es wurde 2001 zum ersten Mal von einem der Gründerväter von Scrum Jeff
Sutherland vorgestellt und stellt ein
Pendant zum klassischen ProgrammManagement dar.
Wenn die typische Scrum-Teamgröße
von sieben +/- zwei Mitgliedern überschritten wird, so wird das ursprüngliche Team auf zwei neue Scrum-Teams
aufgeteilt. Das neue Team bekommt im
Idealfall einen eigenen Scrum-Master
und Product-Owner. Diese zwei Teams
arbeiten weiterhin an demselben Produkt, haben ein gemeinsames Product
Backlog und führen wie gewohnt Daily
Scrums durch. Das Prinzip von SoS
sieht vor, dass nach den Daily Scrums
der Teams ein „Scrum of Scrums Meeting“ stattfindet. In diesem Meeting
treffen sich ausgewählte Vertreter der
einzelnen Teams. Die Vertreter sind in
der Regel Scrum-Master, können aber
auch reguläre Teammitglieder sein und
abwechseln. Besprochen werden das
Product Backlog, der Fortschritt und
die Hindernisse der jeweiligen Teams.
Das Ziel ist ein Erfahrungsaustausch,
eine gemeinsame Lösungsfindung und
Abbildung 2: Scrum of Scrums
somit die Verhinderung von redundanter Arbeit. Entschlüsse und Einigungen
werden in einem gemeinsamen Backlog festgehalten. Die gewonnenen Erkenntnisse und Neuigkeiten werden anschließend in die Teams getragen.
SoS ist in der Hinsicht skalierbar, als
dass bei einer größeren Anzahl an
Teams die SoS Meetings mehrstufig
stattfinden können. Vertreter von SoSMeetings treffen sich mit Vertretern anderer SoS-Meetings in „Scrum of
Scrums of Scrums Meetings“ (siehe
Abbildung 2).
Zwar bietet diese Vorgehensweise wenig Overhead, die Koordination und
Übersichtlichkeit geht mit zunehmen-
der Anzahl an Teams bzw. SoS-Hierarchieebenen jedoch verloren.
3.2. NEXUS
Das Nexus Framework (siehe Abbildung 3) wurde vom Miterfinder des
Scrum Frameworks Ken Schwaber erstellt und im Jahr 2015 veröffentlicht.
Es beschreibt einen Lösungsansatz für
die Produktentwicklung mit drei bis
neun Scrum-Teams. Die Besonderheit
von Nexus ist das „Nexus Integration
Team“, welches aus einem Scrum Master, einem Product Owner und ausgewählten Scrum-Team Mitgliedern besteht. Dieses ist dafür verantwortlich,
die funktionalen Abhängigkeiten innerhalb des Product Backlogs für jedes
Abbildung 3: Das Nexus Framework (https://www.scrum.org/Resources/The-Nexus-Guide)
Project Partners Management GmbH | Nördliche Münchner Straße 16 | D-82031 Grünwald
T: 089/ 62 00 95-70 | www.project-partners.de
Scrum-Team zu identifizieren und zu
differenzieren, damit die Entwicklung
vollständig und ohne Redundanzen erfolgt. Das Nexus Integration Team fokussiert sich darauf, die Scrum-Teams
zu orchestrieren und diesen coachend
zur Seite zu stehen.
Der Prozessablauf beginnt mit der Zerlegung der Product Backlog Inhalte auf
möglichst granulare Teile mit einem
Fokus auf die Minimierung von Abhängigkeiten unter diesen (eine Service
Oriented Architecture ist an der Stelle
sinnvoll). Dabei wird vorab geplant,
welche Scrum-Teams welche Inhalte in
welcher Reihenfolge liefern könnten.
Danach werden im Nexus Sprint Planning die Aktivitäten aller Scrum-Teams
koordiniert. Dazu gehört die Zieldefinition, die Aufteilung der Aufgaben auf
die einzelnen Teams abhängig von ihrer
Beschaffenheit und ein gesondertes
Sprint Planning mit einem jeden
Scrum-Team. Im Nexus Sprint Backlog
werden die Sprint Backlogs der einzelnen Teams kombiniert und mit dem Fokus auf gegebene Abhängigkeiten visualisiert. Im Nexus Daily Scrum werden
Umsetzungsschwierigkeiten und Abhängigkeiten von Vertretern der einzelnen Scrum-Teams besprochen und
identifiziert. Neu entstandene Aufgaben werden den Backlogs der einzelnen
Scrum-Teams zugewiesen. An Stelle
eines Scrum-typischen Sprint Review
innerhalb einzelner Teams findet das
Review in einem „Nexus Sprint Review“ teamübergreifend statt. In der
„Nexus Sprint Retrospective“ werden
zunächst teamübergreifende Probleme
aufgedeckt, diese in den einzelnen
Teams besprochen und anschließend
Lösungsvorschläge auf Teamebene
vorgestellt.
Das Nexus Framework ist mit der starken Anlehnung an Scrum und der Beschränkung auf drei bis neun Teams für
kleine skalierte Projekte geeignet.
Abbildung 4: Prozessablauf von LeSS
2005 erschaffen und stetig weiterentwickelt wurde um Scrum um Funktionen
für die Skalierung zu erweitern. Das
Framework bietet einen Ansatz für kleinere skalierte Projekte mit bis zu zehn
Scrum Teams zu je sieben Team-Mitgliedern und einen Ansatz für eine beliebige Anzahl an Leuten, die an einem
Produkt arbeiten (LeSS Huge).
LeSS baut auf eigenen Prinzipien, Regeln und Richtlinien auf und versucht
Scrum zu bleiben, womit zum einen die
Einfachheit (More with LeSS) und der
geringe Overhead thematisiert werden,
als auch die Annahme, dass man für das
Skalieren von Scrum weiterhin auf
Scrum setzen sollte.
Dieser Ansatz bietet eine einfache
Struktur (siehe Abbildung 4), die aus
Scrum-Teams und einer Hierarchie aus
Product Ownern (PO) besteht, wobei
der Verantwortungsbereich eines PO
auf tieferen Hierachie-Ebenen kleiner
wird.
Im kleinen Rahmen haben Product Owner somit mehrere Scrum-Teams die an
dessen Backlog arbeiten.
Für den Skalierungseffekt im großen
Rahmen (LeSS Huge) werden Area
Product Owner (APO) eingeführt.
APOs sind einem regulären PO zugeordnet und verantworten Backlogelemente die spezifisch für deren Themengebiet sind (Area).
Teams werden durch Sprint Planning
Meetings koordiniert, wobei die Anzahl
derartiger Meetings mit der Hierarchietiefe skaliert. Abstimmungen zwischen
zwei Teams können der beiden zuständigen APO und dem PO bedürfen.
LeSS ist ein leichtgewichtiges und flexibles Framework, welches besonders
dafür geeignet ist die Anzahl an ScrumTeams im Unternehmen zu steigern.
LeSS kann mit einer beliebigen Unternehmensgröße praktiziert werden.
3.4. SCALED
(SAFE)
AGILE
FRAMEWORK
Das SAFe-Rahmenwerk besteht aus
drei Ebenen: Portfolio, Programm und
Team (siehe Abbildung 5). Die Portfolio-Ebene entscheidet über strategische
Themen, an denen gearbeitet werden
sollte, erstellt daraus Portfolio Epics
3.3. LARGE-SCALE SCRUM (LESS)
LeSS ist ein Framework, welches von
Bas Vodde und Craig Larman im Jahr
Abbildung 5: Aufbau von SAFe
Project Partners Management GmbH | Nördliche Münchner Straße 16 | D-82031 Grünwald
T: 089/ 62 00 95-70 | www.project-partners.de
(Zielvorgaben) und überträgt diese an
die Programm-Ebene. Auf der Programm-Ebene werden die Epics des
Portfolios weiter verfeinert und in einzelne Features aufgeteilt. Diese werden
Teams zugewiesen um Iterationenübergreifend Agile Release Trains zu
liefern. Release Trains umfassen alle
umgesetzte Funktionalitäten.
SAFe bringt ausformulierte Lösungsansätze auf prozessualer Ebene und eine
skalierungsfähige Aufbauorganisation
mit, die durch definierte Rollen eine
hohe Zahl an Teams koordinieren kann
und verschiedene Stakeholder und klassische Unternehmensbereiche einbindet. Auf der Team-Ebene unterscheidet
sich SAFe kaum vom Scrum-Ansatz,
welcher durch Extreme Programming
Methoden wie zum Beispiel Pair Programming erweitert wird.
Durch die feste Definition von Rollen
und Prozessen büßt SAFe an Flexibilität und somit Agilität ein. Jedoch macht
diese feste Strukturvorgabe des Frameworks die Transition zur Agilität für
Unternehmen einfacher. Die Strukturvorgabe stellt mit ihrer Vielzahl an Rollen eine Hürde für kleinere Unternehmen dar und macht das Framework
hauptsächlich für größere Projekte attraktiv.
4.
Abbildung 7 geht auf die zwei Dimensionen ein und stellt die vier vorgestellten Frameworks gegenüber. Die ermittelten Kriterien führen zu der Matrix in
Abbildung 6.
5.
FAZIT
Es gibt viele verschiedene Ansätze und
Frameworks für die agile Skalierung.
Die vier vorgestellten Frameworks basieren zwar alle auf Scrum, greifen den
Skalierungsgedanken jedoch auf unterschiedliche Art und Weisen auf.
SoS ist der leichtgewichtigste Ansatz,
mit hoher Flexibilität, jedoch mit einer
beschränkten Skalierungsgröße. Nexus
konzentriert sich darauf, dass Abhängigkeiten zwischen den Teams und im
Backlog stets transparent sind. LeSS ist
der Ansatz mit dem größtem Skalierungspotential für Unternehmen jeder
Größe und bietet einen besonderen Fokus auf die produzierten Produkte.
SAFe ist das vielseitigste der Skalierungsframeworks und eignet sich besonders für Großunternehmen. Durch
klare Organisations- und Prozessstrukturen wird die Transition zur skalierten
Agilität erleichtert.
Dennoch sind Frameworks wie der
Name bereits sagt nur Rahmen für Vorgehensweisen. Kein Unternehmen wird
sich eins zu eins an alle Regeln eines
Frameworks halten können. Frameworks liefern eine Vielzahl an tollen
einzigartigen Methoden und Lösungsansätzen für potentielle Skalierungsprobleme. Wie bei der ersten ScrumEinführung gibt es bei der Skalierung
für die Unternehmen viele Hürden zu
meistern und an diesen zu wachsen.
Aus diesem Grund folgt die Schlussfolgerung, dass Unternehmen aufgrund ihrer Individualität mit einem Standard
anfangen und diesen dann Schritt für
Schritt an sich anpassen sollten. Es
empfiehlt sich auf externe Expertise zurückzugreifen um die Auswahl und Implementierung eines Frameworks mit
dem nötigen Know-How vornehmen zu
können.
6.
WEITERFÜHRENDE LEKTÜRE
Falls Sie an näheren Informationen zum
Wandel hin zur Agilität interessiert
sind, empfehlen wir Ihnen einen Blick
in unsere Publikationen und folgende
Artikel in unserem Blog:




Agile Transition
Klassisch oder Agil?
Der Agile Projektleiter
Agiler Festpreis
VERGLEICH VON SOS, NEXUS,
LESS UND SAFE
Zwei Dimensionen sind für die Auswahl eines der vier Frameworks für ein
Unternehmen besonders geeignet: einerseits ist dies die Größe der Entwicklungsorganisation und andererseits die
Komplexität von Produkt und Markt.
Diese beiden Dimensionen sind Ausschlaggebend dafür, welchen Bedarf an
Steuerungs- und Kontrollmechanismen
es in der Aufbau- und Ablauforganisation gibt. Insbesondere gilt es auf die
Unterschiede in der Komplexität der
Frameworks zu achten. Dazu gehören
der Detailgrad der definierten Strukturen, der Umgang mit Komplexität und
die teamübergreifenden Koordinationsmechanismen.
Abbildung 6: Skalierungsframeworks
Project Partners Management GmbH | Nördliche Münchner Straße 16 | D-82031 Grünwald
T: 089/ 62 00 95-70 | www.project-partners.de
Abbildung 7: Vergleich von Skalierungsframeworks
Mittlerweile gibt es eine Vielzahl ähnlicher und dennoch unterschiedlicher
Rahmenwerke für die agile Skalierung.
Dazu gehören „Discipled Agile Delivery (DAD)”, „Spotify model“, „Drive
Strategy Deliver Mode (DSDM)”,
„Recipes for Agile Governance
(RAGE)”, „Scrum at Scale“, „EBM Agility Path“, „Comparative Agility“
und viele mehr.
Wollen auch Sie von den zahlreichen
Methoden profitieren und ihre Agilität auf das nächste Level bringen?
Sprechen Sie uns an! Von der Wahl
der richtigen Herangehensweise für
Ihr Unternehmen bis hin zur Durchführung eines agilen Pilot-Projektes
unterstützen Sie gerne die Project
Partners.
Ein Artikel von:
Alexander Zuchtmann, Marc Kordes,
Steffen Langer, Hendrik Schmitz,
Christoph Strauß
GREENPAPERS
sind Expertenpapiere von Project Partners, in denen wir
unsere Erfahrung speziell für IT Entscheider zusammenfassen.
Gerne stehen wir auch Ihnen bei ITProjekten mit Rat und Tat zur Seite.
www.project-partners.de
QUELLEN
 https://www.agilealliance.org/glossary/scrum-of-scrums/
 https://www.scrum.org/Resources/The-Nexus-Guide
 https://less.works/
 http://www.scaledagileframework.com/
 https://www.it-agile.de/wissen/agileskalierung-ueber-die-prinzipien/
 http://www.agilescaling.org/
 http://www.computerwoche.de/a/scrum-und-co-auch-agilemethoden-lassen-sich-skalieren,3219768
 https://www.gulp.de/knowledgebase/markt-und-trends/managementvon-it-engineering-projekten-die-zukunft-ist-hybrid.html
Project Partners Management GmbH | Nördliche Münchner Straße 16 | D-82031 Grünwald
T: 089/ 62 00 95-70 | www.project-partners.de

Download Report