Agile Arbeitsweisen im IT-Kontext haben sich innerhalb der letzten Jahre immer weiter zum De-facto-Standard etabliert. SCRUM und Software-KANBAN sind dabei die am häufigsten genutzten Frameworks in IT-Organisationen und regelmäßig kommen beide Ansätze sogar zeitgleich vor (Hier eine Einordnung, warum beide Frameworks komplementär agieren). Aber auch im Non-IT-Umfeld wird unsere Cassini-Expertise zunehmend häufiger für agiles Arbeiten angefragt. Die Zeit im Homeoffice hat diesen Trend sogar verstärkt. Viele unserer Klienten setzen demnach agile Methoden in kleinen Umfeldern ein. In der Regel entsteht aus dieser Situation eine Folgefrage: „Wie kann ich als agile Organisation eigentlich skalieren?“
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:
“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
Beispiele für technologische Abhängigkeiten im agilen Kontext
Beispiele für ressourcenbedingter Abhängigkeiten im agilen Kontext
Beispiel für produktbezogene Abhängigkeiten im agilen Kontext
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:
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:
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.
