Montag, 2. März 2020

Agile Skalierung – in 3D!

Agile Skalierung in drei Dimensionen - 3D-BrilleAgil arbeitende Teams haben sich – zumindest in der Software-Entwicklung – fest etabliert. Wo agile Zusammenarbeit nicht nur als rein organisatorische Übung missverstanden sondern mit Verbindlichkeit und im ausdrücklichen Bewusstsein der zugrundeliegenden Prinzipien gelebt wird, lösen agile Teams am Ende tatsächlich die Versprechen der Agilität ein: Hohe Qualität, hohe Lieferfähigkeit, hohe Kunden- und Mitarbeiterzufriedenheit. Auf diesen Errungenschaften basiert wiederum die Fähigkeit, die der ganzen Bewegung den Namen gegeben hat, nämlich, schnell und mit geringem Aufwand auf Veränderungen optimal reagieren zu können: Agilität.
Nun sind agile Teams naturgemäß kleine Einheiten, idealerweise weniger als 10 Personen stark. Seit jeher gibt es deshalb ein lebendiges Interesse daran, Agilität auf ein größeres Umfeld auszudehnen, sei es, weil man aufwändige Ziele hat, die man mit nur einem Team dieser Größe nicht schnell genug erreichen kann, sei es, weil man sich die Fähigkeit der Agilität auch außerhalb der Software-Entwicklung wünscht. Diese Ausdehnung über einzelne Entwicklungs-Teams hinaus nennt man Skalierung.

Bei agiler Skalierung lassen sich prinzipiell drei verschiedene Ausdehnungsrichtungen – Dimensionen – unterscheiden. Weil es drei sind, liegt es nahe, sie in einem dreidimensionalen Koordinatensystem mit x-, y- und z-Achse darzustellen. [1]

Horizontale Skalierung – Skalierung entlang der Wertschöpfungskette


Betrachten wir zunächst einmal die x-Achse, die in diesem Modell als Zeitachse fungiert und auf der ich ein paar aufeinanderfolgende exemplarische Tätigkeiten eines hypothetischen Entwicklungsteams aufgelistet habe:
Tätigkeiten vor der Skalierung - Entwurf, Implementierung, Test, Deployment
Diese Darstellung ist bitte nicht als Rückfall in vor-agile Zeiten zu verstehen; ein agiles Entwicklungsteam wird diese Tätigkeiten natürlich kontinuierlich bzw. in kurzen Iterationen immer wieder ausführen. (Aber man kann zweifellos nur deployen, was man zuvor implementiert hat.)
Doch ist die Umsetzung durch das Entwicklungsteam natürlich weder der erste noch der letzte Schritt in der ökonomischen Wertschöpfungskette. Diese kann zum Beispiel mit einem Business Case beginnen und mit dem Verkauf und Support einer Leistung oder eines Produkts enden:

Agile Skalierung - Tätigkeiten vor und nach der Software-Entwicklung.
Horizontale Skalierung bedeutet, dass auch solche, der Entwicklung vor- und nachgelagerten Aufgaben, von einem agilen Team gemeinsam abgedeckt werden.
DevOps kann als ein Beispiel für horizontale Skalierung angesehen werden: Development und Operations übernehmen die gemeinsame Verantwortung für den gesamten Prozess der Erstellung und des Betriebs einer Anwendung oder eines Service – durch dieses Miteinander werden Kommunikation und Lösungsfindung erheblich erleichtert. Das Verständnis für technische und kulturelle Voraussetzungen des zuvor unbekannten Teils der gemeinsamen Verantwortung wächst auf beiden Seiten. Die kontinuierliche Verbesserung und Weiterentwicklung richten sich nun auf den gesamten Prozess, nicht nur auf den ehemals „eigenen“ Teil. Die gleichen Vorteile materialisieren sich, wenn auch die vor der Entwicklung passierenden Schritte vom gleichen Team abgedeckt werden.

Agile Skalierung - Ausdehnung der Agilität auf den gesamten Wertstrom

