Die agile Skalierung gilt als eine der Königsdisziplinen der Agilität. Scrum oder XP mit einem Team zu machen ist heute nichts Ungewöhnliches mehr, auch zwei oder drei gehen noch - aber mit zehn Teams? oder zwanzig? Oder noch mehr? Das wird hart. Erklärungen für diese Wahrnehmung gibt es viele: steigende Komplexität, Parallelität der Ereignisse und Einbeziehung nicht-agiler Einheiten sind unter den häufigsten, hier soll es aber um einen anderen Erklärungsansatz gehen. In ihm scheitert alles bereits an der Kommunikation.

Die These - wenn verschiedene Menschen miteinander über agile Skalierung reden meinen sie damit oft völlig unterschiedliche Dinge und reden aneinander vorbei. Durch diese fehlschlagende Kommunikation entstehen Frustration, falsche Erwartungshaltungen und später dann Enttäuschungen durch die so nicht erwarteten oder anerkannten Ergebnisse. Was von aussen wie ein Organisationsproblem aussieht ist also in Wirklichkeit ein Verständnisproblem. Um dem auf den Grund zu gehen - welche Verständnisse sind das?

Skalierung bedeutet in diesem Fall, dass eine agil operierende Einheit grösser wird - und dabei weiterhin agil bleiben soll. Die steigende Zahl der beteiligten Teams führt hier zu einem steigenden Koordinationsbedarf, der durch die sukzessive Einführung teamübergreifender Zusammenarbeitsformen bedient wird. Am Anfang z.B. mit einem Scrum of Scrums, später mit Release Trains, noch später mit Gilden, etc. Zum Verständnistyp I ist wichtig: solange das Wachstum anhält ändern sich auch die Zusammenarbeitsformen.

Wenn Manager zum ersten mal über agile Skalierung reden meinen sie meistens das: ein Regelwerk, das die einzelnen agil arbeitenden Teams umgibt und verbindet und in dem es wenn möglich für alles eine Rolle, ein Meeting, ein Quality Gate oder einen Prozess gibt. Häufig stecken dahinter SAFe oder ein "hauseigenes Hybrid-Modell", seltener LeSS, Nexus oder (Pseudo-)Spotify. Zum Verständnistyp II ist wichtig, dass meistens erwartet wird, dass er nach der Einführung "stabil läuft" und nicht mehr angepasst werden muss.

Das was sich Agile Coaches unter agiler Skalierung vorstellen ist genau gegenläufig zum zuletzt genannten Typ: der Skalierungsansatz selbst soll Gegenstand agiler Vorgehensmuster sein, sich also permanent durch inspect & adapt an ändernde Rahmenbedingungen anpassen. Die Entwicklung neuer Zusammenarbeitsformen erfolgt damit explizit ergebnisoffen, einschliesslich der Möglichkeit Veränderungen wieder rückgängig zu machen. Zum Verständnistyp III ist wichtig: in ihm gilt es als Risiko wenn sich das Skalierungsmodell nicht ständig ändert.

Dass diese verschiedenen Verständnistypen zu Problemen führen können wenn sie nebeneinander existieren ist offensichtlich. Nur Typ I und Typ III sind kompatibel miteinander, Typ I und Typ II werden früher oder später in Konflikte laufen, Typ II und Typ III sind völlig inkompatibel. Selbst wenn diese unterschiedlichen Sichtweisen sich gegenseitig bekannt sind ist eine Vermittlung schwierig, wenn das nicht der Fall ist und jeder annimmt, dass sein Verständnis von den anderen geteilt wird, sind Konflikte unausweichlich.

Vor Beginn eines agilen Skalierungsvorhabens macht es also hochgradig Sinn, dass alle Beteiligten sich darüber unterhalten, was sie denn unter agiler Skalierung verstehen. Das erscheint naheliegend, findet aber leider nur selten statt.