Was ist Skalierung?

Immer mehr Unternehmen möchten ihre agilen Entwicklungen „skalieren“. Damit meinen sie meist, dass heute wenige Personen oder Teams an einem Produkt arbeiten und in Zukunft viele Personen oder Teams an diesem Produkt arbeiten sollen. Manchmal geht es aber auch darum, dass die Erfahrungen eines Teams auf andere Teams, die an anderen Produkten arbeiten, übertragen werden sollen.

Es gibt am Markt eine Vielzahl von Ansätzen, um das „Problem“ der Skalierung zu lösen. Die bekanntesten sind dabei LeSS, Scaled Agile Framework (SAFe), Nexus und Scrum@Scale. Diese haben alle ihre individuellen Vor- und Nachteile. Bevor du nun aber voreilig zu einem Ansatz wie SAFe greifst, solltest du die Grundlagen der Skalierung verstehen. Hier sind unsere fünf goldenen Regeln der Skalierung für dich.

Fünf goldene Regeln

Diese fünf goldenen Regeln gelten grundsätzlich immer bei der Skalierung agiler Entwicklungen. Du kannst sie als Grundregeln verstehen, sozusagen als das „kleine Einmaleins“:

1. Minimiere Abhängigkeiten

Abhängigkeiten zwischen Personen, Anforderungen und innerhalb der Umsetzung erfordern zusätzliche Kommunikation, die mit mehr Beteiligten exponentiell wächst. Das Grundproblem ist es daher, genau diese Abhängigkeiten zu minimieren. Gelingt dies, gelingt auch die Skalierung.

2. Skaliere zum richtigen Zeitpunkt

Im skalierten Kontext wird die Zusammenarbeit nicht einfacher. Im Gegenteil: Die Komplexität steigt und mit ihr die Probleme. Es gibt in diesem Zusammenhang den englischen Ausdruck „shit scales“. Das heißt, wenn man einen dysfunktionalen Zustand dadurch aufzulösen versucht, dass man mehr davon macht, dann muss man sich nicht wundern, wenn man hinterher sehr viel Dysfunktionalität (=scaled shit) hat. Man muss daher zunächst den vorhandenen kleinen Kontext so weit lösen, dass er hervorragend funktioniert. Skaliert man erst dann, profitiert man von den Erfahrungen und skaliert seine Fehler nicht mit.

3. Nutze eine Vielzahl von Methoden

Kein Ansatz, egal ob SAFe, LeSS, Nexus oder Scrum@Scale passt im Regelfall zu 100% auf dein Szenario. Du musst also Grundwissen in all diesen Methoden aufbauen und sie dann so kombinieren, dass ein gutes Ergebnis für deinen Kontext entsteht.

4. Halte dich an agile Prinzipien

Die agilen Grundprinzipien gelten auch im skalierten Kontext. Denke daran, wenn du zusätzliche Managementebenen (z.B. eine Programm- oder Portfolioebene) installierst. Die Führungskräfte sind Vorbild – wenn ihr jetzt also anfangt, auf der Programmebene „Command and Control“ vorzuleben, während ihr auf der Teamebene „Agil“ predigt, dann verliert ihr eure Glaubwürdigkeit und euer agiles Vorhaben scheitert.

5. Setze deinen gesunden Menschenverstand ein

Der gesunde Menschenverstand, auch GMV genannt, ist unerlässlich, wenn du skalierst. Kein Framework wird exakt deinen Kontext antizipert haben, folglich musst du eigene Lösungen finden. Das geht am besten durch Nachdenken, nicht durch planloses Umsetzen eines Skalierungsframeworks.

Wenn du mehr über diese Prinzipien erfahren willst, empfehle ich dir diesen Artikel aus dem Projektmagazin.

Szenarien

