Agile Teams sorgen in den Unternehmen für Flexibilität und Innovationskraft. Damit in großen Unternehmen wegen der Vielzahl an solchen Teams nicht alles im Chaos versinkt, bieten sich Skalierungs-Frameworks wie der Scaled Agile Framework (SAFe) an. Diese sind einer Studie zufolge für den Großteil der Unternehmen jedoch noch unbekannt.
Bereits jedes zehnte Team arbeitete im Jahr 2020 mit agilen Methoden – und die meisten der Unternehmen möchten 2021 die Zahl ihrer agilen Teams nochmals deutlich erhöhen. Zu diesem Ergebnis kommt die Studie "Agile Transformation: Doing Agile versus Being Agile", für die das Marktforschungsunternehmen Lünendonk gut 200 große mittelständische Unternehmen und Konzerne befragte. Je höher die Zahl der agilen Teams, die an einem gemeinsamen Ziel arbeiten, desto mehr stoßen Arbeitgeber jedoch an ihre Grenzen, wenn sie diese bereichsübergreifend vernetzen möchten. Hierbei helfen können agile Skalierungs-Frameworks, die für den Großteil der Unternehmen laut der Analyse von Lünendonk jedoch noch weitestgehend unbekannt sind. Diese "Rahmengerüste" für Agilität stammen ursprünglich aus der Softwareentwicklung, jedoch können diese auch auf Unternehmen aus allen anderen Branchen übertragen werden.
Übersicht über agile Frameworks
Die beliebtesten agilen Methoden wie Scrum, Kanban und Design Thinking sind für einzelne und kleine Teams konzipiert. In großen Unternehmen mit großen Projektvorhaben steigt die Anzahl der Teams sowie die Abhängigkeiten zwischen ihnen. Wie gelingt es Unternehmen, die Arbeit der agilen Teams in beispielsweise IT, HR, Fachbereich, Management, Produktentwicklung, Legal und Finanzen miteinander zu verzahnen? Um diese Komplexität zu bewältigen, bieten skalierbare agile Frameworks wie der Scaled Agile Framework (SAFe) oder Large Scale Scrum einen Lösungsansatz. Sie ermöglichen es Unternehmen, Agilität bereichsübergreifend im großen Stil zu implementieren.
Scaled Agile Framework: Scrum-Teams mittels SAFe vernetzen
Im Jahr 2007 von Dean Leffingwell veröffentlicht, bietet SAFe eine Vorlage, mit der Unternehmen agile Methoden in allen Teams implementieren können. Das Konzept wurde mittlerweile mehrmals überarbeitet. In seiner Basisvariante setzt sich SAFe aus drei Ebenen zusammen: der Team-, Programm- und Portfolioebene.
SAFe: Teamebene und Programmebene
Auf der Teamebene arbeiten fünf bis neun Mitarbeiter mit der Scrum-Methode zusammen. Sie setzen Teilprodukte in sogenannten Sprints um (mehr zur agilen Scrum-Methode erfahren Sie hier). Der Product Owner hat die Verantwortung für die Teilprodukte von ein bis zwei Teams und unterstützt auf der Programmebene das Product Management.
Eine Stufe über der Teamebene fasst SAFe auf der Programmebene fünf bis zehn Teams mit insgesamt rund 50 bis 125 Mitgliedern in sogenannten "Agile Release Trains" (ART) zusammen. Die Trains richten die Teilprojekte der einzelnen Teams auf eine gemeinsame, langfristige Aufgabe beziehungsweise auf ein gemeinsames, sogenanntes "Programm" aus. Ein großes Unternehmen hat üblicherweise mehrere parallel laufende Programme mit zugehörigen Trains.
Rollen auf der Programmebene des Scaled Agile Frameworks
Die Schnittstelle zwischen Team- und Programmebene bildet der Product Manager. Dieser arbeitet eng mit den Kunden zusammen und gibt deren Anforderungen an die Product Owner der einzelnen Teams weiter. Diese brechen die Anforderungen für ihre Teams in sogenannte "Stories" herunter. Weitere Rollen auf der Programmebene sind:
- Der Release Train Engineer (RTE) versucht die Events und Prozesse zu optimieren und einfacher zu gestalten. Außerdem assistiert er den Teams in der Wertschöpfungskette.
- Der System Architect trägt die Verantwortung für die allumfassende Struktur des SAFe-Systems.
- Die Business Owner sind die Haupt-Stakeholder des ART und tragen die Verantwortung für den Output der jeweiligen Trains.
SAFe: Program Increment und PDCA-Zyklus
Der Zeitrahmen, in der der ART zusammenarbeitet, wird als Program Increment (PI) bezeichnet. Zum Auftakt legen die Teams gemeinsam in einer Planungssitzung fest, welche Teilverbesserungen ihres Produktes innerhalb des kommenden Zyklus umgesetzt werden sollen. Üblicherweise dauern eine Iteration acht bis zwölf Wochen, in denen die Trains versuchen, für einen Wertzuwachs des Produkts zu sorgen. Dieser sogenannte PDCA-Zyklus eines PI umfasst die Schritte "Projektplanung, Entwicklung, Prüfung und Anpassung" (Plan, Do, Check, Adjust).
Auf der Portfolioebene werden künftige Programme definiert
Die Portfolioebene beschäftigt sich mit strategischen Themen. Mitarbeiter, die mit dem Portfolio Management betraut sind, definieren die Programme für die Programm-Ebene und suchen Antworten auf die Fragen, wie Werte für das Unternehmen geschaffen und wo Ressourcen investiert werden sollen. Auf der Portfolioebene wird somit auch das Budget für jeden ART festgelegt.
Scaled Agile Framework: Optionale Large-Solution-Ebene
Unternehmen und Konzerne, in denen mehrere ARTs große Entwicklungsvorhaben realisieren, benötigen eine zusätzliche Steuerungsebene – die Large-Solution-Ebene. Die Mitglieder dieser Ebene koordinieren und synchronisieren die ARTs. Vor und nach den PI-Plannings finden auf der Large-Solution-Ebene sogenannten Pre- und Post-Plannings statt. Diese Ebene von SAFe berücksichtigt auch Einheiten, die organisatorisch nicht im Unternehmen angesiedelt sind, wie zum Beispiel Lieferanten und Kunden. Die Mitglieder der Large-Solution-Ebene nutzen Solution Backlogs und Solution Kanban (mehr zur agilen Kanban-Methode und deren Anwendung in HR erfahren Sie hier).
Vorteile und Nachteile von SAFe
Der Vorteil des Scaled Agile Frameworks besteht darin, dass er Unternehmen mit einer hohen Anzahl von voneinander abhängigen Teams aus unterschiedlichen Bereichen unterstützt, dauerhaft agil zu arbeiten. Über die Ebenen hinweg neigt SAFe jedoch zur Inflexibilität. Die zusätzlichen Rollen und Abhängigkeiten zwischen den vielen verschiedenen Ebenen sorgen für eine gewisse Starrheit. Diese steht zusammen mit der eher auf top-down ausgerichteten Vorgehensweise dem Grundgedanken von Agilität entgegen, möglichst flexibel zu sein und ohne Hierarchien auszukommen.
Weitere agile Frameworks: Large Scale Scrum (LeSS)
Wie SAFe bietet auch Large Scale Scrum (LeSS) ein Rahmenwerk, innerhalb dessen mehrere Scrum-Teams arbeiten. Der LeSS-Rahmen, der von Craig Larman and Bas Vodde entwickelt wurde, ist jedoch nicht ganz so weit gespannt und bietet sich deshalb auch für kleinere Unternehmen an: Der Framework eignet sich dafür, Produkte mit rund zwei bis acht Teams zu entwickeln. Für größere Unternehmen eignet sich dagegen der von LeSS abgeleitete Framework "LeSS Huge". Das Grundprinzip bei LeSS ist, Prozesse so einfach wie möglich zu halten, sprich mit kleinstmöglichem Aufwand mehrere parallel arbeitende Scrum-Teams zu koordinieren.
Wie bei der agilen Scrum-Methode auf Teamebene durchlaufen mehrere Scrum-Teams bei LeSS einen Iterationszyklus. Es gibt mehrere Scrum-Teams, aber insgesamt nur einem Product Owner und einen gemeinsamen Backlog. Der Product Owner erstellt zunächst einen Product Backlog. Dort sind die Anforderungen aus Kundensicht an das Produkt, unterteilt in Features, aufgelistet. Aus dieser Anforderungsliste erstellen die einzelnen Teams ihren eigenen Sprint-Backlog und realisieren diesen. Der Output der Sprints ist ein gemeinsames, sogenanntes PSPI ("Potentially Shippable Product Increment"). Die Scrum-Ereignisse "Sprint-Planning", "Sprint-Review" und "Sprint-Retrospektive" finden in allen Teams parallel statt.
Unterschied zwischen LeSS und der "einfachen" Scrum-Methode
Im Gegensatz zum "einfachen" Scrum-Prozess werden das Sprint Planning und die Retrospektive in zwei Teile aufgeteilt. Das Sprint Planning findet zunächst teamübergreifend mit Repräsentanten aus jedem Team statt, die überlegen, welche Features durch welche Teams umgesetzt werden sollen. In Teil zwei beschließen dann die einzelnen Teams "intern", wie sie diese im kommenden Sprint umsetzen wollen. Bei der Retrospektive ist es umgekehrt: Zunächst findet das Ereignis innerhalb der einzelnen Teams statt. Im zweiten Teil treffen sich schließlich Repräsentanten aus jedem Team, um zu schauen, an welche Stellen Aufgaben nicht erledigt werden können.
Beim "LeSS Huge", sprich wenn mehr als acht Teams an einem Product Backlog arbeiten, wird dieser in mehrere "Area Product Backlogs" unterteilt. Jeder "Area" werden acht Teams zugeordnet, außerdem erhält jeder Bereich einen eigenen "Area Product Owner".
Das könnte Sie auch interessieren: