Agiles Skalieren ist häufig gar nicht notwendig

1. Wie bereits beschrieben, weitet sich das „Spielfeld“ für die Agilität. Raus aus den reinen Software-Projekten hin zur Betrachtung des gesamten Unternehmens. Dabei entstehen organisatorische Herausforderungen, welche in der Zusammenarbeit von verschiedenen Fachbereichen mit der IT begründet sind.
2. Die Interaktionen der IT-Systeme in Konzernen sind zunehmend komplexer und können durch losgelöste SCRUM-Teams nicht mehr qualitätsgesichert werden. Die technischen Abhängigkeiten führen dabei zu großen Problemen.
3. Agile Projekte konnten lange „unter dem Radar“ laufen. Entwicklerteams, die nach SCRUM oder KANBAN arbeiteten – ggf. sogar durch die Zusammenarbeit mit Dienstleistern dazu gezwungen sind – wurden über ihren Projekt-Scope hinaus nicht wahrgenommen. Sie waren so gesehen emergente Pilotteams. In dem Moment, wo das Thema Agilität auf den Schreibtisch des Top-Managements landet, beginnen sich mehrere Bereiche dafür zu interessieren. So kann es zum Beispiel sein, dass Herausforderungen zu Budgetierungsprozessen auftauchen. Budgets von agilen Projekten, die zuvor pragmatisch verwendet wurden, müssen jetzt im unternehmensweiten Budgetierungsprozess abgebildet werden.

Diese Entwicklungen führen verständlicherweise direkt zu der folgenden Fragestellung: „Wie steuere ich Agilität eigentlich im großen Kontext?“ Diese erwartbare Reaktion kann jedoch der falsche Ansatz sein. Unternehmen können unter Umständen mit einem anderen Vorgehen wesentlich erfolgreicher agieren. In diesem Artikel möchte ich darstellen, wie eine solche Situation erkannt werden kann und wie alternative Strategien aussehen könnten. Denn wie schon Abraham Maslow in seinem „Law of Instruments“ sagte: "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." Wenn eine agile Organisation wächst, ist ein Skalierungwerkzeug nicht immer die beste Wahl.

Zur Einordnung des Begriffes „agile Skalierung“ nehme ich eine kurze Abgrenzung vor: Mit agiler Skalierung ist die Auswahl und der (partielle) Einsatz etwaiger Frameworks gemeint, die als Alternativen, Ergänzungen oder aber Überbauten für SCRUM oder KANBAN dienen können. Die berühmtesten Alternativen stellen dabei LeSS, Nexus, SCRUM@Scale, SAFe, Enterprise Kanban oder das Spotify-Modell dar. Dieser Artikel widmet sich dem Vergleich der Skalierungs-Frameworks untereinander. Grundsätzlich lassen sie sich mittels folgender zwei Dimensionen einteilen:

1. Scope
   Spotify oder SAFe können zum Beispiel ein ganzes Unternehmen betrachten. Wohingegen LeSS oder SCRUM@Scale lokaler in kleineren Bereichen anzusiedeln sind.
2. Technologienähe
   Enterprise Kanban oder Spotify sind Frameworks, die praktisch sofort in IT- und Non-IT-Kontexten eingesetzt werden können. Nexus oder SAFe (trotz der Einführung des Elementes „Business Agility“) sind viel technologiegetriebener.

“Simplicity – the art of maximizing the amount of work not done – is essential”. Das zehnte der zwölf Prinzipien des agilen Manifests. Das, was es aussagen möchte, ist recht klar. Ich muss zugeben, dass ich den Appell zunächst missverstanden habe. Ich habe mich viel zu sehr auf den Begriff „Simplicity“ konzentriert und dabei an Themen wie Clean Code Development und Refactoring in der Software-Entwicklung gedacht. Was bei mir wie ein Blitz einschlug, war die folgende Erkenntnis: Wenn etwas konzipiert, entworfen, entwickelt oder reorganisiert wird, sollte nur getan werden, was wirklich verlangt wird. Keine Interpretation des „potenziell Notwendigen“. Nichts was eventuell in der Zukunft verlangt werden könnte. Oder ganz frei heraus gesagt: „Mach' es nicht schwieriger als es schon ist“. 

Und genau dieser Aufforderung folgt zum Beispiel SCRUM. Der SCRUM-Guide beschreibt das „Warum“ für SCRUM recht prägnant: „Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.“

Es gibt eine komplexe Herausforderung zu lösen? Hier bitte - ein Framework, das einfach erlernbar ist und eine große Hilfe sein wird. Ok, ich gebe zu, dass noch ein Unterschied zwischen „Erlernen“ und „Verstehen“ existiert, dennoch stimmt der Ansatz: Wenn schon eine komplexe Herausforderung existiert, dann macht es keinen Sinn, diese Komplexität künstlich durch etwaige Freigabeprozesse, Rollen oder Dokumentationspflichten zu erhöhen (vgl. den Entwicklungsstandard „V-Modell XT“ mit seinen 35 Rollen). Wenn ich diesen Gedanken fortführe, komme ich zu folgendem Schluss: Wenn eine komplexe Herausforderung dadurch erfolgreich gemeistert werden kann, indem die entsprechenden Arbeitsweisen möglichst einfach gehalten werden, sollte doch eine Gruppe gemeinsam zu betrachtender Herausforderungen (wo die Komplexität steigt) in ihrer Summe mit noch einfacheren Steuerungsmechanismen betrachtet werden. Doch was ist der einfachste „Steuerungsmechanismus“ für eine Gruppe von zusammenhängenden Herausforderungen? Die Antwort: Gar keiner. Slice the elephant. Energie investieren, damit Teams getrennt voneinander arbeiten können! Und zwar bezüglich Personal, Ressourcen und Technologie.

Warum entsteht eine solche Situation mit vielen gegenseitigen Abhängigkeiten? Eigentlich sollten agile Teams crossfunktional und selbstorganisiert sein und eine End2End-Betrachtung auf ihr Produkt haben. Dass dies aber immer der Fall ist, ist realitätsfremd. Es wird immer wieder Projekt- und Produktentwicklungsteams geben, die eine Abhängigkeit zu anderen Personen oder Teams haben. Diese Abhängigkeiten können sowohl durch Kommunikation, Technologie, Ressourcen oder Produktschnitt bedingt sein.

Beispiele für kommunikative Abhängigkeiten im agilen Kontext

• Kommunikation von Anforderungen 
• Abstimmungen mit Dienstleistern 
• Abnahmen durch Stakeholder 

Beispiele für technologische Abhängigkeiten im agilen Kontext

• Notwendige Tools werden über ein Service Center bereitgestellt 
• Automatische Software-Tests und Deployments können nur nacheinander durchgeführt werden 

Beispiele für ressourcenbedingter Abhängigkeiten im agilen Kontext

• Teammitglieder stehen nur teilweise zur Verfügung 
• Expertenwissen liegt außerhalb des Teams 

Beispiel für produktbezogene Abhängigkeiten im agilen Kontext

• Nur das aggregierte Entwicklungsergebnis von zwei Teams (z. B. pro Sprint) ergibt einen Mehrwert für den Nutzer 
• Schnitt von sogenannten Layer-Teams in der Softwareentwicklung, welche zum Beispiel Frontend von der Backend-Entwicklung trennen 

All dies sind Beispiele für Settings, bei denen Teams aufgrund von Abhängigkeiten gezwungen werden, zu warten. Die Auslastung wird dann meist durch einen Fokuswechsel mit anderen Aufgaben abgefangen - dies verlängert jedoch zusätzlich die Lieferzeit von Anforderungen. Es gibt zwei Strategien, um die verlorene Effizienz zurückzugewinnen:

1. Modularisierung:  
   Es wird eine Teamstruktur mit einem Produktschnitt und einer technologischen Basis gebaut, um Abhängigkeiten größtmöglich aufzulösen. Ein Ansatz, den zum Beispiel das Spotify-Framework oder auch die Holakratie in den Fokus rücken. Auch Kanban richtet einen expliziten Blick auf übergreifende Abhängigkeiten. 
2. Integration: 
   Die Abhängigkeiten zwischen Teams, Produkten und Technologien werden in Kauf genommen. Es wird einen Managementsystem darum aufgebaut, um diese zu steuern. 

Beide Strategien haben neben ihren Vorteilen auch relevante Nachtteile:
Im Falle der Modularisierung wird auf vielen Management-Ebenen Überzeugungsarbeit geleistet werden müssen. Es wird auch auf Team-Ebene Change-Management notwendig sein. Tendenziell wird es Mitarbeiter:innen geben, die ihre Rolle aufgeben müssen, Investitionen in Technologie werden nötig sein und einige Unternehmensprozesse müssen überarbeitet werden.

Der Aufbau eines Management-Systems hingegen dürfte ad hoc weniger Aufwand erzeugen. Die Herausforderung besteht nur darin möglichst alle Verknüpfungen zwischen Teams, Produkten und Technologien zu identifizieren sowie ein Entscheidungs- und Steuerungsmodell aufzubauen. Genau das tun die meisten agilen Skalierungsframeworks.

Das zweite Ansatz klingt nicht nur weniger aufwändig, er ist es auch. Zumindest zu Beginn. Denn man droht bei dem Versuch des Managements von Abhängigkeiten in negative Spiralen zusätzlicher Abhängigkeiten zu geraten:

Wie die Grafik vereinfacht zeigt, gibt es einige Beziehungen zwischen der gewählten Struktur einer agilen Organisation und ihrem Verhalten. So hat der Schnitt der Produkte, die in Ihrer Organisation entwickelt werden, direkten Einfluss auf die zu nutzende Technologie und die Kommunikationsprozesse, die zur Abstimmung notwendig sein werden. Um diese zusätzlichen Prozesse abdecken zu können, werden Sie in der Regel mehr Expert:innen benötigen. Diese müssen zunächst intern oder extern gefunden werden und haben in der Regel auch andere Aufgaben, was in der Folge Ihre Handlungsfreiheit und Flexibilität einschränken wird. Zudem wird dieser personelle Zuwachs auch wieder miteinander interagieren müssen. Dabei gilt es in der Regel, Rollen mit Aufgaben und Entscheidungsgewalt zu definieren. Darüber hinaus werden zusätzliche Termine zum Austausch notwendig. Der Management-Overhead wächst. Daher ist es zunächst wichtig, einen kritischen Blick auf den Produktschnitt zu werfen.

Kommen wir nun aber zur Ausgangsfrage zurück: Ist eine Skalierung über ein Skalierungsframework wirklich notwendig und wenn ja, welches macht am meisten Sinn? Ich schlage vor, dass wir zusammen in einem Health-Check diese folgenden Fragen in genau der Reihenfolge beantworten:

1. Welche agile Reife haben Ihre Teams? Sind sie mit allen notwendigen Ressourcen bestückt, um eine End2End-Verantwortung für Ihr Produkt zu übernehmen? Ein sich verbessernder Reifegrad wird dazu führen, dass sich Abhängigkeiten automatisch auflösen und die agile Organisation modularisiert werden kann. Das gilt auch während des Einsatzes eines Skalierungsframeworks. Andernfalls werden unausgewogene agile Teams unmittelbar zu Fehlerquellen der skalierten Prozesse.
2. Kennen Sie existierende technologische, prozessuale und menschliche Abhängigkeiten zwischen Ihren Teams und Ihren Produkten? Skalierungsframeworks können beim Management von diesen nur Hilfe bieten, wenn sie auch berücksichtigt werden.
3. Haben Sie versucht, die bekannten Abhängigkeiten aufzulösen? Lässt sich dies bewerkstelligen? Wenn ja, wie groß ist der Aufwand, unabhängige agile Teams zu bekommen?

Wenn Sie sich bei einer der Fragen nicht sicher sind oder Ihnen nicht klar ist, ob Ihre Organisation Herausforderungen hat, sollten Sie genau an dieser Stelle ansetzen. Ich schlage dabei ein agiles iteratives Vorgehen vor. Es passiert häufig, dass sich bereits nach Optimierung der agilen Teams viele Fragezeichen auflösen.