A wie Agiles Reifegradmodell

„Nicht die größten Unternehmen werden überleben, sondern die anpassungsfähigsten“ – Joe Kaeser

„Nicht die Großen fressen die Kleinen, sondern die Schnellen überholen die Langsamen.“ – Eberhard von Kuenheim

Diese beiden Zitate der ehemaligen Top-Manager sind zeitgemäßer denn je. Unternehmen müssen dynamisch auf sich schnell ändernde Kundenanforderungen reagieren können, um so langfristig erfolgreich zu sein. Insbesondere die Produktentwicklung ist hierbei ein entscheidendes Vehikel.

Traditionelle Projektmanagement-Methoden, wie bspw. wasserfallartiges Vorgehen werden den Anforderungen nicht mehr gerecht.¹ Agile Methoden werden dabei in der Software- und Produktentwicklung als effiziente Alternative gesehen, um auf die Komplexität und die sich ändernden Anforderungen in kurzer Zeit reagieren zu können. Im Bereich der Softwareentwicklung gehören sie bei vielen Unternehmen bereits zum Standard bzw. gelten als Best Practices. Für den Bereich der Hardwareentwicklung hingegen sind agile Methoden noch recht wenig verbreitet, was auch daran liegt, dass sie ursprünglich für die Softwareentwicklung konzipiert wurden.² Mittlerweile wollen immer mehr Unternehmen agile Ansätze in der Systementwicklung für die Software- und Hardwareentwicklung verwenden, die sich kontinuierlich synchronisieren müssen. Eine Frage dabei lautet: Wie lässt sich Agilität in einer hardwarenahen Produkt- bzw. Systementwicklung adaptieren?³ Eine Antwort darauf liefert dieser Blogbeitrag.

Agile Entwicklung

Aus den agilen Werten und Prinzipien entstanden viele verschiedene Methodiken und Praktiken zur agilen Entwicklung.⁴ Innerhalb der Softwareentwicklung gilt Scrum heute als Standard für die Entwicklung neuer Softwareprodukte.⁵

Der Einsatz von agilen Praktiken ermöglicht Veränderungen durch das Generieren von Kundenwert. Diese Veränderungen werden beispielsweise mithilfe von Iterationen, welche auf Kundenfeedback basieren oder durch evolutionäre Anforderungen erreicht.⁶ Dailys oder Pair Programming fördern den Wissensaustausch.⁷ Grundsätzlich wird Agilität mit dem Agilen Manifest sowie mit den Attributen

• Flexibilität,
• Lernbereitschaft,
• Geschwindigkeit,
• arbeiten auf selbstorganisatorischer Teambasis,
• iterativ-inkrementeller Entwicklung,
• taktbasiertem Arbeiten mit vielen Auslieferungen und
• Wille zur kontinuierlichen Verbesserung innerhalb der Organisation

assoziiert.⁸

Agilität in der Hardwareentwicklung

Das Agile Manifest wurde vor dem Hintergrund der Herausforderungen in der Softwareentwicklung geschrieben. Diese “Einschränkung” ist in der Beschreibung und auch in den Werten zu erkennen.⁹ Die Entwicklung von Hardware unterscheidet sich jedoch in Teilen von der Softwareentwicklung. Für die Entwicklung von Hardware kann das Manifest dementsprechend nicht eins zu eins verwendet werden, wenngleich es als Inspiration dient. Aus diesem Grund haben sich ca. 30 Experten im Jahr 2016 auf dem ersten „Scrum for Hardware Gathering“ zusammengefunden. Das Ziel war es die Unterschiede zwischen Scrum in der Software- und der Hardwareentwicklung herauszuarbeiten und aufbauend darauf Werte zu definieren, welche für die Entwicklung von Hardware herangezogen werden können. Das Ergebnis ist das „Agile Product Charter“, das im Folgenden beschrieben ist.¹⁰

“We embrace agile methods as the engine driving innovative solutions and collaboration to amplify economic, ecologic and social benefits across our planet. Through this work we have come to value:

