Agilität

Agil im großen Stil: Entkopplung vor Skalierung

Diesen Beitrag per E-Mail versenden
Sie können maximal fünf Empfänger angeben. Diese bitte durch Kommas trennen.





Die hier eingegebenen Daten werden nur dazu verwendet, die E-Mail in Ihrem Namen zu versenden. Sie werden nicht gespeichert und es erfolgt keine Weitergabe an Dritte oder eine Analyse zu Marketing-Zwecken.

In immer volatileren, unsichereren, komplexen und vieldeutigeren Märkten und Umfeldern, wird gerade für große und entsprechend starre Organisationen in Zukunft die Anpassungsfähigkeit immer wichtiger. Oder mit den etwas drastischeren Worten von Jack Welch: „If the rate of change on the outside exceeds the rate of change on the inside, the end is near.“ Nun wollen also alle agil werden, ihre Supertanker agilisieren und ihre Organisationen transformieren. Auf Ebene des einzelnen Teams scheint auch schnell alles klar: klein, schlagkräftig und cross-funktional soll es sein, end-to-end verantwortlich und selbstorganisiert entscheiden mit einem Product-Owner als Visionär und Richtungsgeber. Was aber wenn die Produkte viel größer sind und gefühlt sowieso alles mit allem irgendwie zusammenhängt und also viele Teams koordiniert werden müssen? Dann schlägt die Stunde von Skalierungsframeworks wie dem Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) oder Nexus. Zu früh meistens, weil die technischen Schulden der Vergangenheit, die hohe Kopplung und die monolithischen Architekturen, dadurch akzeptiert und tendenziell nur verwaltet anstatt reduziert werden. Kurz gesagt: Entkopplung vor Skalierung.

Jahr für Jahr zeigt der Chaos-Report der Standish-Group ein ähnliches Bild: Je größer ein Projekt, desto geringer die Erfolgswahrscheinlichkeit. Auch wenn agile Projekte gegenüber Wasserfall-Projekten eine deutlich höhere Erfolgswahrscheinlichkeit haben, diese Tendenz bleibt auch hier erhalten: Je größer, desto riskanter. Zusammengefasst sieht das dann beispielsweise im Chaos-Report 2015 so aus (vergleiche auch den zugehörigen Artikel bei InfoQ):

Quelle: Standish Group 2015 Chaos Report – Q&A with Jennifer Lynch

Da für viele Organisationen lange Jahre Anpassungsfähigkeit keine entscheidende Rolle spielte, sondern eher die Effizienz im Vordergrund stand, tendieren IT-Landschaften aufgrund vermuteter Skaleneffekte eher zu großen monolithischen Architekturen. Selbst wenn dieses Monolithen in verschiedene Schichten und Komponenten logisch unterteilt sind, ihre hohe Kopplung erfordert dennoch ein koordiniertes Vorgehen zur Weiterentwicklung, also gemeinsame Planung, viele Abstimmungen, gemeinsamer Test und gemeinsame Auslieferung in eine Produktionsumgebung. Da diese Monolithen ihrerseits mit anderen Monolithen und Systemen über Schnittstellen verbunden sind, sind dann für solche Cluster oft nur zwei bis drei große Releases pro Jahr möglich. Und gemäß den Ergebnissen des Chaos-Reports entsprechend riskant.

Quelle: YouTube

Daran ändert auch Agilität auf Teamebene mit entsprechenden Skalierungsframeworks nichts. Die historisch gewachsenen Abhängigkeiten werden einfach mehr oder weniger unhinterfragt übernommen und anders koordiniert. Auch Amazon hatte interessanterweise genau dieses Problem, wie Rob Brigham, AWS senior manager for product management, in seinem Vortrag bei re:invent 2015 selbst zugibt: „If you go back to 2001 the Amazon.com retail website was a large architectural monolith. Now, don’t get me wrong. It was architected in multiple tiers, and those tiers had many components in them, but they’re all very tightly coupled together, where they behaved like one big monolith.“ Durch konsequentes Refactoring ihres Monolithen in kleine Services mit definierten (und versionierten) Schnittstellen zur Entkopplung, automatisierten Tests gegen diese APIs und einer hoch-automatisierten Deployment-Engine (Apollo) können die Two-Pizza-Teams seither weitestgehend unabhängig Anpassungen schnell ausliefern (und taten das in den ersten zwölf Monaten nach Einführung von Apollo auch 50 Millionen mal, also mehr als einmal pro Sekunde, wie Werner Vogels, CTO Amazon, stolz berichtet). Ein schönes Beispiel für das Prinzip Entkopplung vor Skalierung.

Quelle: YouTube

Autor

Mein Name ist Marcus Raitner. Über die Themen Führung, Agilität und Digitalisierung schreibe ich regelmäßig in diesem Blog. Schreiben bedeutet für mich Nachdenken über Erlebtes auch und gerade im Dialog mit meinen Lesern. Hauptberuflich begleite die Veränderung von Organisationen hin zu mehr Agilität. Mein Motto dabei lautet: Zusammenarbeit gestalten auf Augenhöhe. Ich war seit der ersten Stunde Mitglied des Organisationsteams des PM Camps Dornbirn, wo die PM-Camp Bewegung 2011 begann. Dort habe ich zusammen mit einigen Mitstreitern openPM gegründet. Ich bin verheiratet und stolzer Vater zweier kleiner Töchter.

Kommentar verfassen