Unserer Erfahrung nach gibt es acht Skalierungsszenarien, die immer wieder auftreten.

  1. Ein Team arbeitet gleichzeitig an mehreren Produkten
  2. Es sind unabhängig von der Teamanzahl mehrere Standorte an der Entwicklung beteiligt (virtuelle Teams)
  3. Es arbeiten zwischen zwei und zehn Teams am selben Produkt
  4. Es arbeiten mehr als zehn Teams am selben Produkt
  5. Es arbeiten zwei bis zehn Teams ohne Abhängigkeiten an verschiedenen Produkten
  6. Es arbeiten zwei bis zehn Teams mit Abhängigkeiten an verschiedenen Produkten
  7. Es arbeiten mehr als zehn Teams mit Abhängigkeiten an verschiedenen Produkten
  8. Der Entwicklungsbereich des Unternehmens arbeitet agil und jetzt soll der Rest der Organisation folgen

Im Folgenden gebe ich dir ein paar Tipps, was du in diesen Szenarien beachten solltest.

1. Ein Team arbeitet gleichzeitig an mehreren Produkten

Ich persönlich würde das nicht als „Skalierung“ bezeichnen. Es ist einfach nur Multitasking. Im agilen Bereich versuchen wir das zu vermeiden, aber in manchen Kontexten (z.B. im IT-Betrieb) geht das leider nicht. Dort setzt man meist Kanban oder KanScrum ein, was auch recht gut funktioniert. In der Produktentwicklung hingegen ist Multitasking äußerst schädlich. Die Mitarbeiter verlieren ihren Fokus und Produktivität durch das Task-Switching. In Scrum würde man ein solches Szenario dadurch zu lösen versuchen, dass man produktspezifische Sprints definiert, idealerweise mehrere hintereinander. Also arbeiten wir zum Beispiel drei Sprints an Produkt A und danach einen Sprint an Produkt B, bevor wir dann zwei Sprints an Produkt C werkeln. Besonders gut ist das aber nicht: Besser wäre es, den Grund für das Multitasking abzustellen.

2. Es sind unabhängig von der Teamanzahl mehrere Standorte an der Entwicklung beteiligt (Virtuelle Teams)

Virtuelle Teams sind spätestens seit der Corona-Pandemie in der Praxis sehr häufig anzutreffen. Die Skalierung erstreckt sich hier auf die Dimension der Standorte, bzw. auf die Entfernung der Teammitglieder zueinander. Zunächst empfehle ich dir, nicht nur Personalkosten in deine Entscheidung einzubeziehen, sondern auch Reibungsverluste und konkreten Outcome der Teams. Oft rechnet sich die Virtualisierung der Teams dann nicht mehr. Falls du trotzdem virtuell arbeiten möchtest, musst du die „Virtuelle Distanz“ reduzieren. Was das ist, erklären wir in einem späteren Blog-Post. Du kannst dazu aber auch das Buch „Uniting the Virtual Workforce“ von Karen Sobel Lojeski und Richard R. Reilly lesen.

3. Es arbeiten zwischen zwei und zehn Teams am selben Produkt

Die Arbeit von mehr als einem Team am gleichen Produkt ist das, was meist gemeint ist, wenn von „Skalierung“ gesprochen wird. In der Praxis braucht es bei zwei Teams selten zusätzliche Maßnahmen, da die Mitglieder sich noch gegenseitig kennen und einfach miteinander sprechen, wo nötig. Das gilt besonders, wenn alle im gleichen Raum sitzen. Ab drei Teams muss man sich allerdings über ein paar Faktoren Gedanken machen:

  • Rollen – welche sind notwendig und wer füllt sie aus?
  • Wissenstransfer – wie erhalten alle die Informationen, die sie benötigen?
  • Meetings/Events – welche Meetinginfrastruktur benötigen wir?
  • Artefakte – welche Artefakte benötigen wir, wo sind sie zu finden und wer hat Zugriff darauf?
  • Qualität – wie können wir eine gemeinsame, hohe Qualität für unser Produkt garantieren?
  • Architektur – welche Produktarchitektur benötigen wir, damit diese Anzahl Personen sinnvoll daran arbeiten kann?
  • Entwicklungswerkzeuge – sind bei dieser Anzahl Personen die vorhandenen Werkzeuge noch geeignet und ausreichend?
  • Codier-Richtlinien – arbeiten wir nach den gleichen Standards?
  • Teamregeln – welche Regeln helfen uns, als Team im Alltag mehr Spaß zu haben und erfolgreicher zu sein?