Im Grunde wird hier die Idee des Feature-Teams weiterentwickelt. Unter einem „Feature-Team“ versteht man ein (Software-)Entwicklungsteam, das fachlich so breit aufgestellt ist, dass es über alle Schichten einer Anwendung hinweg (z.B. GUI, Fachlogik, Datenbank) ein neues Feature komplett selbständig implementieren kann. Die Einbeziehung aller Beteiligten der Wertschöpfungskette in ein Team schafft sozusagen ein Feature-Team für die ganze Wertschöpfungskette, das nicht nur ein Feature implementieren, sondern einen ganzen Wertstrom selbständig betreiben kann.
Für die konkrete Ausgestaltung solcher übergreifender Teams und ihrer konkreten Zusammenarbeitsformen gibt es keine Patentrezepte. Ist es sinnvoll, dass nun auch das Marketing und der Support am Daily Scrum Meeting der Entwicklung teilnimmt? Wahrscheinlich nicht, schon allein, weil agile Teams aus guten Gründen bestimmte Größenordnungen nicht überschreiten, und weil die enge tägliche Zusammenarbeit im Entwicklungsteam naturgemäß von anderer Art ist, als die Zusammenarbeit mit „entfernteren“ Beteiligten am Wertstrom.
Horizontale Skalierung besteht deshalb oft in der Auflösung von Silos und die Ermöglichung von Zusammenarbeit durch die Schaffung einer Wertstrom-orientierten Organisation mit übergreifenden gemeinsamen Prozessen und Strukturen mit transparenter Planung und Fortschrittskontrolle, mit einem gemeinsamen Arbeitsrhythmus, mit gemeinsamer Verantwortung und gemeinsamer Vision.

Laterale Skalierung – viele Teams im gleichen Wertstrom


Betrachten wir nun einmal folgende Situation - ein Team, sei es nun ein Entwicklungs- oder ein Wertstrom-Team, steht bereit, um entlang der x-Achse „loszulaufen“ und gemeinsam Kundennutzen zu schaffen:

Agile Skalierung - ein Team am Beginn des Wertstroms


Die nächste Herausforderung der agilen Skalierung stellt sich, wenn die Anzahl der Menschen, die zusammenarbeiten sollen, die übliche Größe eines einzelnen agilen Teams überschreitet.[2]
Um im Bild zu bleiben, stehen dann mehrere Teams nebeneinander an der imaginären Startlinie und wollen parallel zur x-Achse loslaufen, um gemeinsam Werte zu schaffen. Im Koordinatensystem handelt es sich dabei um laterale Skalierung, also Skalierung entlang der z-Achse:

Agile Skalierung - laterale Skalierung: Mehrere Teams arbeiten synchron im gleichen Wertstrom

Hier stellen sich unter anderem Aufgaben der Synchronisation und der Aufteilung von Anforderungen unter den Teams, der Reduzierung von gegenseitigen Abhängigkeiten und, wo Abhängigkeiten nicht vermieden werden können, von Abhängigkeitsmanagement. Diese Art von Skalierung hat seit jeher das größte Interesse hervorgerufen, so dass es mittlerweile eine ganze Reihe von praktisch erprobten und gut beschriebenen Frameworks gibt, die Ansatzpunkte bieten und Hilfestellung leisten. Zu nennen sind insbesondere Large-Scale Scrum(LeSS), Scrum@Scale, Nexus™ und SAFe®.

Vertikale Skalierung – wenn ganze Organisationen agil werden


Agile Skalierung - Skalierung entlang der x-Achse, Portfolio, Budget, Strategie, InvestitionBislang haben wir uns – ob horizontal skaliert oder nicht – auf der operativen Ebene aufgehalten. Vertikale Skalierung, also Skalierung „nach oben“, ist die Ausdehnung von Agilität auf jene übergeordneten Steuerungsebenen eines Unternehmens, auf denen über Strategien, Zukunftsmärkte, finanzielle Ziele und letztlich über Produkte und Wertströme selbst entschieden wird.

