Wer von agiler Skalierung spricht meint meistens etwas anderes

Bild: Piqsels - Lizenz

Unter allen Herausforderungen die eine agil arbeitende Organisation mit sich bringt dürfte die Skalierung die grösste sein. Sobald es nicht mehr nur ein Team ist das nach XP, Scrum, Kanban & Co arbeiten soll sondern mehrere, und das auch noch aufeinander abgestimmt, müssen Zusammenarbeitsmodelle entwickelt werden. Der hohe Anspruch an sie: sie sollen die auf der Teamebene mögliche Schnelligkeit und Flexibilität bewahren und auf die Gesamtorganisation übertragen, auf der anderen Seite aber auch eine gemeinsame Ausrichtung auf übergeordnete Ziele ermöglichen.

Es gibt tatsächlich auch Organisationen in denen das gelingt, in den meisten Fällen ist das Ergebnis aber nicht das gewünschte. Entweder führt der Versuch sich auf ein gemeinsames Ziel auszurichten wieder zu Hierarchie und Bürokratie oder eine nicht ausreichende Abstimmung untereinander endet in Ineffizienz und Ineffektivität. "Agil skaliert nicht" ist aufgrunddessen eine häufig zu hörende Aussage geworden. Aber ist das wirklich so? Ein anderer Erkläransatz ist der, dass das was meistens für agile Skalierung gehalten wird etwas ganz anderes ist.

Um das zu verstehen rufen wir uns kurz eine agile Organisationsform vor Augen. Am Anfang steht die noch zu erledigende Arbeit, meistens in Form eines Backlogs. Aus dem wird eine Teilmenge entnommen, die durch ein (Sprint-)Ziel zu einem sinnvollen Umfang gruppiert, durch ein crossfunktionales Team ohne externe Abhängigkeiten umgesetzt und als benutzbares Increment an die Anwender geliefert wird. Übertragen auf skalierte Ansätze bleibt das Vorgehen das gleiche, nur sind es jetzt mehrere crossfunktionale Teams ohne externe Abhängigkeiten die gleichzeitig auf ein gemeinsames Ziel hinarbeiten. Visualisiert sieht das so aus:



Und jetzt die spannende Frage: entspricht das was meistens als agile Skalierung bezeichnet wird diesem Bild? Leider nicht. Es fehlt in praktisch jedem Fall zwei entscheidende Kriterien - die Teams sind eben nicht crossfunktional und haben eben doch zahlreiche externe Abhängigkeiten. Bedingt dadurch ist es in diesen Fällen nicht möglich konzentriert auf das Ziel hinzuarbeiten, stattdessen sind alle gezwungen auf Zulieferungen zu warten und unfertige Arbeit an andere Einheiten weiterzugeben. Erst wenn alle dieser voneinander abhängigen Teams fertig sind kann ein benutzbares Increment an die Anwender geliefert werden. Visualisiert (und stark vereinfacht) sieht das so aus:


Dass in einem solchen Konstrukt die Lieferzyklen deutlich länger sind als in dem zuerst genannten ist offensichtlich. Sowohl die zeitliche als auch die inhaltliche Koordination der Übergaben ist derartig anspruchsvoll, dass sie einen Grossteil der Arbeitszeit einnimmt. Die vorderen und hinteren Teams der Prozesskette haben keine direkten Berührungspunkte und liegen zeitlich weit auseinander, so dass umfangreiche Dokumentation nötig wird. Wenn ein zulieferndes Team mit der Arbeit fertig ist wird das abnehmende nicht immer verfügbar sein, so dass Wartezeiten im System entstehen. Etc.

Das alles heisst natürlich nicht, dass diese Abläufe nicht optimierbar wären. Aber für eine Optimierung derartiger Systeme sind die agilen Ansätze nicht die beste Lösung. Hier ist das klassische Lean Management besser geeignet, dass mit seinen Wertstromanalysen, Just in Time-Lieferungen und Work in Progress-Limits auch über passende Werkzeuge verfügt. Das wird in der Regel auch unbewusst verstanden, versehentlich aber falsch bezeichnet. Es müssen doch mehrere agile Teams koordiniert werden¹, also muss auch diese Koordination agil sein. Der entscheidende Irrtum vieler Transitionsvorhaben ist also der, dass von agiler Skalierung gesprochen wird, implizit aber Lean Management gemeint ist.

Vor diesem Hintergrund wird auch verständlicher, warum die gängigen agilen Skalierungsframeworks oft nicht funktionieren. Sie sind gedacht für crossfunktionale und unabhängige Teams, werden aber angewandt auf Komponententeams mit vielen Abhängigkeiten. Das kann nicht funktionieren. Und um das allen Beteiligten klar zu machen ist das Aufzeigen des zentralen Irrtums wichtig: Wer von agiler Skalierung spricht meint meistens etwas anderes.


¹Dass nicht verstanden wird, dass diese Teams ohne Crossfunktionalität und Freiheit von Abhängigkeiten kaum agil sein können, ist Teil des Missverständnisses.