Bei all diesen Fragestellungen kann die fünfte goldene Regel (der GMV) helfen.

Unsere Empfehlung ist, auf Hierarchien wo immer möglich zu verzichten. Beispielsweise sind ein „Chief Product Owner“ oder ein „Super Scrum Master“ nur selten wirklich hilfreich und verkomplizieren die Arbeit nur. Außerdem bringen sie ein Command-and-Control-Element in die Organisation, das wir ja eigentlich abschaffen wollen. Auch bei den übrigen Aspekten solltest du dich unbedingt an die vierte goldene Regel erinnern und dich an agile Prinzipien halten.

4. Es arbeiten mehr als zehn Teams am selben Produkt

Unserer Erfahrung nach funktionieren die Lösungen, die bei weniger als zehn Teams gute Erfolge produziert haben, selten bei mehr als zehn Teams, plus minus. Persönlich präferiere ich kleinere Umgebungen, da die durchschnittliche Leistung pro Team höher ist und man weniger Kommunikationsinfrastruktur, Rollen, etc. braucht. Welche Lösung genau für deinen Kontext geeignet ist, hängt vom – du ahnst es schon – Kontext ab. Es gibt definitiv keine Blaupausen mehr für diese Größenordnung. Allerdings empfehle ich dringend, die betroffenen Personen früh in die Lösungsfindung einzubeziehen und statt Kontrollhierarchien auf „dienende Führung“ mit einem hohen Involvierungsfaktor zu setzen. Die vielen Teams auf dem Weg zu einer eigenen Lösung zu unterstützen, funktioniert mittelfristig besser, als ein scheinbares Optimum von oben vorzugeben. Wenn ihr euch an etablierten Frameworks orientiert, reflektiert sehr sorgfältig zu jedem einzelnen Aspekt. Der Schaden könnte sonst am Ende größer sein als der Nutzen.

5. Es arbeiten zwei bis zehn Teams ohne Abhängigkeiten an verschiedenen Produkten

Wenn mehrere Teams keine Abhängigkeiten haben, dann würde ich persönlich nicht von „Skalierung“ sprechen. Man hat dann ein Umfeld, in dem einige Teams unabhängig voneinander Scrum (oder andere agile Methoden) einsetzen. Um Wissensverluste zu vermeiden kann man über eine Stabsstelle (z.B. ein „Transition Team“ oder ein „Agile Project Management Office“) nachdenken. Ansonsten gilt es, jedes Team für sich zu betrachten und zu optimieren.

6. Es arbeiten zwei bis zehn Teams mit Abhängigkeiten an verschiedenen Produkten

Verschiedene Produkte aber viele Abhängigkeiten – das treffen wir häufig in unserer Beratungspraxis an. Hier geht es nicht primär darum, viele Teams auf einer Codebasis zu verwalten, sondern um die Schnittstellen dazwischen. Das können zum Beispiel die Schnittstellen zwischen verschiedenen Abteilungen sein, die benötigt werden, um ein Produkt fertigzustellen. Vermutlich koordiniert ihr diese Schnittstellen schon lange und nehmt es ggf. gar nicht mehr wahr. Der Unterschied mit agilen Methoden und Scrum ist, dass ihr nicht länger in Abteilungssilos arbeitet, sondern interdisziplinäre Teams habt (wenn ihr diese nicht habt, solltet ihr da anfangen nach Verbesserungen zu suchen). In der agilen Welt bedeutet das auch, dass jedes Team dort die anderen Produkte verändern darf, wo die Abhängigkeiten bestehen – solange das Wissen und die Fähigkeiten dazu vorhanden sind. Natürlich darf dabei nichts „kaputt gehen“. Automatisierte Regressionstest sind hier absolut sinnvoll. Ob eure Probleme durch Communities of Practice, „Scrum of Scrums“ oder einen anderen Ansatz gelöst werden, wissen wir nicht. Das ist auch unerheblich: Setzt euch mit den Betroffenen zusammen und findet zunächst heraus, was das wirkliche Problem ist. Erst dann solltet ihr anfangen euren GMV auszupacken und nach Lösungen zu suchen. Übertreibt es dabei nicht mit der Komplexität: Mehrere Produkte durch mehrere Teams zu skalieren muss keine Raketenwissenschaft sein. Manchmal reicht schon eine winzige Änderung in den Rahmenbedingungen, damit es besser läuft.