1. Cross functional team collaboration over specialization, process and tools.
2. Modularity over tightly-coupled solutions.
3. Continuous customer collaboration over inflexible contracts.
4. Useful continuous delivery over a single comprehensive delivery.
5. Extending development through manufacturing over fixing problems in the field.
6. Useful continuous documentation over comprehensive documentation.

That is, while there is value in the items on the right, we value the items on the left more.” ¹¹

Beim Vergleich mit dem Agilen Manifest können einige Änderungen festgestellt werden. Der erste Wert aus dem Agile Product Charter hebt die abteilungsübergreifende Zusammenarbeit und das Thema Spezialisierung hervor. Insbesondere im Bereich Hardware ist die Entwicklung durch mehrere Abteilungen beeinflusst. Neben der Entwicklung sind beispielsweise auch der Einkauf und die Produktion stark mit in die Produktentwicklung eingebunden. Eine Arbeitsweise wird unterstützt, bei der mehrere Leute die gleichen Aufgaben ausführen können. Der Wandel von einer Spezialisierung hin zu einem Generalisierung wird betont. Die Modularisierung wird im Agile Product Charter ebenfalls unterstrichen, so dass mehrere Module innerhalb der Produktentwicklung entkoppelt voneinander entwickelt werden können.

Ein weiterer Punkt ist die Ausweitung der Entwicklung über die Fertigung hinaus. Hiermit kann in der Produktentwicklung der Blick auf die gesamte Wertschöpfungskette erweitert werden. Speziell im Hardwarebereich ist dieser Blick hilfreich. Bemerkenswert ist, dass die Schwerpunkte Dokumentation und kontinuierliche Auslieferung etwas angepasst wurden. Dies ist ebenfalls bei der Entwicklung von Hardware notwendig, da bspw. Dokumentationen aus rechtlicher Sicht erforderlich sind.

Skalierung agiler Entwicklung

Mit der Ausweitung des Wissens über agile Methoden in der Praxis ist der Wunsch bei vielen Unternehmen gewachsen, Agilität für große Entwicklungsprojekte, den gesamten Entwicklungszyklus und in ganzen Organisationen zu implementieren.¹²

Wenn große Entwicklungsprojekte agil bearbeitet werden sollen, d. h. mehrere Teams an einem Produkt arbeiten, ist eine Skalierung notwendig, welche die Synchronisierung der einzelnen Teams regelt. Bei der Synchronisierung ist es für eine Unternehmung, die sowohl Software als auch Hardware entwickelt, entscheidend auch die Hardwareentwicklung mit in diesen Entwicklungszyklus einzubinden.¹³ Skalierungsframeworks, welche auch diese Integration regeln, wurden entwickelt und werden heute bereits in vielen Unternehmen genutzt.

Zu den am meisten verwendeten Ansätzen gehören in der Praxis das Scaled Agile Framework (SAFe) und das Large Scale Scrum (LeSS). Auch die Erfahrungen, die Spotify im Zuge von Skalierung nutzt, findet hohe Anwendung in der Praxis.¹⁴

Nachfolgend legen wir den Fokus auf die Skalierung mit SAFe. Es bietet für traditionelle Unternehmen eine gute Starthilfe, besitzt eine klare Struktur, beachtet Wertströme und ermöglicht eine kontinuierliche Weiterentwicklung.¹⁵

SAFe ist ein Rahmenwerk, welches dafür entworfen wurde, unternehmensweite Agilität zu schaffen und dabei Methoden aus den Bereichen Lean, agil sowie DevOps zu verwenden. Es wurde im Jahr 2011 erstmals vorgestellt und seitdem mehrfach weiterentwickelt. Die aktuelle Version SAFe 5 stammt aus dem Jahr 2020.¹⁶

In SAFe 5 gibt es vier verschiedene Implementierungslevel: Full SAFe, Portfolio SAFe, Large Solution SAFe und Essential SAFe.¹⁷ Die einzelnen Implementierungslevel in SAFe setzen sich aus mehreren Rollen und Methoden zusammen:

• Im Essential SAFe bildet der Agile Release Train (ART), welcher aus mehreren agilen Teams besteht, das Zentrum dieses Levels. Die Rollen in diesem Level teilen sich zum einen in das agile Team, welches operativ am Produkt arbeitet und zum anderen in den ART im Allgemeinen. Im agilen Team wird zwischen Scrum Master, Product Owner und dem Entwicklungsteam unterschieden. Der ART besteht aus mehreren agilen Teams, Produktmanager, System Architekt/Ingenieur, Release Train Engineer (RTE) und einem Business Owner. Im Zuge des Essential SAFe werden u.a. Aktivitäten wie ein Programm Increment (PI) Planning oder ein Scrum of Scrums durchgeführt, damit sich die Teams untereinander besser synchronisieren können.¹⁸
• Beim Large Solution SAFe wird das Konzept des ART auf mehrere ARTs ausgeweitet. Um die Koordination dieser ARTs sicherzustellen, werden drei neue Rollen eingeführt: Solution Architect/Engineer, Solution Management und der Solution Train Engineer. Die Haupttätigkeiten sind hierbei das Pre- und Post-PI-Planning.¹⁹
• Auf dem Level Portfolio SAFe wird ein Lean Portfolio Management eingeführt, um die Strategie der Organisation mit den Investments und den restlichen Ressourcen zu lenken.²⁰

SAFe wird wie das Agile Manifest über Werte und Prinzipien definiert²¹, die nachfolgend für die Entwicklung eines Modells herangezogen werden.

Unterscheidung zwischen Werten, Prinzipien, Methodik und Praktiken

Besonders die Unterscheidung zwischen Werten, Prinzipien, Methodiken und Praktiken/Methoden ist für das Verständnis wichtig. Die Unterscheidung wird in der nachfolgenden Abbildung detaillierter beschrieben:

Abbildung 1: Differenzierung zwischen Werten, Prinzipien, Methodiken und Praktiken²²

Werte stellen die kraftvollste Art und Weise dar, agil zu sein, allerdings auch die am wenigsten sichtbare. Sie bilden im Zuge der agilen Adaption die Grundpfeiler. Praktiken hingegen sind am sichtbarsten, weisen jedoch den geringsten Nutzen auf, weil sie zumeist Lösungen für einzelne Probleme darstellen.

Agile Reifegradmodelle

Der Wille von Unternehmen agile Methoden zu implementieren, ist im letzten Jahrzehnt angestiegen. Ein häufig anzutreffendes Problem bei der Adaption von agilen Methoden ist die Identifikation darüber, wie agil das Unternehmen bereits ist und wie agil es werden möchte bzw. kann. Diese Probleme führten zu dem Bedürfnis, Wege zu finden, die Unternehmen beim Adaptieren von Methoden unterstützen sollten. Strukturierte Ansätze wie beispielsweise Reifegradmodelle zielen darauf ab, Unternehmen bei ihrer agilen Transformation zu begleiten. Sie bieten umfassende Anleitungen für die Verwendung von Prozessen, zeigen Roadmaps für die Implementierung auf und beschreiben, was agil im Kern bedeutet.²³

In der Literatur gibt es zahlreiche Reifegradmodelle, welche u.a. von Ozcan-Top und Demirors untersucht und bewertet wurden. Das Agile Adoption Framework (AAF) von Sidky wurde bspw. für eine Anwendung in der Praxis empfohlen, da es besonders in den Kategorien Definition der Reifegrade, Konsistenz und inhaltliche Richtigkeit überzeugt. Zusätzlich wird von Sidky die Wichtigkeit der agilen Werte und Prinzipien in den Mittelpunkt des Modells gestellt. Aufbauend darauf wurden Praktiken definiert, welche dabei helfen, die Werte und Prinzipien zu unterstützen.²⁴ Das Reifegradmodell von Sidky bezieht sich allerdings auf die Softwareentwicklung, weshalb im Folgenden aufbauend auf dem AFF eine Weiterentwicklung vorgestellt wird. Diese Weiterentwicklung beinhaltet dementsprechend sowohl Skalierungs- als auch Hardwareaspekte.

Ein weiterentwickeltes, agiles Reifegradmodell

