Die Skalierungs-Grenzen in SAFe®

SAFe® sagt in der Theorie: Ein Agile Release Train (ART) besteht aus 50 bis 125+ Mitgliedern. Was passiert unter 50 Mitgliedern? Über den 125+ haben wir die Large Solution. SAFe sagt nichts zum Thema, wie gross das Maximum für eine Large Solution ist. Gibt es ein Maximum? All diese Fragen, möchte ich, Niko Kaintantzis, mit meinem Kollegen Wolfgang Brandhuber diskutieren.

Die 125+ kommt bekannterweise von Dunbars-Number, benannt nach dem Anthrophologen Robin Dunbar [1] und beschriebt die theoretische „kognitive Grenze“ der Anzahl an Menschen, mit denen eine Einzelperson soziale Beziehungen unterhalten kann. Darüber ist es schwierig, alle gut zu kennen. Im Allgemeinen betrage die Zahl 150, wobei die Anzahl der Freunde individuell zwischen 100 und 250 schwanken könne.

Wolfgang, du bist der Experte für Large Solutions, gibt es eine Grenze für Large Solutions?

Die Large Solution ist nur ein Container in SAFe®. Der Container ist nach oben offen. Die Frage ist: Wie viele Leute kann ich idealerweise in einem Solution-Train koordinieren? Irgendwann bricht die Mechanik zusammen. Die nächste Skalierungsstufe nach 150 endet meiner Meinung nach bei 500.

Wie kommst du auf diese Zahl?

Zu Dunbar gibt es diverse Artikel, die diese Grenze von 500 beleuchten.

Beim römischen Heer ist 500 eine typische Grösse für eine Kohorte. Dies ist die grösstmögliche taktische Einheit. Im Gegensatz dazu die Legion mit etwa 5'000 Menschen, welche aber eine Verwaltungseinheit ist.

Römisches Heer hört sich nach vielen Jahren Erfahrung und Geschichte an. Hatten die Römer auch so etwas wie RTEs und STEs?

Da gibt es viel zu erzählen... Stark vereinfacht und mit SAFe-Begriffen: Die Release Train Engineers (RTE) bestimmten wer von ihnen auch Solution Train Engineer (STE) ist. Dies ist aber kein zusätzlicher Titel. Die Römer waren sehr gut beim De-Skalieren.

SAFe hat auch eine untere Grenze von 50. Ich sage meinen Kunden immer SAFe hat Events, Rollen und Artefakte, die sich erst ab einer bestimmten Grösse lohnen. Wie erklärst du diese untere Grenze?

Die Grundfrage betrifft die Wirksamkeit: Wo hört die Selbstorganisation auf? Angenommen ich habe zwei Scrum-Teams [2] mit acht Leuten, die eine Webseite betreiben. Die beiden Teams können sich gemeinsam koordinieren. z.B. mit Pair-Programming zwischen den Teams oder einer gemeinsamen Planung. Das kann man fussmässig erledigen. Das ist keine Rocket-Science. Da braucht es keinen Chef und keinen Prozess-Overhead. Auch bei drei Teams kann man sich eine solche Zusammenarbeit vorstellen, auch wenn es aufwendiger wird. Mit jedem Team nehmen die Reibungsverluste zu. Ich würde behaupten: exponentiell. Bei vier Teams ist der Kollaborationsbedarf unterschiedlich. Er muss dynamisch angepasst werden. Können diese Teams ein gemeinsames Optimum finden? Bei geeigneten Rahmenbedingungen, wie örtlicher Nähe, kann es mit Performance-Verlust funktionieren.

Mit fünf Teams und da bin ich bei 50 Personen braucht es einen starken gemeinsamen Business Value respektive eine gemeinsame Aufgabe. Im Beispiel der römischen Armee:

👉Sicherung des Brückenkopfs

👉Eroberung des Hügels

Diese gemeinsame Aufgabe erleichtert die Koordination, da jeder auf diese Aufgabe fixiert ist.

Ist dies nicht vorhanden oder geht man darüber, braucht es andere Organisations-Mechanismen.