Doch was bedeutet es, Agilität auf diese Unternehmensebene auszudehnen? Soll da jetzt auch „nach Scrum“ gearbeitet werden? Nun, natürlich darf und sollte man auch auf dieser Ebene passende Formen agiler Zusammenarbeit praktizieren. Aber das wäre einfach Team-Agilität, nur eben in Teams oberhalb der operativen x-z-Ebene. Die zentrale Herausforderung der vertikalen Skalierung ist hingegen, das Unternehmen in die Lage zu versetzen, die Agilität der operativen Ebene auch nutzen zu können. Es hilft ja nichts, wenn man operativ in der Lage ist, sehr kurzfristig auf Veränderungen reagieren zu können, wenn das auf einer globalen Steuerungsebene nicht bekannt ist oder nicht verstanden wird; wenn dort in langen, unflexiblen Planungs- und Umsetzungsperioden gedacht wird und man auf die Auslastung von Cost Centern und vorhandenen Ressourcen ausgerichtet ist; wenn man auf Hierarchien, getrennten Fachabteilungen, und das „Durchmanagen“ von ganz oben bis ganz unten besteht.

Vertikale agile Skalierung kann also bedeuten, die strategische Ebene eines Unternehmens mit einer bereits agilen operativen Ebene zu harmonisieren, indem sie sich dem Rhythmus, den Planungshorizonten und der Wertstrom-Orientierung dieser Ebene anpasst, und dadurch selbst an überlebensnotwendiger Beweglichkeit – Agilität – gewinnt.
Doch dieses Bild einer nachträglichen vertikalen Skalierung, die einer Skalierung auf der operativen Ebene nachfolgt, ist irreführend. Es mag möglich sein, für beschränkte Zeit, z.B. die Dauer eines Projekts, ausschließlich lateral zu skalieren. Aber spätestens, wenn man horizontal skaliert, wenn man aus fachlich begründeten organisatorischen Grenzen ausbricht, um sich an Wertströmen zu orientieren, spätestens dann muss dies verbunden sein mit einer entsprechenden vertikalen Skalierung, die die horizontale Skalierung überhaupt erst dauerhaft ermöglicht – durch explizite Ermächtigung, durch entsprechende Prozesse, Strukturen und Finanzierung, durch Dezentralisierung, durch Vision, Werte, sinnvolle Vorgaben. Die Idee einer „Guerilla“-Agilisierung „von unten“ mag ihren Reiz haben; aber die Aussicht, damit langfristige, robuste Veränderungen außerhalb eines begrenzten Einflussbereichs zu bewirken, sind gering.
Und umgekehrt: Eine Organisation, die Agilität als rein operatives Thema auffasst, erschwert nicht nur den Erfolg dieser Bemühungen sondern blendet den wesentlichen Vorteil einer Agilisierung, nämlich die Beweglichkeit der gesamten Organisation und damit die eigene Konkurrenz- und Zukunftsfähigkeit erheblich zu steigern, vollkommen aus. Die Einführung und die Skalierung von Agilität muss von Anfang an ein dreidimensionales Vorhaben sein.

Feedback!


Du siehst das genauso? Oder komplett anders? Super! Ich freue mich auf dein Feedback!

Fußnoten


[1] Eine Google-Suche – ohne Anspruch auf Vollständigkeit – bringt drei Treffer für zweidimensionale Auffassungen von Skalierung: it-agile, Kraus und Partner, sowie NextLevelConsulting. Auch die bekannte Illustration des LeSS-Frameworks von Bas Vodde und Craig Larmann stellt letztlich ein zweidimensionales Koordinatensystem dar, das meiner „operativen“ x-z-Ebene entspricht.

[2] Nur der Vollständigkeit halber sei erwähnt, dass niemand jemals die Idee hatte, einfach ein entsprechend größeres Team aufzubauen. Ein Kernpunkt der Agilität ist die Konzentration auf temporal und quantitativ überschaubare und damit beherrschbare Zusammenarbeit. Die Anzahl der agil zusammenarbeitenden Personen zu erhöhen, kann daher nur heißen, die Anzahl der agilen Kerneinheiten, der Teams zu erhöhen.


Keine Kommentare:

Kommentar posten