7. Es arbeiten mehr als zehn Teams mit Abhängigkeiten an verschiedenen Produkten

Hier gelten die gleichen Regeln und Prinzipien wie oben. Im Normalfall haben nicht alle (z.B. 50) Teams Abhängigkeiten. Vor allem dann nicht, wenn sie wirklich interdisziplinär aufgesetzt sind. Daher ist das auch nicht wesentlich schwieriger als 2-10 Teams zu koordinieren. Anders sieht es aus, wenn man in der Vergangenheit selbst verpflichtende Abhängigkeiten geschaffen hat. Zum Beispiel begegnen mir ab und an „Framework-Teams“, die zum zentralen Flaschenhals für alle werden und die alleinigen Zugriffsrechte auf Basiscode haben. Auch gängig sind „Core Product“-Teams, die sich damit beschäftigen, die Sünden der Vergangenheit zu verwalten – oft, weil die Entwickler in diesen Teams als einzige in der Lage sind, den alten Code zu verstehen und anzupassen. Eine große Hypothek für jedes Unternehmen.

Wenn du solch ein Szenario in deinem Alltag findest, dann hast du die goldene Regel 2 verletzt und Mist skaliert. Kein Prozess und kein Framework kann dich aus dieser Lage befreien. Zunächst musst du die Grundursache abstellen. Das wiederum ist harte Arbeit und nicht Teil der Skalierung, sondern gehört zum Themengebiet des „Organizational Change“.

8. Der Entwicklungsbereich des Unternehmens arbeitet agil und jetzt soll der Rest der Organisation folgen

Auch diese Frage gehört eher in die Domäne des „Organizational Change“ als zu Skalierung. Allerdings ist die Motivation oft eine skalierungstypische: Man möchte Erfolge und Erfahrung für größere Teile des Unternehmens zugänglich machen. Das ist super! Das Vorhaben ist allerdings sehr groß (siehe auch Scrum – Einführung in der Unternehmenspraxis). Die Super-Schnell-Einführung (frei nach John Kotter‘s „Leading Change“) ist, dass zunächst alle Beteiligten ein Gefühl der „Dringlichkeit“ besitzen, woraufhin die Veränderung getrieben und zudem unterstützt wird. Das ist dann gegeben, wenn der Nutzen des Neuen größer ist als der Nutzen des Alten und die Gefahren des Neuen kleiner sind als die Gefahren des Alten. Auf dieser Basis könnt ihr gemeinsam Lösungen erarbeiten und Erfolge generieren. Diese Erfolge motivieren und beweisen, dass ihr auf dem richtigen Weg seid. Haltet euch darüber hinaus an die fünf goldenen Regeln oben und bildet euch zum Thema „Organizational Change“ fort, dann stehen eure Chancen sehr gut.

Fazit

Dieser Artikel ist nur eine kurze Übersicht zum Thema Skalierung. Um die richtigen Antworten für genau deinen Kontext zu finden, wirst du vermutlich noch viel lesen und lernen müssen. Ein guter Anfang ist es, sich an die goldenen Regeln zu halten und nur für wirklich existierende Probleme Lösungen zu definieren. Das unreflektierte Übernehmen einer umfänglichen Lösung ist selten eine gute Idee!