Eine kurze Typologie der agilen Skalierungsframeworks

Grafik: Pixabay / GDJ - Lizenz

Sobald irgendwo mehrere agile Teams zusammenarbeiten sollen kommen sie ins Spiel: agile Skalierungsframeworks. Mittlerweile gibt es eine ganze Reuhe von ihnen, die alle ihre Fans und Skeptiker haben. Eine Frage wird dabei aber erstaunlich selten gestellt - gibt es Strukturmerkmale, anhand derer man sie grundlegenden Mustern zuordnen kann? Für ein Buchprojekt habe ich versucht, eine entsprechende Übersicht zu erstellen, die ich auch hier teilen möchte.

Wichtig für das Verständnis ist dabei, dass die einzelnen Vorgehensmodelle hier nicht im Detail vorgestellt werden sollen. Es geht darum hervorzuheben, was sie von den anderen unterscheidet und welche ihrer Elemente wesensbestimmend sind. Detailbeschreibungen zu jedem einzelnen gibt es an verschiedenen anderen Stellen, das hier ist ein Versuch einer grundlegenden Gruppierung, die einen Einstieg in das Thema der agilen Skalierung erleichtern soll.

Scrum-Skalierungsframeworks

Beginnen wir mit den Minimalisten. Die Scrum-Skalierungsframeworks LeSS (Large Scale Scrum) und Nexus haben den Anspruch, Scrum zu skalieren ohne ihm Meetings und Rollen hinzuzufügen. Ihre Grundidee: mehrere Scrum Teams teilen sich einen Product Owner, ein Backlog und eine Definition of Done und haben gemeinsame Plannings und Reviews, führen die dazwischenliegenden Sprints aber getrennt durch. Sehr unbürokratisch, für den Product Owner aber ggf. sehr fordernd.

Hierarchische Skalierungsframeworks

Im deutlichen Kontrast dazu führen hierarchische Skalierungsframeworks wie Scaled Agile Framework (SAFe) und Scrum@Scale oberhalb der Scrum Teams neue Hierarchieebenen ein, SAFe etwa den Product Manager und den Release Train Engineer, Scrum@Scale den Chief Product Owner und den Scrum of Scrums Master [sic]. Bei grösseren Vorhaben ist das nochmal erweiterbar, für weitere Hierarchieebenen können nochmal weitere Rollen geschaffen werden.

Dynamische / Fluide Skalierungsframeworks

Dynamische Ansätze wie FAST (Fluid Agile Scaling Technology) und Unfix stellen die Idee des crossfunktionalen und autonomen Teams in den Mittelpunkt. Bei grossen oder komplexen Produkten kann es sein, dass eine solche Einheit deutlich mehr als die üblichen zehn Personen umfassen muss. Um trotz dieser Grösse agil bleiben zu können ist es vorgesehen, dass sich innerhalb dieser stabilen Einheiten Untereinheiten je nach Bedarf bilden und wieder auflösen können. Quasi ein agiles Organigramm.

Kanban-Skalierungsframeworks

Aufgrund der "Open Source-Natur" von Kanban sind die Skalierungs-Möglichkeiten in diesem Bereich sehr wenig formalisiert, bzw. sehr individuell. Die grundlegende Idee ist aber eine Optimierung des Arbeitsflusses oder Wertstroms. Skalierung bedeutet in diesem Sinn, dass Umfang oder Anfangs- und Endpunkt des Wertstroms immer weiter definiert werden, etwa durch Einbeziehung von Zulieferern oder Parallel-Fertigungen. Bestehende Rollen und Hierarchien bleiben dabei zunächst unverändert.

Kommunikationsorientierte Skalierungsframeworks

Ähnlich wie bei den Kanban-Skalierungsframeworks verzichten kommunikationsorientierte Ansätze wie Flight Levels oder Open Space Agility zunächst auf neue Rollen und Strukturen. Stattdessen werden übergreifende Abhängigkeiten für alle sichtbar visualisiert (Flight Levels) oder in Grossgruppen-Formaten regelmässig mit allen Beteiligten besprochen (Open Space Agility). Basierend darauf können dann Kommunikation und Zusammenarbeit dort stattfinden wo es Sinn macht.

Sonstige Skalierungsframeworks

Über die gerade gennten agilen Skalierungsansätze hinaus gibt es auch weitere die immer wieder genannt werden, u. a. das so genannte "Spotify Model" und organisationsweite Objectives and Key Results (OKRs). Bei ihnen handelt es sich aber nicht um agile Skalierung im eigentlichen Sinn, sondern eher um eine kreative Neubenennung klassischer Organisationsprinzipien (Spotify = Matrix-Organisation, organisationsweite OKRs = Zielkaskadierung). Auch ok, nur ein anderes Thema als das hier.

Soviel zur Übersicht - aber was kann man jetzt mit ihr machen?

Eine guter Einsatzmöglichkeit ist, vor (!) dem Beginn einer wie auch immer gearteten agilen Skalierung zu überprüfen, welche dieser Grundmuster in der eigenen Organisation vermittelbar wären. Sind beispielsweise Scrum oder Kanban auf Teamebene gesetzt? Dann machen diese Ansätze vermutlich auch in der Skalierung Sinn. Wird Wert auf Hierarchien gelegt? Dann passen SAFe und Scrum@Scale. Soll maximale Flexibilität möglich sein? Dann passen die dynamischen Skalierungsframeworks besser.

Was durch ein derartiges Vorgehen möglich wird, ist eine Lösung die zur Aufgabenstellung passt, statt einer Lösung an die die Aufgabenstellung angepasst werden muss. Denn so merkwürdig es klingt - Variante zwei ist zur Zeit noch verbreiteter als Variante eins. Das umzudrehen kann nur im Interesse aller Beteiligten sein.