Voraussetzung für die agile Skalierung

Um die skalierte agile Softwareentwicklung zu bewältigen, haben sich verschiedene skalierte agile Frameworks herausgebildet. Mit deren Hilfe ist es möglich, mit mehreren Teams gleichzeitig agil an einem Produkt zu arbeiten. Skalierte agile Frameworks können als eine Form der Organisationsstruktur verstanden werden; manche geben nur überblicksartige Beschreibungen vor, andere sind detailliert.^[1]

Skalierte agile Frameworks beinhalten Praktiken der Technologie- und Management-Ebene; dabei werden Events, Rollen und Artefakte ergänzt. Gemäß einer Befragung von 15 Erfindern der skalierten agilen Frameworks wurden folgende Gründe für die Entwicklung genannt: die Verbesserung der Anpassungsfähigkeit der Organisation, die Verbesserung der Zusammenarbeit sowie die Koordination und Synchronisation agiler Teams, die am gleichen Produkt arbeiten.

Auf welcher Ebene soll skaliert werden?

Die Anwendung von Prinzipien der agilen Softwareentwicklung in großem Maßstab erfordert eine Schärfung des Begriffs “agile Skalierung”. Powers unterscheidet drei Varianten:^[2]

• agile Praktiken, die von einem Team in einem großen Unternehmen verwendet werden,
• agile Praktiken in einem großen Entwicklungsvorhaben und
• die Agilität eines Unternehmens

Analog dazu unterscheiden sich die skalierten agilen Frameworks darin, wie sie den Aspekt der Unternehmens-, der Programm-, der Portfolio- und der Team-Ebene berücksichtigen. In diesem Zusammenhang wird von vertikaler Skalierung und horizontaler Skalierung gesprochen.

Vertikale Skalierung umfasst die organisatorischen Ebenen von der Planung über die Strategie bis zur Ausführung.^[3] Horizontale Skalierung meint die Koordinierung einer großen Anzahl agiler Teams.^[4]

Häufig ist das schon die erste Hürde: Ein klares Verständnis sollte geschaffen werden, auf welcher Ebene skaliert wird – und warum. Denn agile Skalierung ist kein Selbstzweck; es sollte schließlich nur skaliert werden, wenn damit ein Business Value (Geschäftswert) generiert werden kann.

Ab wann spricht man von skalierter agiler Softwareentwicklung?

Gemäß eines historischen Überblicks zur agilen Softwareentwicklung kam das Thema “Large Scale Agile” Mitte der 2000er Jahre auf.^[5] Bisher besteht in der Literatur kein einheitliches Verständnis darüber, ab wann von “skalierter agiler Softwareentwicklung” gesprochen werden kann. Stattdessen können mehrere Faktoren verwendet werden, um dies zu charakterisieren.

Dingsøyr und Moe identifizierten das Skalierung in Bezug auf die Anzahl der Personen, die Anzahl der Teams, die Standorte, die Zeitzonen und den Umfang der Codebase charakterisiert werden kann.^[6]

Dikert, Paasivaara und Lassenius diskutierten Sichtweisen von Praktikern und Forschern, deren Beobachtungen zwischen 50 und 100 Personen lagen. Sie legten für “Large Scale” eine Anzahl von 50 oder mehr Personen oder mindestens sechs Teams fest.^[7]

Eine weitere Betrachtungsweise lieferten Dingsøyr, Fægri und Itkonen. Dieser Taxonomie folgend handelt es sich bei zwei bis neun Teams um “Large Scale” und bei zehn oder mehr Teams um “Very Large Scale“.^[8] Zudem lässt sich festhalten, dass mehrere Teams gemeinsam an einem Entwicklungsvorhaben arbeite.n^[9] Ein Multiprojektmanagement, bei dem mehrere Teams gleichzeitig an mehreren Entwicklungsvorhaben arbeiten, ist damit nicht gemeint. Da skalierte agile Frameworks ab drei Teams angewendet werden können, ist die Betrachtungsweise aus Praxissicht (=! Forschungssicht) gemäß Anzahl der Teams tauglich.

Voraussetzungen für die Skalierung agiler Softwareentwicklung

Jetzt kommen wir zum Eingemachten: Welche Voraussetzungen sollten geschaffen werden, um die agile Softwareentwicklung zu skalieren?

Verständnis für das agile Arbeiten ist etabliert

Eine wesentliche Voraussetzung, um in die skalierte agile Softwareentwicklung zu starten, ist ein ausgeprägtes Verständnis für das agile Arbeiten. Es ist relevant, agiles Arbeiten zunächst sicher im kleinen Rahmen zu beherrschen, bevor skaliert wird. Denn beim Skalieren skalieren alle Herausforderungen mit, die agiles Arbeiten birgt.

Um das vorliegende Verständnis für das agile Arbeiten zu überprüfen, ist eine agile Reifegradbestimmung hilfreich. Diese stellt eine Situations- und Bedarfsanalyse dar.