Das weiterentwickelte Reifegradmodell soll Unternehmen bei der Adaption von Agilität unterstützen. Zum einen werden sinnvoll aufeinander aufbauende Schritte (Reifegrade) aufgezeigt, welche ein Unternehmen bei Ausweitung der Agilität gehen kann, und zum anderen werden Empfehlungen gegeben, welche Praktiken dabei helfen, diese Stufen zu erreichen.

Die Struktur des zu entwickelnden Reifegradmodells basiert, wie die des AAFs auf den agilen Werten und Prinzipien. Damit die Fokussierung auf den Softwarebereich aufgelöst werden kann, werden sowohl die Werte aus dem Agile Product Charter, SAFe und Scrum verwendet. Ebenfalls erfolgt eine Ausweitung der Prinzipien um die SAFe Prinzipien. Durch die Einbindung dieser Werte und Prinzipien soll die Gültigkeit des Modells auf Hardware bzw. nicht Softwareentwicklung sowie Skalierungsaspekte ausgeweitet werden. Der Aufbau des Modells ist wie folgt:

Abbildung 2: Aufbau des Reifegradmodells²⁵

Die Beziehung zwischen den Werten bzw. Stufen und den Prinzipien kann hierbei mithilfe der Analogie „Slicing the cake“ beschrieben werden, die auch für das Teilen von User Storys verwendet wird. Ein vollständig agiler Entwicklungsprozess wird hierbei mit einer Torte, die mehrere Schichten hat, verglichen. Dabei stellt jede Schicht ein Prinzip dar. Die einzelnen Stücke der Torte zeigen die Reifegrade. Um nun sicherzustellen, dass jedes Tortenstück (agiler Reifegrad) die Essenz der gesamten Torte (Agilität) beinhaltet, müssen alle Schichten der Torte (agile Prinzipien) in jedem Stück präsent sein.²⁶

Abbildung 3: Analogie „Slicing the Cake”

Dieses Konzept wurde auch bei der Konzeptionierung des AAFs verwendet. Damit jede Stufe im Reifegradmodell die agile Charakteristik beinhaltet, wurde in jeder Stufe versucht, so viele Prinzipien wie möglich zu berücksichtigen. Die Zusammensetzung mit den Praktiken orientiert sich an dem Umfang der Einhaltung dieser Prinzipien je Stufe. Jede Stufe verwendet die agilen Prinzipien für unterschiedliche Zwecke, je nachdem welcher Wert bzw. welche Werte durch die Stufe beschrieben sind.²⁷

Der Gedanke, der hinter der Betrachtung aller agilen Prinzipien pro Stufe steht, ist, dass ein Unternehmen bei der Adaptierung eines agilen Reifegrades nicht nur einen Aspekt der Agilität implementieren soll. Diese Vorgehensweise an sich würde nicht agil sein, sondern vielmehr einem Wasserfallvorgehen ähneln, indem das gesamte Produkt (Agilität) erst am Ende des gesamten Prozesses fertig ist. In einem inkrementellen Ansatz liegt nach jeder Iteration ein auslieferungsfähiges Produkt vor, welches in diesem Fall ein „Tortenstück“ wäre, das alle Prinzipien berücksichtigt.²⁸

Clusterung der Werte und Prinzipien

Die Verwendung aller Werte und Prinzipien würde das Reifegradmodell unnötig kompliziert bzw. unübersichtlich machen und eine Umsetzung in der Praxis wäre schwieriger darstellbar. Aus diesem Grund wurden die 17 Werte und 22 Prinzipien aus dem Agilen Manifest, dem Agile Product Charter, Scrum und SAFe betrachtet sowie nach Vorlage des AAFs eine Gruppierung der Werte und Prinzipien vorgenommen. Durch die Gruppierung können so alle Werte und Prinzipien im Reifegradmodell berücksichtigt werden. Nach dieser Betrachtung und Gruppierung konnten das Modell auf fünf Werte (Reifegrade) und fünf Prinzipien festgelegt werden.

Abbildung 4: Die fünf agilen Reifegrade²⁹

