Agile Skalierung ohne Framework: Wie Unternehmen eigene Regeln finden

Agile Skalierung gelingt ohne Framework, wenn ein Unternehmen fünf Fragen selbst beantwortet: Teamzuschnitt, Takt, Abhängigkeiten, Ziele und Entscheidungsrechte. Aus den Antworten entsteht ein kurzes Regelwerk, das zur eigenen Organisation passt. Ein Framework bleibt eine Option, sobald die Zahl der Teams und die Abhängigkeiten zwischen ihnen die Selbstorganisation überfordern.

Dieser Beitrag beschreibt, wie Unternehmen eigene Regeln für das Arbeiten mit vielen Teams entwickeln, vergleicht die bekannten Skalierungs-Frameworks nach Einsatzfeld und liefert eine Prüfliste, mit der sich ein Regelwerk auf Wirkung testen lässt. Der Druck, ein Framework zu übernehmen, ist real: Beratungsangebote und Zertifizierungen sowie Wettbewerber setzen Entscheider unter Zugzwang. Die Entscheidung braucht Kriterien.

Warum reicht Scrum allein für viele Teams nicht aus?

Scrum allein reicht für viele Teams nicht aus, weil der Scrum Guide ein einzelnes Team beschreibt. Der Guide von 2020 regelt Rollen und Ereignisse sowie Artefakte eines Scrum Teams mit einem Product Owner, einem Scrum Master und Entwicklern. Wie mehrere Teams an einem Produkt arbeiten, wie sie Abhängigkeiten klären und wer Prioritäten zwischen ihnen setzt, bleibt offen. Diese Lücke füllen die Skalierungs-Frameworks, und genau hier entscheidet sich, ob ein Unternehmen ein fertiges Regelwerk übernimmt oder eigene Regeln entwickelt.

Die Frage entsteht an einer konkreten Schwelle. Bis zu fünf oder sechs Teams, die an einem Produkt arbeiten, genügen in der Regel ein gemeinsames Backlog, ein gemeinsamer Rhythmus und ein regelmäßiges Abstimmungsformat. Darüber wächst die Zahl der Abhängigkeiten schneller als die Zahl der Teams, weil jedes Team mit jedem anderen in Verbindung treten kann. Wie sich diese Abhängigkeiten behandeln lassen, beschreibt der Beitrag zu Big Room Planning.

Welche Skalierungs-Frameworks gibt es, und wofür sind sie gedacht?

Die verbreiteten Skalierungs-Frameworks sind das Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Nexus und Scrum@Scale, und sie unterscheiden sich im Umfang ihrer Vorgaben. Die folgende Übersicht ordnet sie nach Einsatzfeld und Voraussetzung, jeweils nach den Primärquellen der Autoren.

Die Einführungsschritte ähneln sich: Ein Pilot mit wenigen Teams, Schulung der Beteiligten, Etablieren des gemeinsamen Rhythmus und danach schrittweise Ausweitung. Der Unterschied liegt im Umfang dessen, was vorgegeben wird. Bei SAFe übernehmen Sie ein Gerüst mit vielen Bausteinen, bei LeSS und Nexus ein schlankes Regelwerk. Scrum@Scale von Jeff Sutherland erweitert Scrum um sich wiederholende Zellen aus Teams. Keines davon ist falsch. Ein Framework wird zum Problem, wenn es als Ganzes eingeführt wird, bevor jemand das Problem benannt hat, das es lösen soll. Wie dieses Muster in Unternehmen aussieht, beschreibt der Beitrag zu Methoden-FOMO.

Wie entwickeln Unternehmen eigene Regeln für viele Teams?

Unternehmen entwickeln eigene Regeln, indem sie fünf Bausteine nacheinander klären: Teamzuschnitt, Rhythmus, Abhängigkeiten, Ziele und Entscheidungsrechte. Jeder Baustein beantwortet ein Problem, das Teams im Betrieb tatsächlich haben, und die Antworten stammen aus bekannten Quellen, die sich einzeln übernehmen lassen.

Die Reihenfolge folgt einer Logik. Der Teamzuschnitt kommt zuerst, weil Conways Beobachtung von 1968 gilt: Organisationen bauen Systeme, die ihre Kommunikationsstruktur abbilden. Ein schlechter Zuschnitt erzeugt Abhängigkeiten, die keine Regel mehr heilt. Der Beitrag zu Team Topologies beschreibt, wie Sie Teams nach dem Fluss der Arbeit schneiden. Für die Sichtbarkeit von Arbeit über mehrere Ebenen hilft das Modell der Flight Levels, und für die Verteilung von Entscheidungen liefert das unFIX-Modell Bausteine.

Wie viele Teams verträgt ein eigenes Regelwerk? Der Rechenweg

Ein eigenes Regelwerk genügt, solange die Zahl der Abhängigkeitspaare überschaubar bleibt, und diese Zahl lässt sich ausrechnen. Bei n Teams gibt es höchstens n mal (n minus 1) geteilt durch 2 Paare, die einander brauchen können. Entscheidend ist, wie viele davon in der Praxis tatsächlich Abhängigkeiten haben. Das folgende Beispiel ist illustrativ.

Die Zahlen sind eine Rechenhilfe und keine Studie. Sie zeigen, dass die Koordinationslast mit dem Quadrat der Teamzahl wächst, und dass die Antwort auf diesen Zuwachs eine Gruppierung ist: Teams, die dieselbe Abhängigkeit teilen, gehören in eine Gruppe mit eigener Abstimmung. Das Ergebnis lässt sich ohne Framework erreichen, wenn der Zuschnitt stimmt und jemand die Regeln pflegt. Die erste Stellschraube ist deshalb der Zuschnitt, die zweite das Abstimmungsformat und erst die dritte die Frage nach einem Framework.

Wann lohnt sich ein Framework doch?

Ein Framework lohnt sich, wenn mehr als etwa ein Dutzend Teams gemeinsam liefern, Führungskräfte eine gemeinsame Sprache brauchen und die Organisation Kapazität für eine umfassende Einführung hat. Hinzu kommt ein praktischer Grund: Wo viele Neue in kurzer Zeit eingearbeitet werden müssen, spart ein dokumentiertes Regelwerk mit Schulungsangeboten Zeit. Die Größenordnung ist ein Erfahrungswert aus der Praxis und keine Studienzahl.

Auch dann gilt: Beginnen Sie mit dem Problem und wählen Sie die Bausteine, die es lösen. Ein Framework lässt sich schrittweise übernehmen, und jede Übernahme gewinnt, wenn sie an eine Kennzahl geknüpft ist. Dasselbe Prinzip gilt für das Spotify-Modell, das 2012 Henrik Kniberg und Anders Ivarsson als Momentaufnahme der Arbeitsweise bei Spotify beschrieben haben. Es zeigt Ideen, die zu einem Unternehmen mit seiner Kultur und Größe passten, und wer es kopiert, übernimmt die Antworten auf Fragen, die Spotify gestellt hat.

Eigene Regeln für agile Skalierung mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management und Organisationsdesign arbeitet er am Teamzuschnitt und an den Entscheidungswegen sowie Schnittstellen, damit Regelwerke zur Organisation passen und im Alltag gelten.

Das Vorgehen folgt dem Niehues Delivery Model. Für agile Skalierung zählen drei seiner Prüffragen: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen und Entscheidungswege sowie Schnittstellen braucht der Betrieb? Welche Kennzahl zeigt nach 90 Tagen, dass die Lösung ankommt? Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen, die 30 Minuten dauert und über den Kontakt vereinbart wird.