Es gibt verschiedene Methoden, um den agilen Reifegrad zu bestimmen: Neben elaborierten Tests stehen auch kurze Checks zur Verfügung. Insbesondere sind das “Agile Fluency Model”, die “Scrum Team Survey” von The Liberators oder der “Nokia Test” von Jeff Sutherland zu nennen.

Die agile Reifegradbestimmung kann durch die bestehenden Scrum Master oder Agile Coaches durchgeführt werden. Da eine Vielzahl an Methoden existieren, kann diesbezüglich ein individueller Vorschlag oder eine eigene Methodenkombination von den jeweiligen Agile Coaches oder Scrum Mastern entwickelt werden.

Da das agile Arbeiten die Kundenzentrierung in den Mittelpunkt stellt, sind auch die Kundeneinbindung und Kundenzufriedenheit zu prüfen. Der aktuelle agile Reifegrad zeigt den Ist-Zustand auf und identifiziert mögliche Herausforderungen. Spätestens ab diesem Zeitpunkt wird auffallen, ob das agile Arbeiten verstanden wurde.

Auf dieser Basis können Maßnahmen eingeleitet werden. Je besser der agile Reifegrad bewertet wird, desto besser kann die skalierte agile Software-Entwicklung umgesetzt werden. Erfolgsfaktoren, die dabei helfen, ein agiles Verständnis aufzubauen, sind agile Pilotprojekte, Trainings und Coachings.^[10]

Überprüfung des Lieferumfangs, der Architektur und des Zeitpunkts

Die Skalierung der agilen Softwareentwicklung soll durch einen relevanten Kundennutzen vorangetrieben werden. Hinter diesem Kundennutzen steht folglich ein Geschäftswert, der realisiert werden kann. Das bedeutet, es liegt ein Verdacht vor, dass ein Lieferumfang (Produkt, Features oder Anpassungen) benötigt wird, der zusätzliche Teams erfordert.

Dies ist jedoch kritisch zu hinterfragen, denn häufig können Skalierungsvorhaben durch eine geschickte Priorisierung, eine durchdachte Reduzierung des Lieferumfangs oder eine Verschiebung des Lieferzeitpunktes vermieden werden. Das können die Product Owner und Developer gemeinsam eruieren.

Es ist zu prüfen, ob die bestehende Infrastruktur und Architektur der Software es überhaupt erlauben, mit mehreren Teams parallel zu arbeiten. Infrastruktur und Architektur verhalten sich relativ zur Umgebung und sind in der Praxis häufig ein Engpass. Bei der Skalierung sind eine adäquate Infrastruktur und Architektur unerlässlich, damit die Lieferfähigkeit der Developer und die Stabilität der Software sichergestellt ist. Die Infrastruktur und Architektur sollten moderne Entwicklungspraktiken unterstützen. Letztere sind eine Voraussetzung und ein Erfolgsfaktor für die skalierte agile Softwareentwicklung.^[11] Insbesondere sind Continuous Integration, Continuous Delivery, DevOps, Testautomatisierung  und Observability (vollständiges Infrastruktur- und Applikationsmonitoring) zu nennen.^[12]

Diese Entwicklungspraktiken sparen Zeit und Ressourcen. Werden pro Woche und Developer mehrere Stunden durch verbesserte Entwicklungspraktiken gespart, extrapoliert sich dies entsprechend. Daher sollte geprüft werden, ob eine Verbesserung der Infrastruktur und Architektur und daraus resultierende Entwicklungspraktiken eine Skalierung obsolet machen können. Gewonnen hat man damit in jedem Fall.

Wenn Altsysteme zu berücksichtigen sind, können vorab zusätzliche Modernisierungsmaßnahmen oder Refactorings nötig werden.

Wenn eine Optimierung der Architektur und Infrastruktur nicht ausreicht, um den Lieferumfang zu realisieren, ist es notwendig weitere Teams hinzuzufügen. Wie im BAPO-Modell dargestellt, ist die Architektur mit der Organisation und den Prozessen verknüpft. Es ist empfehlenswert die Zielarchitektur, die Produktbereiche und die Teamstruktur in Einklang zu bringen. Hierzu eignen sich verschiedene Ansätze, bspw. Komponenten- versus Feature-Teams, fluide versus stabile Teams, Team Topologies oder das Inverse Conway Maneuver. Im Wesentlichen geht es darum, Abhängigkeiten und Blockaden (Wartezeiten) bestmöglich zu reduzieren. Dieses Vorgehen minimiert wiederum die Interteam-Koordination, ermöglicht so ein autonomes Entscheiden und führt zu einer verantwortlichen End-to-End-Lieferung.

Häufig ist eine mangelnde Wissensverteilung ein Grund für eine (unnötige) agile Skalierung. Häufig werden zusätzliche Spezialisten eingebunden, anstatt in die Wissensverteilung an bestehende Developer zu investieren. Je besser das Wissen verteilt ist, desto besser sind Developer in der Lage, zu agieren und bestmögliche Entwicklungsarbeit zu leisten. Die Wissensverteilung kann mittels Pair Programming, Mob Programming, Communities of Practice (CoP) oder durch Schulungsmaßnahmen durch interne Developer oder externe Spezialisten geschehen.