Im Zuge der ersten Stufe „Kollaborativ“ des Reifegradmodells wird die Basis für die agile Arbeitsweise geschaffen, indem die Themen Kommunikation und Zusammenarbeit gefördert werden. Innerhalb der zweiten Stufe „Evolutionär“ wird gemäß dem Wert „Useful continuous delivery over a single comprehensive delivery“ aus dem „Agile Product Charter“ der inkrementelle und evolutionäre Ansatz näher beleuchtet. Aufbauend auf einem Minimum Viable Product (MVP) soll das Produkt entwickelt werden. Insbesondere geht es in dieser Stufe darum, einen zeitlichen Rhythmus in den Entwicklungsprozess zu bringen, der eine kontinuierliche Auslieferung fördert. Nach der Einführung dieser Arbeitsweise wird die Steigerung der Effizienz in der dritten Ausbaustufe „Effizienz“ thematisiert. Dabei konzentrieren sich Teams in dieser Stufe auf das Entwickeln von funktionierenden Lösungen unter Betrachtung eines hohen Qualitätsanspruchs und einer kontinuierlichen Verbesserung. Stufe vier „Adaptiv“ stellt die Zusammenarbeit mit dem Kunden in den Vordergrund. Hierbei wird versucht im Rahmen einer verstärkten Zusammenarbeit auf dessen Wünsche während der laufenden Entwicklung zu reagieren. In der letzten Stufe des Reifegradmodells „Umfassend“ geht es für Unternehmen darum, eine nachhaltige Umwelt zu schaffen, welche die agile Arbeitsweise nachhaltig unterstützt. Besondere Beachtung findet hier die agile Führung und die kontinuierliche Ausrichtung auf den Kunden und den Markt.

Den zweiten Pfeiler des Reifegradmodells stellen die Prinzipien dar. Die Entwicklung und Zusammensetzung der Prinzipien ergibt sich durch die Clusterung der 22 Prinzipien aus dem Agilen Manifest und SAFe.

Im agilen Ansatz liegt der Fokus auf dem Mitarbeiter. Dementsprechend gibt es im Agilen Manifest und in SAFe insgesamt neun Prinzipien, welche diese Zentrierung fokussieren. Themen, die von diesen Prinzipien angesprochen werden, sind u.a.

• Kommunikation,
• intrinsische Mitarbeitermotivation oder
• motivierte Teams mit Entscheidungskompetenz.

Der agile Ansatz fördert die Entwicklung von Produkten in kleinen Schritten. So wird nicht einmal am Ende ein großes Produkt sondern mehrere kleinere Inkremente ausgeliefert, die jeweils einen Kundenwert haben. Damit lässt sich das Risiko reduzieren, dass ein Produkt oder eine Funktion ohne Kundennutzen entwickelt wird. Zudem lässt sich die Planbarkeit durch kürzere Zyklen und kontinuierliches Feedback verbessern. Diese Arbeitsweise wird im Agilen Manifest und in SAFe mit insgesamt neun Prinzipien hervorgehoben. Themen, die in diesen Prinzipien beschrieben werden, sind u.a.

• frühe und kontinuierliche Auslieferungen,
• Betrachtung/ Bewertung der Warteschlange,
• Feedback inklusive Lernzyklen,
• nachhaltige, konstante Entwicklungsgeschwindigkeit sowie
• Fortschrittsmessung an funktionierenden Inkrementen.

Die Entwicklung hoher Qualität durch den Blick auf das Produkt oder System ist sehr wichtig. So können unter diesem Punkt sieben Prinzipien aus dem Agilen Manifest und dem SAFe-Framework zusammengefasst werden. Die Themen, die behandelt werden, sind u.a.

• Einfachheit durch Standards,
• technische Excellence,
• Design,
• sicherstellen von Variabilität.

Der letzte Punkt wird auch bei den agilen Hardwarewerten unterstrichen und dort als Modularität beschrieben. Hierdurch bietet sich in der agilen Hardwareentwicklung die Möglichkeit, auf späte Änderungen in der Entwicklung besser reagieren zu können.

