Agile Skalierungsframeworks im Vergleich (Teil 1)
Viele Organisationen haben im Kontext der voranschreitenden Digitalisierung verstanden, dass sie sich agile Fähigkeiten aneignen müssen, um sich an eine sich schnell wandelnde Umwelt anzupassen und den Risiken der Digitalisierung, z. B. durch neue Marktteilnehmer, schnell wechselnde Kundenanforderungen oder neue Methoden der Leistungserstellung, zu begegnen. Neben der Abwehr von Risiken ermöglicht Agilität es Unternehmen aber auch, die Chancen der Digitalisierung zu nutzen, indem sie durch die Nutzung agiler Methoden externe Ressourcen effizienter und effektiver in die Wertschöpfung integrieren können. Agilität kann auf verschiedene Weisen im Unternehmen etabliert werden. In manchen Unternehmen, vor allem in Startups oder kleineren Organisationen, hat sich eine agile Arbeitsweise bereits auf natürliche Art und Weise in Prozessen und Strukturen etabliert, ohne dass es einer speziellen Formalisierung in Form von Methoden bedürfen würde. Andere Unternehmen jedoch, bei denen etablierte Strukturen und Prozesse eher dem klassischen Projektmanagement entspringen, benötigen jedoch Hilfestellungen in Form von agilen Methoden, um agile Fähigkeiten aufzubauen. Agile Methoden ermöglichen es Unternehmen, gewisse Strukturen und Prozesse so umzugestalten, dass der Produktentwicklungsprozess beschleunigt und/oder die Kommunikation und Kollaboration innerhalb der Unternehmung und nach aussen hin verbessert wird. Die meisten agilen Methoden beziehen sich dabei auf die Prinzipien und Werte, die im Agile Manifesto definiert wurden (vgl. Beck et al., 2001).
Nutzung agiler Methoden im Gesamtorganisationskontext
Es ist naheliegend, dass agile Methoden sich in der Softwareentwicklung zuerst etabliert haben, da es hierbei oftmals zu Veränderungen der Anforderungen des Nutzers kommt und die Entwicklungszyklen teilweise sehr schnell sind. (Den Unterschied zwischen den Methodenfamilien der agilen und klassischen Methoden und die Faktoren, die die Verwendung agiler Methoden begünstigen, könnt Ihr hier nachlesen). Die voranschreitende Digitalisierung und die damit einhergehenden Veränderungen erfassen jedoch immer mehr Bereiche im Unternehmen bis hin zur Gesamtstrategie. Ein Beispiel sind Ecosysteme, in denen mehrere Akteure gemeinsam Wertschöpfung betreiben. Die Offenheit eines solchen Wertschöpfungsnetzwerks für neue Marktteilnehmer und die Möglichkeit für Nutzer, verschiedene Angebote transparent zu vergleichen und ohne hohe Transaktionskosten zwischen verschiedenen Angeboten zu wechseln, führen zu einer Machtverschiebung und Emanzipation des Kunden. Die Konsequenz dieser Machtverschiebung ist, dass Angebote, die sich nicht schnell genug an eine veränderte Marktumgebung anpassen können und den Kundenbedarf nicht mehr hinreichend gut erfüllen, potentiell sehr schnell nicht mehr nachgefragt werden. Für Unternehmen bedeutet dies, dass sie die beiden Kernfähigkeiten von Agilität (nämlich die der Wahrnehmung der Veränderungen im Markt und der darauf basierenden adäquaten Anpassung von Ressourcen, Prozessen und Angeboten) auch über die Softwareentwicklung hinaus in weiten Teilen der Organisation etablieren müssen, um ihre Wettbewerbsfähigkeit zu erhalten und ganzheitliche, konsequent am Kundenbedürfnis ausgerichtete Angebote zu schaffen.
Viele agile Methoden jedoch sind auf die Arbeit in kleinen Teams ausgerichtet. Die Scrum-Methode zum Beispiel (vgl. https://www.scrum.org/resources/scrum-guide) präsentiert eine Vielzahl an Techniken und Aktivitäten für die Kollaboration in Gruppen von 8-12 Teilnehmern. Jedoch kennt die Scrum-Methode keine Mechanismen, um verschiedene Teams innerhalb eines Unternehmens miteinander abzustimmen und untereinander kommunizieren zu lassen. Das Product Backlog ist zwar an der iterativen Erstellung eines ganzheitlichen Produktes in Form von Inkrementen orientiert, jedoch gibt es keinen Mechanismus, der zwei Teams, die an einem System arbeiten, miteinander abstimmt. Auch die Verbindung zur Gesamtstrategie des Unternehmens wird nicht adressiert, was dazu führen kann, dass verschiedene Teams unkoordiniert an einer Gesamtlösung arbeiten bzw. nur selektiv ihre «Pet Projects» vorantreiben. Dies führt die Nutzung agiler Methoden ad absurdum, da diese das genau gegenteilige Ziel verfolgen und durch ein hohes Mass an Struktur die Effizienz und Effektivität bei der Entwicklung von Systemen verbessern sollen.
Durch die oben beschriebenen Probleme agiler Methoden hat sich die Beliebtheit von agilen Skalierungsframeworks erhöht. Agile Skalierungsframeworks zielen darauf ab, die Kollaboration zwischen verschiedenen Teams und somit die Nutzung agiler Prinzipien in der gesamten Organisation zu ermöglichen. Prominente Beispiele agiler Skalierungsframeworks sind SAFe, LeSS, Nexus, Crystal oder DAD. SAFe ist das international am meisten verwendete Framework (29 % der Nutzer agiler Skalierungsframeworks), gefolgt von intern erstellten Methoden (10 %). Den dritten Platz teilen sich LeSS und DAD (je 5 %) (vgl. VersionOne, 2018). In dieser zweiteiligen Serie konzentrieren wir uns auf den Vergleich der drei Skalierungsframeworks SAFe, LeSS und DAD. Der erste Teil beschäftigt sich mit SAFe, während der zweite Beitrag die Frameworks LeSS und DAD näher beleuchtet.
SAFe – Scaled Agile Framework (for Lean Enterprises)
Das Scaled Agile Framework (https://www.scaledagileframework.com/#) verbindet verschiedene agile Methoden, wie z. B. Scrum, DevOps, Kanban und XP, mit der Gedankenwelt des Lean Managements, weswegen neuere Versionen der Methode als «SAFe for Lean Enterprises» bezeichnet werden. SAFe kennt verschiedene Konfigurationen, die von der Kombination einzelner Teams in einen Agile Release Train (im sog. «Essential SAFe») bis hin zur Gesamtunternehmenssteuerung in Form von agilen Methoden in der sog. «Full SAFe»-Konfiguration reichen. Hierbei wird die Ablauforganisation von der Gesamtstrategie und Portfoliosicht bis zur Entwicklung von Lösungen auf Teamebene mithilfe von Strukturen, Prozessen und Techniken, Rollen, Aktivitäten und Tools modelliert. SAFe weist in dieser Hinsicht einen relativ hohen Grad an Formalisierung auf. Kernartefakte in SAFe sind der sog. Agile Release Train und die Solution Trains. Der Agile Release Train ist eine relativ stabile Einheit, die aus mehreren agilen Teams besteht und typischerweise 50-125 Mitglieder hat. Diese sind rund um die für die Organisation signifikanten «Value Streams» organisiert und zielen auf die Erstellung von Lösungen, die in der Gesamtheit für den Nutzer Wert generieren. Der Solution Train wiederum ist das organisatorische Konstrukt, in dem grosse und komplexe Lösungen erstellt werden, was die Koordination von mehreren Agile Release Trains notwendig macht. In einem Solution Train sind mehrere hundert oder gar tausend Personen organisiert – ggf. werden in dieses Konstrukt auch externe Supplier eingebunden, die notwendig sind, um eine komplexe Gesamtlösung zu liefern.
In diesem Beitrag haben wir uns mit dem am stärksten formalisierten Skalierungsframework SAFe beschäftigt. Im zweiten Teil der Serie „Agile Skalierungsframeworks im Vergleich“ wenden wir uns den weiteren international verbreiteten Skalierungsframeworks LeSS und DAD zu.
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/
Larman, C., & Vodde, B. (2017). Large-scale scrum: More with LeSS. Boston: Addison-Wesley.
Denning, S. (2019). Understanding Fake Agile. Retrieved May 27, 2019, from https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-fake-agile/#13205aa44bbe
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