Zunächst sollte geprüft werden, ob es möglich ist, eine Wissensvermittlung zu erzielen, bevor skaliert wird und ob so eine Skalierung obsolet machen könnte.

Timing ist alles: Der richtige Zeitpunkt

Weiterhin ist zu prüfen, ob die Skalierung der Softwareentwicklung zum richtigen Zeitpunkt verfolgt wird. Eine Veränderung der Arbeitsweise wird nicht unmittelbar wirksam werden und kann die Liefergeschwindigkeit vorübergehend beeinträchtigen. Es ist eine Phase der Umstellung zu berücksichtigen, da weitere Teams ergänzt, neue Kollegen integriert und bestehende Teams neu zusammengesetzt werden. Eine organisationale Umstellung bei gleichzeitigem Lieferdruck führt zu einer Überlast und ggf. zur Abkehr von der skalierten agilen Software-Entwicklung. Aus diesem Grund sollte Klarheit über die Opportunitätskosten bestehen:

• Agile Metriken des Entwicklungsprozesses, die bisher gesammelt wurden, sind nicht mehr valide. Die Abgleichs- und Prognosefunktion ist vorübergehend nicht mehr gegeben.
• Gemäß des Tuckman Models durchlaufen Teams Teamformations-Phasen. Bis die Performingphase erneut erreicht wird, vergeht Zeit.
• Insbesondere ist in diesem Zusammenhang zu prüfen, wie mit bisherigen Absprachen und Plänen zu Features und der Roadmap insgesamt verfahren wird. Bisher geplante Features können verzögert oder verdrängt werden.
• Zudem sollte geprüft werden, ob es die Wettbewerbssituation, bereits bekannte Kundenanforderungen oder weitere spezifische Umstände (saisonale Themen, bspw. Weihnachtsgeschäft im Onlinehandel) zulassen, vorübergehend langsamer zu sein oder neue Prioritäten zu verfolgen.
• Je nach Bürogebäude kann ein zusätzliches monetäres und zeitliches Investment (Umzug, Umbau, Gestaltung der Räume) benötigt werden, da es beim agilen Arbeiten erforderlich ist, die Teams so nah wie möglich nebeneinander zu platzieren. Es ist Platz für teaminterne und teamübergreifende Meetings notwendig. Auf die Bürogestaltung sei hier nur kurz verwiesen.

Je nach Unternehmen sind weitere Punkte zu berücksichtigen, um zu prüfen, ob der aktuelle Zeitpunkt mit dessen Opportunitätskosten geeignet ist, um eine Organisationsveränderung zu bewältigen. Dies ist vom Management, dem Product Ownern, den Developern und den Agile Coaches oder Scrum Mastern zu eruieren.

Und weiter?

In diesem Artikel haben wir die Voraussetzungen für eine skalierte agile Softwareentwicklung beleuchtet. Nächste Woche zeige ich euch, warum diese Frameworks dringend angepasst werden müssen.

Doch wie seht ihr das – welche Voraussetzungen sollten Eurer Meinung nach ergänzt werden? Ich freue mich auf Input!

Quellen

• ^[1] Vgl. Uludag, Ö. u. a., Evolution of the Agile Scaling Frameworks, 2021, S. 130.
• ^[2] Vgl. Power, K., A Model for Understanding When Scaling Agile Is Appropriate in Large Organizations, 2014, S. 83.
• ^[3] Vgl. Horlach, B. u. a., IT Governance in Scaling Agile Frameworks, 2018, S. 1792.
• ^[4] Vgl. Horlach, B. u. a., IT Governance in Scaling Agile Frameworks, 2018, S. 1792.
• ^[5] Vgl. Hoda, R. u. a., The Rise and Evolution of Agile Software Development, 2018, S. 61.
• ^[6] Vgl. Dingsøyr, T., Moe, N. B., Towards Principles of Large-Scale Agile Development: A Summary of the Workshop at XP2014 and a Revised Research Agenda, 2014, S. 3.
• ^[7] Vgl. Dikert, K. u. a., Challenges and success factors for large-scale agile transformations: A systematic literature review, 2016, S. 88.
• ^[8] Vgl. Dingsøyr, T. u. a., What Is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development, 2014, S. 275.
• ^[9] Vgl. Dingsøyr, T. u. a., What Is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development, 2014, S. 275.
• ^[10] Vgl. Dikert, K. u. a., Challenges and success factors for large-scale agile transformations: A systematic literature review, 2016, S. 102.
• ^[11] Vgl. Edison, H. u. a., Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review, 2021, S. 18.
• ^[12] S. dazu Edison, H. u. a., Comparing Methods for Large-Scale Agile Software Development: A Systematic Literature Review, 2021, S. 18.