Der agile Ansatz fördert eine Entwicklung, welche darauf ausgerichtet ist, Wert für den Kunden zu erzeugen. Die Wichtigkeit über die Ausrichtung an den Kunden, aber auch an den Stakeholdern wird mit sieben Prinzipien beschrieben, u.a.

• Offenheit für Änderungen und
• enge Zusammenarbeit aller Beteiligten.

Wie bereits erwähnt, wurde der agile Ansatz insbesondere vor dem Hintergrund entwickelt, dass Anforderungen für ein Entwicklungsprojekt nicht immer vor Beginn eines Projekts feststehen. Anforderungen entwickeln sich im Zuge von Projekten und Änderungen auch in späten Projektphasen werden immer häufiger notwendig. So ist die Reaktion auf Änderungen in SAFe und im Agilen Manifest mit fünf Prinzipien explizit beschrieben, u.a.

• regelmäßige Reflexion im Team sowie
• visualisieren und begrenzen der konkreten Arbeiten.

Grundrahmen des Reifegradmodells

Aus der Beschreibung der Werte und Prinzipien ergibt sich für das Reifegradmodell folgender Rahmen:

Abbildung 6: Aufbau des Reifegradmodells

Es gibt verschiedene Praktiken, die Unternehmen dabei unterstützen, agiler zu arbeiten. Diese Praktiken sind dabei entweder neu entwickelte agile Praktiken oder solche, die von anderen Disziplinen übernommen wurden. In beiden Fällen werden nicht-agile Praktiken durch agile ersetzt, neu definiert oder ergänzt. Ein Beispiel stellen User Storys dar, die ein traditionelles Pflichtenheft ersetzen. Test Driven Development ergänzt traditionelle Entwicklungspraktiken. Ebenfalls ist das Pair Programming eine agile Praktik, die relativ weit verbreitet ist.³⁰

Diese Praktiken werden den definierten Prinzipien zugeordnet und in einem weiteren Schritt in einen Reifegrad eingeordnet:

Abbildung 7: Gruppierung der Prinzipien

Reifegradmodell und Anwendung

Im letzten Schritt werden die Praktiken zu den einzelnen Stufen zugeordnet. Das finale Reifegradmodell setzt sich folglich aus einer Kombination aller Ergebnisse zusammen und mündet im nachfolgenden Modell:

Abbildung 8: Finales Reifegradmodell

Die Anwendung des Reifegradmodells hat zwei übergeordnete Schritte. Zum einen muss der IST-Stand des Unternehmens oder des Projektteams ermittelt werden und darauf aufbauend wird ein Soll-Stand, unter Einbezug der vorgeschlagenen Praktiken aus dem Reifegradmodell, definiert.

Die Bewertung des IST-Stands kann mithilfe einer Selbstbewertung durchgeführt werden. Die Selbstbewertung ist auf einem Fragebogen aufgebaut, der jede Praktik bzw. das Ziel jeder Praktik mit mindestens einem Statement abfragt.

Die Abfrage bezieht sich auf die Häufigkeit der Anwendung. So wird festgestellt, ob eine Praktik systematisch angewendet wird. Des Weiteren kann es für die Implementierung von neuen Praktiken hilfreich sein zu wissen, ob gewisse Strukturen vorhanden sind, um auf diesen aufzubauen. Ein Beispiel hierfür stellt die Praktik User Storys dar, bei der es um die Beschreibungen von Anforderungen aus Nutzersicht geht. Hier könnte es beispielsweise sein, dass ein Unternehmen bereits definiert hat, was bei der Beschreibung von Anforderungen zu beachten ist. Diese Arbeitsanweisung bzw. dieser Prozess könnte bei der Implementierung als Grundlage verwendet werden. Neben einem reduzierten Arbeitsaufwand bei der Definition ist der Aufbau auf gewohnten Strukturen für den Bereich Change Management wichtig. Mitarbeiter/ Projektmitglieder können so leichter in den Wandel einbezogen werden.

