Agile Skalierungsframeworks im Vergleich (Teil 2)

Veränderungen in der Unternehmensumwelt erkennen und zeitnah darauf reagieren, indem die einzelnen Bestandteile des Geschäftsmodells, wie z. B. das Wertversprechen, die Ressourcen oder die Prozesse, an die neuen Gegebenheiten angepasst werden – das ist der Grundgedanke von Agilität. Die Fähigkeiten, die dafür notwendig sind, müssen viele Unternehmen allerdings erst aufbauen. Für ein Unternehmen, das traditionell mit klassischen Methoden des Projektmanagements arbeitet, kann schon die Umstellung im kleinen Rahmen für einzelne Teams eine Herausforderung darstellen. Ungleich schwieriger wird es, wenn das Unternehmensumfeld die organisationsweite Einführung agiler Methoden erfordert, nicht zuletzt, da die ersten agilen Methoden, wie z. B. Scrum, die Kollaboration über verschiedene agile Teams hinweg gar nicht adressieren. Um agile Methoden dennoch über die gesamte Unternehmung hinweg einsetzen zu können, wurden seither mehrere sogenannte agile Skalierungsframeworks entwickelt, die genau diese teamübergreifende Kollaboration ermöglichen. Im ersten Teil des Beitrags «Agile Skalierungsframeworks im Vergleich» haben wir das Framework SAFe betrachtet, in diesem Teil stellen wir nun die Frameworks DAD und LeSS vor.

DAD – Disciplined Agile Delivery
Abbildung 1: DAD Agile Lifecycle, Quelle: https://disciplinedagiledelivery.com/introduction-to-dad/ (Die anderen Konfigurationen können ebenfalls dem oben aufgeführten Link entnommen werden)

Bei DAD geht es massgeblich um die korrekte Anwendung unterschiedlicher agiler und klassischer Methoden in Abhängigkeit von einer spezifischen Situation. DAD ist dabei ein hybrider Ansatz, der Scrum um bewährte Strategien aus Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development und verschiedenen anderen Methoden erweitert. DAD betrachtet auch die Gesamtorganisationsebene und verfolgt das Ziel der Erschaffung von Agilität auf verschiedenen Organisationsebenen. Die Herausforderung, der durch DAD begegnet werden soll, liegt in der oftmals undisziplinierten Nutzung agiler Methoden – DAD strebt folglich eine disziplinierte und strukturierte Art der Nutzung von agilen Methoden an. Grundsätzlich geht DAD davon aus, dass den meisten Teams nicht mit einer vollständigen, detaillierten Planung der Abläufe geholfen ist. Entgegen des durchformalisierten Frameworks von SAFe wird daher ein Framework propagiert, welches ein gewisses Mass an Flexibilität aufweist, um an die jeweilige Unternehmenssituation angepasst werden zu können. DAD zeigt dabei Ansätze für die disziplinierte Nutzung agiler Methoden in vielerlei Hinsicht. So gibt es den DAD Delivery Lifecycle für den gesamten Produktlebenszyklus (vom Konzept bis zum Retirement einer Lösung) oder Methodenbausteine für spezifischere Problemstellungen, wie z. B. den DAD Agile Lifecycle (für die agile Lösungsentwicklung), den DAD Lean Lifecycle (für die Lean-Management-basierte Lösungsentwicklung), DAD Continuous Delivery (mit Fokus auf die Umsetzungsphase) oder den DAD Exploratory Life Cycle (mit Fokus auf die Konzept- und Ideengenerierung sowie deren Evaluation). Im DAD Agile Lifecycle gibt es beispielsweise drei übergeordnete Phasen. In Phase 1 (Inception) werden in einem oder mehreren kurzen Iterationen relevante Projekte identifiziert, modelliert und priorisiert. In Phase 2 (Construction) werden die priorisierten Projekte in Form von Items in mehreren Iterationen bearbeitet, wobei Working Systems entstehen. In Phase 3 (Transition) werden die jeweiligen Inkremente in die Produktion überführt und dort weiter betreut. Ziel hierbei ist es, das Feedback aus der Produktion wieder in Phase 2 zurückzuspielen.

LeSS – Large Scale Scrum

Abbildung 2: Why LeSS Framework, Quelle:  https://less.works/

Ein weiterer Vertreter agiler Skalierungsframeworks, der eine hohe Verbreitung geniesst, ist das LeSS-Framework. LeSS ist im Gegensatz zu SAFe durch seine explizit unformalisierte, d. h. eher prinzipien-basierte, Art gekennzeichnet. Der Leitspruch dieser Methode lautet daher auch «LeSS is more», was einen Hinweis auf den Kerngedanken der Methode darstellt. Die Autoren spielen dabei auf die Relevanz der Selbstorganisation im Team an, die für den Aufbau agiler Fähigkeiten notwendig ist. Die LeSS-Methode konzentriert sich daher auch sehr stark auf den kulturellen Aspekt der Skalierung von agilen Strukturen in Organisationen. Ausgehend von der Scrum-Methode wurden im LeSS-Framework nur einige wenige Rollen, Aktivitäten und Techniken eingeführt, die allerdings allesamt an die Scrum-Methode angelehnt sind. In der kleineren der beiden LeSS-Konfigurationen ist ein Product Owner z. B. schlichtweg für mehrere Teams verantwortlich, die sich aus einem gemeinsamem Product Backlog ihre Aufgaben für den kommenden Sprint ziehen. Während des Sprints gibt es zusätzlich noch verschiedene Koordinations- und Abstimmungsaktivitäten zwischen einzelnen Vertretern der Teams, wodurch gewährleistet werden soll, dass alle Teams abgestimmt an der Gesamtlösung arbeiten. Am Ende eines jeden Sprints gibt es dann einen gemeinsamen Review und einen gemeinsamen Retrospective sowie ein Big Room Planning für die Planung der nächsten Iteration. In der grösseren Konfiguration LeSS Huge (mehr als 8 Teams) gibt es zusätzlich noch die Rolle des Area Product Owners, der zwischen Product Owner und Teams agiert und die Koordination und Verteilung der Aufgaben in die einzelnen Teams unterstützt. Die Mechanismen für die Abstimmung bleiben innerhalb einer «Area» gleich wie in der kleineren LeSS-Konfiguration.