Wie koordinierst du diese bis zu maximal vier bis fünf Teams?

Die Magie ist, die vorhandenen Dinge wie Scrum Rollen, Events und Artefakte geeignet zu synchronisieren. Ich lasse es bewusst offen, was geeignet bedeutet und betone die Wichtigkeit der Synchronisation. Es ist ein dynamischer Prozess. Wir müssen hier adaptieren können.

Hast du Beispiele dazu?

Als Beispiel für regulierten Kommunikations- und Kollaborations-Bedarf kann das PI Planning angesehen werden. Es hat seinen Wert, ist aber starr. Unregulierte Kommunikation und Kollaboration ist aber genauso wichtig. Wenn diese Art aber zu stark zunimmt, laufen die Leute nur noch herum und erzählen irgend etwas. Ökonimsch wird es sinnvoll bestimmte unregulierte durch regulierte Abläufe zu ersetzen.

Bei einer Large-Solution musst du ebenfalls weg kommen von vielen dieser starren resp. statischen Prozess-Modelle und dynamisch über die Zeit anpassen. Prozess-Manager kriegen hier Angst.

Gibt es Patterns, wie man diese Dynamik strukturiert hinkriegt, damit die Angst reduziert wird?:

🚀 Meine Erfahrung: Über die Events (statt über Rollen und Artefakte) kriegst du es am schnellsten hin.

💥 Das Schwierigste ist: Die Leute sind überfordert beim Identifizieren ihres Kommunikationsbedarfs.

Sie haben sich aufgrund ihrer Grösse und darauffolgenden Regulierungen an die Kommunikations- und Kollaborationsmechanismen gewohnt. Es bereitet Mühe herauszufinden, wieso gewisse Meetings notwendig sind. Rauskommen aus der Prozessgläubigkeit hin zu "wir sind eine selbstverwaltende Einheit" ist der Antrieb.

Wenn das Alignement da ist, gilt es zu klären, welche Teile der Large Solutions für welche Scrum-Events zusammengehören. Diese fasse ich zusammen zu – wie ich sie nenne – Solutions Areas. Sie umfassen maximal 4 bis 5 Teams und werden wieder nach Aufgabe respektive Business Value gruppiert; wie vorher beschrieben. Es kann helfen, herauszufinden, welche Teams den höchsten Kommunikations- und Kollaborationsbedarf haben und diese zusammenzufassen.

Unser letzter Newsletter hatte den Arbeitstitel "SAFe+". Dieser hat mich zu diesem Interview mit dir inspiriert. Wo siehst du das Plus, das KEGON einbringt?

Das ist einfach. Das Plus ist De-Scaling – oder "bedarfsgerechte Skalierung". Du kannst nicht Large Solultion machen ohne Descaling. Nur Leute dazu nehmen ist nicht die Lösung. Wie kann ich die Skalierungsmechanismen geringhalten? Wie kann ich die 500 Mitarbeiter mit möglichst wenig Aufwand koordinieren? Dies sind die Kernfragen.

Welche Grenzen von SAFe bist du gerade dabei zu überwinden?

Die Grenze ist die Closed Form. In der Physik passen Relativitätstheorie & Quantenmechanik nicht zusammen: Man sucht nach einer Theorie, in der beide Theorien ihren Platz finden; diese Theorie ist die Closed Form. Man hofft, sie zu finden.

SAFe hat einen so grossen Markterfolg, weil das Framework ein Closed Form in der skalierten Agilität gebildet hat. Das Framework funktioniert ohne ihre Erfinder. Es funktioniert ohne ein Genie als Mastermind.

Meine Herausforderung ist nun:

🎯Gibt es eine Closed Form, die man zwischen zwei Buchdeckel pressen kann und die jeder für sich und sein Unternehmen implementieren kann, für Large Solution? Ich glaube daran.

Es gibt sie und wir müssen sie nur strukturieren, auch wenn dynamische und bedarfsgerechte Skalierung völlig anders aussieht als statische Frameworks. Dabei geht es eher um Leitplanken zur Selbstorganisation als um Prozessmodelle. Daran arbeite ich.