Die Auswertung der IST-Analyse wird hierbei grafisch über eine Farbskala mit Harvey Balls dargestellt. Die einzelnen Farben stellen hier die Gesamtbewertung eines Werte-Prinzipien-Paars dar, während die Harvey Balls die Bewertung der einzelnen Praktiken wiedergeben. Folgende Abbildung zeigt eine beispielhafte IST-Analyse:

Abbildung 9: Beispielhafte IST-Analyse

Eine grüne Fläche zeigt, dass die Praktik systematisch verwendet wird. Wenn die Fläche gelb ist, findet eine Anwendung in bis zu 75 % der Fälle statt. In diesem Fall ist auch davon auszugehen, dass die Praktik systematisch beschrieben ist. An dieser Stelle könnte es aber sein, dass die Ziele der Praktik noch nicht immer erfüllt sind, weshalb die Bewertung noch nicht höher liegt. Rote Felder deuten darauf hin, dass eine gewisse Struktur vorhanden ist, welche aber noch nicht systematisch beschrieben wurde. Nicht farblich markierte Felder zeigen, dass die Methode oder Methoden aus diesem Feld nicht verwendet werden.

Einige Praktiken sind im Zuge des Fragebogens mit mehreren Statements beschrieben worden. Die Berechnung der Bewertung ergibt sich für diesen Fall aus dem Mittelwert der Statements. Erreicht beispielsweise das erste Statement ein Ergebnis von 50 % und das zweite Statement ein Ergebnis von 60 %, erhält die Praktik eine Gesamtbewertung von 55 %. Dies liegt darin begründet, dass die Statements aufeinander aufbauend sind und jedes einen Teil einer Praktik abfragt.

Fazit