Abbildung 3: LeSS Huge, Quelle: https://less.works/

Kritik

Kritik an den Skalierungsframeworks basiert vor allem darauf, dass sie den Kern einer agilen Organisation durch zu viel Struktur unterminieren (vgl. z. B. die ausführliche Kritik von Steven Denning im Forbes Magazin). Hierin liegt allerdings ein weit verbreitetes Missverständnis agiler Methoden: Agilität bedeutet nicht, dass Unternehmen ohne jegliche Struktur und Guidance Lösungen entwickeln, sondern vielmehr das genaue Gegenteil. Oftmals werden agile Methoden dann missbraucht, wenn das Entwicklungsteam orientierungs- und ideenlos ist oder vom Management keine klare Richtung vorgegeben bekommt. In solchen Konstellationen liefern agile Methoden, skaliert oder nicht, oftmals sehr unbefriedigende Ergebnisse. Skalierungsframeworks per se sind also nicht als anti-agil zu verstehen, sondern dienen vielmehr der Strukturierung und der gemeinsamen Ausrichtung unterschiedlicher agiler Teams (dies ist kein Widerspruch!).

Zusammenfassung

Im Vergleich zwischen den verschiedenen agilen Skalierungsframeworks zeigen sich massgebliche Unterschiede. SAFe ist sehr stark formalisiert und beschreibt den Ablauf der Lösungserstellung sehr detailliert. Es bietet daher, abgesehen von den einzelnen Konfigurationen, eher wenig Raum für Anpassung an den Bedarf einer Organisation. Zudem ist SAFe sehr stark auf die Lieferorganisation fokussiert und beschreibt nicht, wie Ideen generiert und in den Lieferprozess der Lösungsumsetzung überführt werden können. DAD zeigt einen hybriden Ansatz mit mehreren agilen Methoden und ist weniger formalisiert als SAFe. DAD verfolgt eine ganzheitliche Sicht auf das Unternehmen und betrachtet den gesamten Lebenszyklus von Lösungen von der Idee bis zur Termination. DAD zeigt jedoch nur sehr undetailliert, wie der Ablauf einer Organisation, die nach den DAD-Prinzipien agiert, aussehen kann. LeSS ist das Framework, welches am stärksten auf das Thema Prinzipien und Kultur fokussiert. Dabei werden bei LeSS so gut wie keine Beschreibungen geliefert, wie die Lösungserstellung organisiert werden soll. Wie dargestellt wurde, haben die verschiedenen agilen Skalierungsframeworks unterschiedliche Foki und sollten entsprechend der Zielstellung und des gewünschten Anwendungsbereichs verwendet werden. Jedoch gilt auch bei den Skalierungsframeworks, dass diese nur als Referenzmodelle zu betrachten sind und an die entsprechende Situation im Unternehmen angepasst werden sollten. Zu diesem Zweck haben wir im zweiten Workshop die Agile Toolbox vorgestellt, die verschiedene Techniken aus agilen Methoden und Skalierungsframeworks enthält. Bis zum nächsten Workshop im September wollen wir auf dieser Basis situativ angepasste Referenzmodelle bauen, die entsprechend der Projekt- und Kontexttypen im Unternehmen angewendet werden können.

Quellen

Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., … Jeffries, R. (2001). Manifesto for Agile Software Development. Retrieved January 4, 2019, from https://agilemanifesto.org/

Denning, S. (2019). Understanding Fake Agile. Retrieved May 27, 2019, from https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#13205aa44bbe

Larman, C., & Vodde, B. (2017). Large-scale scrum: More with LeSS. Boston: Addison-Wesley.

Mathis, C., & Leffingwell, D. (2018). SAFe – Das Scaled Agile Framework. Lean und Agile in grossen Unternehmen skalieren. Christoph Mathis, mit einem Geleitwort von Dean Leffingwell. (2. Auflage). Heidelberg: dpunkt.verlag.

Sutherland, J., & Schwaber, K. (2013). The Scrum Guide: The definitive guide to scrum: The rules of the game. Retrieved May 27, 2019, from https://www.scrum.org/resources/scrum-guide

Daniel Proba

Daniel Proba ist als Doktorand am CC Sourcing tätig, wo er sich mit der Transformation von Geschäftsmodellen im Zuge der Digitalisierung und Bankgeschäftsmodellen im Kontext von Smart Cities beschäftigt. Während seines Masters an der Universität Mannheim befasste er sich schwerpunktmässig mit den Themen Entrepreneurship, Innovationsmanagement und Banking & Finance. Außerdem absolvierte Daniel jeweils ein Gastsemester an der Auckland University of Technology in Neuseeland und der UE in Breslau, Polen, wo er sich mit den Themen Entrepreneurship, Change-Management und IT Management befasste.
Daniel Proba

Kommentar verfassen