Abschließend ist festzuhalten, dass der Weg zu einer agil arbeitenden Organisation einen Kulturwandel erfordert. Dieser Wandel gelingt Unternehmen nur, wenn sie es schaffen, die Werte und Prinzipien in der Unternehmenskultur zu verwurzeln. Hierbei sind die Themen Kommunikation, Mitarbeiterbefähigung, Vertrauen und Entscheidungsverlagerung wichtig. Das entwickelte Reifegradmodell fungiert als Leitfaden und dient als Werkzeug, um Unternehmen und Führungskräften einen Weg aufzuzeigen, wie eine erfolgreiche und individuelle Adaption gelingen kann.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] SCHRÖDER, AXEL (Hrsg.) [Agile Produktentwicklung; 2018]: Agile Produktentwicklung: schneller zur Innovation – erfolgreicher am Markt, 2., überarbeitete Auflage., München: Hanser.
[2] DYBÅ, TORE; DINGSØYR, TORGEIR [Empirical studies of agile software development; 2008]: Empirical studies of agile software development: A systematic review, in: Information and Software Technology, Bd. 50, Nr. 9–10, S. 833–859.
[3] FUCHS, CHRISTOPH; GOLENHOFEN, FRANZISKA [Mastering Disruption and Innovation in Product Management; 2019]: Mastering Disruption and Innovation in Product Management: Connecting the Dots, 1st ed. 2019., Cham: Springer International Publishing : Imprint: Springer.
[4] [26] [27] [28] [29] [30] SIDKY, AHMED [A structured approach to adopting agile practices; 2007]: A structured approach to adopting agile practices: the agile adoption framework, Blacksburg, Virginia: Virginia Polytechnic Institute and State University
[5] [8] [13] PFEFFER, JOACHIM [Grundlagen der agilen Produktentwicklung; 2019]: Grundlagen der agilen Produktentwicklung, Wien: peppair Verlag.
REITTINGER, ANTONIUS [Hybrid Agile; 2018]: »Hybrid Agile« – best of two worlds, in: Agile Produktentwicklung: schneller zur Innovation – erfolgreicher am Markt, München: Hanser, S. 234–251.
[6] [11] JACOBSEN, CHRIS; DORN, DAVID; PARENT, JASON; JUSTICE, JOE; THOMPSON, KEVIN; FELSING, MAC; BERLUCCHI, MATTIA; FERRERO, NICOLA; DEZUTTI, PAOLO; BOYAN, RICH; TESSIER, THOMAS; QUAGLIA, DARIA; GUTTMAN, DAWN; SCHREUDER, JASON; STARKWEATHER, KATRINA; WEAVER-JOHNSON, LONNIE; GARDA, MARCO; CARROLL, MICHAEL; GIORGETTI, NICOLO; CARSON, PAUL; PATRIDGE, RICK; BOEBERITZ, DAVE; SMITS, HUBERT; BRADFORD, JEANNE; SANKAI, KAZUTAKA; BERGERO, LUCA; BUCKNER, MARK; FEW, MIKE; SAMMICHELLI, PAOLO; BORSELLA, PETER; VAIDA, THEODORE [Agile Product Charter; 2016]: The Charter for Agile Product Development
[7] LAW, AMY; CHARRON, RAYLENE [Effects of agile practices on social factors; 2005]: Effects of agile practices on social factors, in: Proceedings of the 2005 workshop on Human and social factors of software engineering – HSSE ’05, the 2005 workshop. St. Louis, Missouri: ACM Press, S. 1–5
[9] BECK, KENT; BEEDLE, MIKE; VAN BENNEKUM, ARIE; COCKBURN, ALISTAR; CUNNINGHAM, WARD; FOWLER, MARTIN; GRENNING, JAMES; HIGHSMITH, JIM; HUNT, ANDREW; JEFFRIES, RON; KERN, JON; MARICK, BRIAN; MARTIN, ROBERT C.; MELLOR, STEVE; SCHWABER, KEN; SUTHERLAND, JEFF; THOMAS, DAVE [Manifesto for Agile Software Development; 2001]: Manifesto for Agile Software Development
[10] SAMMICHELI, PAOLO [Scrum for Hardware; 2018]: Scrum for Hardware, 2. Auflage
[12] [15] MATHIS, CHRISTOPH; LEFFINGWELL, DEAN [SAFe – das Scaled Agile Framework; 2018]: SAFe – das Scaled Agile Framework: Lean und Agile in großen Unternehmen skalieren, 2., überarbeitete und aktualisierte Auflage., Heidelberg: dpunkt.verlag.
[14] BÖHM, JANKO [Erfolgsfaktor Agilität; 2019]: Erfolgsfaktor Agilität: Warum Scrum und Kanban zu zufriedenen Mitarbeitern und erfolgreichen Kunden führen
[16] SCALED AGILE INC [Welcome to Scaled Agile Framework® 5!; 2021]: Welcome to Scaled Agile Framework® 5!
[17] SCALED AGILE INC [SAFe 5 for Lean Enterprises; 2021]:SAFe 5 for Lean Enterprises
[18] SCALED AGILE INC [Essential SAFe; 2021]: Essential SAFe
[19] SCALED AGILE INC [Large Solution SAFe; 2021]: Large Solution SAFe
[20] SCALED AGILE INC [Portfolio SAFe; 2021]: Portfolio SAFe
[21] SCALED AGILE INC [Core Values; 2021]: Core Values
[22] SAMMICHELI, PAOLO [Industrial Agility; 2017]: Industrial Agility – How to respond to the 4th Industrial Revolution
[23] [24] OZCAN-TOP, OZDEN; DEMIRÖRS, ONUR [Assessment of Agile Maturity Models; 2013]: Assessment of Agile Maturity Models: A Multiple Case Study, in: WORONOWICZ, TANJA; ROUT, TERRY; O’CONNOR, RORY V.; DORLING, ALEC (Hrsg.): Software Process Improvement and Capability Determination, Communications in Computer and Information Science. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 130–141
[25] In Anlehnung an SIDKY, A structured approach to adopting agile practices, 2007, S. 80, sowie BAGASKARA, RABBANI MAHATMA; SAMPE, VERAWATY [Scaled Agile Maturity Measurement in Manufactoring; 2021]: Scaled Agile Maturity Measurement in Manufactoring, Göteborg: Chalmers University of Technology, S. 33

Dieser Beitrag ist ein gemeinsames Werk von Dierk Söllner und Kai Hahn.

Dierk Söllner hat weitere Beiträge im t2informatik Blog veröffentlicht, u.a.:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.