Scrum skalieren, aber richtig – Welches ist das beste Framework? || Agile Series – Episode 12

In diesem Artikel erklären wir nach welchen Kriterien man ein skaliertes Scrum-Framework aussuchen sollte und stellen dir LeSS (Huge), Nexus (+), Scrum of Scrums und SAFe kurz vor. Auf die Frameworks an sich werden wir in späteren Artikeln noch genau im Detail eingehen, also unbedingt den Newsletter abonnieren.

Am Schluss sagen wir noch, welches der Frameworks unserer Meinung nach – das beste Framework ist um Scrum richtig zu skalieren.

Hierbei bitte immer bedenken, dass das beste Framework abhängig von deiner Situation im Unternehmen ist und eine erste Analyse von erfahrenen Coaches sehr sinnvoll ist, bevor man einfach skaliert.

In der letzten Folge haben wir das erste Prinzip von DevOps, nämlich Flow, erklärt. Dazu haben wir auch über die Theory of Constraints und die Wall of confusion gesprochen.

Schau also unbedingt hier vorbei falls dir das noch nichts sagt und du darüber mehr lernen willst.

Warum und wann sollte man Scrum skalieren?

Eine gute Skalierung erlaubt es uns Themen/Features anzugehen, die ein einzelnes Team gar nicht erst hätte liefern bzw nur sehr spät liefern könnte.

Auch erlaubt uns eine gute Skalierung Features schneller abzuschließen, um sich dann auf neue Features und Innovationen konzentrieren zu können.

Ein weiterer Vorteil kann ein schnellerer Return on Invest (ROI) sein.

Hierbei müssen wir beachten, dass auch alle Probleme mitskalieren werden. Diese wollen wir natürlich nicht skalieren oder im Idealfall sogar verringern. Dazu gehören:

• Chaos
• Barrieren/Silos
• Verschwendung
• Abhängigkeiten

Um dies negativen Effekte der Skalierung zu verhindern, muss der Fokus klar auch auf diesen Themen sein. Am einfachsten ist das natürlich mit Coaches, die sich darüber im Klaren sind und hierbei unterstützen.

Aber was genau wollen wir dann skalieren?

Damit die Skalierung funktioniert und sich selbst trägt ist der wichtigste Faktor, dass wir den Wert, den wir den Kunden liefern, und damit auch die Qualität skalieren können. Wenn wir nämlich nicht mehr Wert liefern als vorher ist der ganze Sinn der Skalierung verloren.

Was wir dafür benötigen ist, dass wir Kommunikation und Zusammenarbeit zwischen und mit den Teams skalieren und das vor allem effektiv. Denn kein Teammitglied hat gerne auf einmal 10 Meetings mehr, in denen er oder sie  nur rum sitzt.

Das heißt also auch bestimmte Strukturen zu skalieren und genau hier kommt das passende  Skalierungsframework für Scrum ins Spiel.

Die wichtigsten Kriterien für die Wahl des skalierten Scrum Frameworks:

Als allererstes müssen wir einen grundlegenden Gedanken verstehen, der aber essentiell ist, um erfolgreich zu skalieren.

„Wachstum“ ist nicht das gleiche wie „Skalieren„!!

Einfach nur mehr Leute für die Bearbeitung eines Problems oder die Entwicklung eines Produkts hinzuzufügen bedeutet nicht skalieren. Das Problem ist, dass wenn man skaliert auch alle Probleme skaliert werden. Das heißt wir dürfen uns nicht davon ablenken lassen das eigentliche Problem (das uns z.B. an der Erreichung unseres Sprint– oder Produkt–Ziels hindert) aufzudecken und zu lösen.

Die häufigsten Probleme hierbei sind fehlende/schlechte Kommunikation, unkoordinierte Zusammenarbeit und ein fehlendes Ziel/Roadmap. Aber dazu später mehr.

Wenn man Scrum wirklich skalieren will, ist das wichtigste Kriterium auch effektiver (nicht effizienter! Warum das so wichtig ist erklären wir noch in einem späteren Artikel, also unbedingt den Newsletter abonnieren 😉 ) zu werden und nicht einfach mehr Leute, Silos und mehr Schichten hinzuzufügen. Ein wichtiger Punkt ist klar den Grund zu kennen (Why) für die Skalierung. Das ist wie bei allen Change Prozessen, sei es eine Transformation, Umorganisierung, etc., wenn wir klar verstanden haben, warum etwas passiert, können wir bessere Entscheidungen treffen der Unterschied ist „ja“ zu sagen vs „nein“.

Wie auch bei Transformationen, ist die Skalierung an sich nicht das Ziel, sondern der Weg zum Ziel wie z.B. mehr Features abzuschließen und somit neue, innovative Features entwickeln zu können.

Kommen wir aber nun zu den Kriterien für die Auswahl des richtigen skalierten Scrum-Frameworks.

1.) Sei dir im klaren, was du skalieren willst!

Dein Ziel kann es sein Kontrolle zu skalieren oder aber auch bottom-up Intelligence, sodass die Entscheidungen da getroffen werden können, wo das wissen ist. Sei dir ganz klar, was du willst.

2.) Das Framework muss einfach zu verstehen und anzuwenden sein.

Ein Framework oder Tool, das niemand versteht, wird zwangsläufig nie oder falsch benutzt werden. Dadurch entsteht Chaos und Verwirrung, die uns daran hindern das eigentliche Ziel zu erreichen.

3.) Das Framework sollte Anpassungen an dein spezifisches Unternehmen zulassen

Das Framework sollte unbedingt Raum für Anpassungen an dein Unternehmen und deine Umgebung zulassen, da kein Unternehmen genau gleich ist und die gleichen Erfahrungen und Leute hat.

4.) Das Framework sollte konsistent sein, mit Single-Team Scrum

Um auch hier keine weiteren Verwirrungen oder Widersprüche zu erzeugen und damit auch das Wissen der bereits agilen Mitarbeitern effektiv nutzen zu können für die Skalierung, muss das Skalierungsframework unbedingt konsistent mit Scrum für ein Team sein.

Jetzt wo du die wichtigsten Kriterien kannst können wir uns den verschiedenen Skalierungsframeworks widmen.

LeSS (Huge)

Large Scale Scrum (LeSS bzw. LeSS Huge) ist unserer Meinung das simpelste Skalierungsframework, das es für Scrum gibt. Es beschränkt sich hierbei wirklich nur auf die minimalsten Meetings und Vorgaben, die nötig sind, um Scrum zu skalieren. Das macht es sehr einfach zu verstehen und einzuführen, da nicht viel Änderungen gemacht werden müssen und auch kaum neue Meetings dazu kommen.

LeSS gibt es in zwei Versionen. Einmal LeSS für 2-8 Teams.

Aufbau & Ablauf von LeSS für bis zu 8 Entwicklungsteams Quelle: https://less.works/resources

Hier gibt es nur ein Produkt und damit auch nur einen Produkt Owner.

Will man nun skalieren mit mehr als 8 Teams, so gibt es auch LeSS Huge.

Aufbau & Ablauf von LeSS Huge ab 8 Entwicklungsteams Quelle: https://less.works/resources

Abhängig vom Unternehmen und der Anzahl an Produkten macht es auch Sinn bereits früher auf LeSS Huge zu wechseln.

Die beiden Bilder stellen die grundlegenden Bestandteile von LeSS sehr gut dar. So koordinieren sich die Teams eines Produkts immer zu Anfang eines Sprints im Sprint Planning 1 und am Ende eines Sprints im Review bzw der Overall Retrospektive.

Koordinierung zwischen den Teams findet je nach Bedarf während des Sprints statt, ist aber nicht vorgeschrieben.

Die anderen Elemente von Scrum bleiben aber erhalten. So gibt es weiterhin das Daily Scrum eines jeden Teams und auch jedes Team hat seine eigene Team Retrospektive.

In LeSS Huge kommen dann nur noch die Area Product Owner (APO) dazu, die für eine bestimmte Teilmenge der Teams (die gemeinsam an einem Produkt arbeiten) verantwortlich sind. Der Product Owner steuert hierbei wiederum die Priorisierung der Themen der APOs.

LeSS hat unserer Meinung nach aber auch bestimmte Nachteile, da es an hier an bestimmten Stellen an effektiver Kommunikations- und Zusammenarbeitsmöglichkeiten fehlt und die Integration der Arbeit der einzelnen Teams in ein funktionsfähiges Produkt fehlt.

Scrum@Scale bzw. Scrum of Scrums

Dieses Framework wurde von Jeff Sutherland und Scrum Inc. entwickelt, um Scrum für mehrere Teams zu skalieren.

Ziel ist es eine lineare Skalierbarkeit, minimal nötige Bürokratie (Minimum Viable Bureaucracy (MVB)) und die Fokussierung von Netzwerken aus mehreren Scrum Teams mit klar priorisierten Zielen zu erreichen.

Grundlage dafür sind einmal der Scrum Master Cycle („WIE“ etwas gemacht wird) und der Product Owner Cycle (Das „WAS“ gemacht wird).

Scrum@Scale Quelle: https://www.scrumatscale.com/scrum-at-scale-guide-online/

Die Skalierung der Teams funktioniert in diesem Framework mit Hilfe der sogenannten Scrum of Scrums (SoS). Dabei hat jedes Team einen Product Owner und einen Scrum Master. Gedanke hierbei ist es den Fluss der Arbeit zu maximieren und Kundenfeedback-Schleifen so kurz wie möglich zu halten.

A Scrum of Scrums operates as if it were a Scrum Team – Scrum@Scale Guide

Für noch größere Unternehmen gibt es dann noch das Modell des Scrum of Scrum of Scrums (SoSoS), das aus mehreren Scrum of Scrums besteht. Hierbei gibt es dann noch 2 neue Rollen, nämlich den Scrum of Scrums Master (SoSM) und den Chief Product Owner (CPO), auf die wir hier aber nicht genauer eingehen. Wer mehr dazu wissen will sollte unbedingt den Scrum@Scale-Guide lesen.

Scrum of Scrums für 5 bzw. 25 Teams Quelle: https://www.scrumatscale.com/scrum-at-scale-guide-online/

Ein Pentagon steht in dieser Abbildung für jeweils ein Team aus 3-9 Mitgliedern. Das kleinere hell-graue Pentagon darin steht jeweils für einen Scrum Master und das dunkelgraue Pentagon für den Product Owner.

Vorteile bei diesem Skalierungsframework sehen wir, darin, dass Jeff Sutherland selbst es entwickelt hat und damit auch klar auf dem Scrum-Guide aufbaut und seine Erfahrung eingebracht hat. So betont er im Scrum@Scale Guide häufig, dass das Verständnis für Scrum an sich eine wichtige Voraussetzung für Scrum@Scale ist. Auch ist der Grundgedanke sehr einfach und leicht umzusetzen.

Nachteile sehen wir hier aber auch darin, dass es noch mehr neue Rollen gibt, die alle ähnliche Namen, was zu Verwirrung führen kann. So gibt es z.B. den Scrum Master (SM), den Scrum of Scrums Master (SoSM) und den Scrum of Scrum of Scrums Master (SoSoSM). Ähnlich läuft es beim Product Owner und dann gibt es noch mehr Rollen, wie das Executive Action Team (EAT), das auf Organisationsebene wiederum die Verantwortlichkeiten der Scrum Master übernimmt. Ganz zu schweigen vom Executive MetaScrum (EMS), das dann wiederum die Verantwortlichkeiten der Product Owner auf Unternehmensebene übernimmt. Und wer jetzt beim durchlesen noch nicht genug hat, wird spätestens beim lesen des Scrum@Scale Guides so verwirrt sein, dass es noch schwerer ist dies auch entsprechend an die Teams weiterzugeben.

Noch ein Nachteil den wir sehen ist, dass jedes Team seinen eigenen Product Owner hat, aber wenn diese an einem gemeinsamen Produkt arbeiten, wird es unweigerlich zu Priorisierungsproblemen zwischen den verschiedenen Product Ownern kommen.

SAFe

Das Scaled Agile Framework (SAFe) ist ein unternehmensweites Skalierungsframework für Scrum, das sich besonders für sehr große Unternehmen etabliert hat.

Es gibt vier verschiedene Ausführungen von SAFe, jeweils für verschiedene Skalierungsebenen: Essential SAFe, Large Solution SAFe, Portfolio SAFe und Full SAFe.

SAFe hat auch 10 Lean-Agile Prinzipien, nach denen gehandelt wird. Mehr dazu hier.

Vorteil ist, dass hier klare Strukturen herrschen und auch Konzepte wie Lean und DevOps bereits integriert sind.

Nachteil ist, dass dieses Framework in egal welcher Ausführung auf keinen Fall ein Leichtgewicht ist und nur noch teilweise auf Scrum aufbaut. Das macht es natürlich deutlich komplexer es einzuführen und die ganzen Praktiken, Events und Rollen verständlich zu erklären.

Roadmap für die SAFe Implementierung Quelle: https://www.scaledagileframework.com/implementation-roadmap/

Diese hohe Komplexität wird sowohl an der Roadmap zur Implementierung von SAFe (mit 12 Schritten, die alle sehr groß sind), als auch an der Übersicht über SAFe klar.

SAFe Essential Übersicht Quelle: https://www.scaledagileframework.com/#

Und das ist die Übersicht von SAFe Essential, also die absolute Minimalausführung.

Das Nexus(+)-Framework

Kommen wir nun zu guter Letzt noch zum Nexus-Framework. Dieses Framework wurde von Ken Schwaber und Scrum.org entwickelt und baut also auch sehr auf dem Scrum-Guide auf und es fließen viele Erfahrungen der Scrum-Trainer ein.

Der Gedanke hierbei ist, wie bei LeSS,  möglichst wenig neue Rollen und neue Meetings einzuführen, die es nicht bereits in Scrum gibt. Das wird schon an der sehr simplen Übersicht klar.

Das Nexus Framework Quelle: https://www.scrum.org/resources/scaling-scrum

Wie in der Grafik einfach zu sehen ist, gibt es nur einen Product Backlog und einen Product Owner. Das verhindert die Probleme bei der Priorisierung der Aufgaben, die wir im Scrum@Scale Framework angesprochen haben.

Fokus des Nexus-Frameworks ist es, die gängigsten Skalierungsprobleme mit Hilfe von Empirie und Bottom-Up Intelligence zu lösen. Diese Probleme sind, wie wir bereits weiter oben angesprochen haben, Abhängigkeiten zwischen Teams (intern als auch extern), fehlende Transparenz/Kommunikation, das Aufrechterhalten von self-managing Teams und das Sicherstellen von Verantwortlichkeiten, sonst versuchen wir nämlich wie Asterix den Passierschein A38 zu besorgen und kommen gar nicht zu unseren eigentlichen Aufgaben.

All diese Punkte sind uns schon bei gescheiterten Skalierungen begegnet und  sind deshalb extrem wichtig, im Auge zu behalten und Coaches an der Hand zu haben, die genau diese Probleme kennen.

Aus welchen Elementen besteht Nexus nun?

Wie bereits erwähnt gibt es kaum neue Rollen und Meetings.

Eine sehr wichtige neue Rolle und damit Verantwortlichkeit gibt es allerdings. Das sogenannte Nexus Integration Team, dessen Verantwortlichkeit es ist ein fertiges und vor allem integriertes Inkrement am Ende eines jeden Sprints zu erzeugen. Für diese Integration ist es nötig alle technischen und nicht-technischen Einschränkungen aufzudecken und zu lösen. Dieses Team besteht aus dem (einzigen) Product Owner, einem Scrum Master und mindestens einem Nexus-Integration-Teammember. Diese coachen, beraten und schaffen das Bewusstsein für Abhängigkeiten und teamübergreifenden Probleme und unterstützen bei der Lösung der Probleme.

Events die neu hinzukommen, sind teamübergreifende Refinements, die wiederum dazu dienen Abhängigkeiten aufzudecken und ein gemeinsames Verständnis für die Aufgaben zu schaffen und damit die Kommunikation zu verbessern.

Auch während des Nexus Daily Scrum werden Integrationsprobleme aufgedeckt und Kommunikation zwischen den Teams gefördert.

Als Artefakt kommt z.B. der übergreifende Nexus Sprint Backlog hinzu, der aus dem Product Backlog entsteht. Aus dem Nexus Sprint Backlog ziehen sich die Teams wiederum die Items für deren Sprint Backlog. Er dient dazu Abhängigkeiten und den Fluss der Arbeit klar darzustellen.

Wie bei allen Artefakten geht es hierbei um Transparenz und die Diskussionen, die daraus entstehen und weniger um das erstellen des Artefakts an sich.

Das Nexus Sprint Goal ist das Commitment für den Nexus Sprint Backlog und erzeugt ein gemeinsames Ziel für alle Teams.

Einziger Nachteil, den wir in diesem Framework sehen ist, dass es nicht Praktiken, wie DevOps oder Lean schon eingebunden hat, wie z.B. SAFe. Allerdings liegt das in der Natur von Scrum und scrum.org nur das minimal nötige vorzugeben und den Rest optional zu lassen, um es allen Unternehmen zu ermöglichen die nötigen Praktiken und Tools hinzuzufügen wo es nötig ist. So steht diesbezüglich im Nexus-Guide:

As organizations use Nexus, they typically discover complementary patterns, processes, and practices that help them in their application of the Nexus framework. – Scrum Guide

Alles in allem ist Nexus sehr einfach zu verstehen, baut stark auf Scrum auf und man benötigt daher nur sehr wenige neue Rollen, Events bzw. Artefakte, um das Framework einzuführen. Wichtigstes Merkmal ist, dass die häufigsten Probleme von Skalierungen mit Empirie und Bottom-Up Intelligence gelöst werden, aber weiterhin die Möglichkeit für Anpassungen gegeben sind.

Fazit

Es gibt viele verschiedene Skalierungsframeworks für Scrum, die alle ihre eigenen Vor- und Nachteile haben, aber die gleichen grundlegenden Problem der Skalierung teilen und diese sind extrem wichtig zu kennen und zu beachten.

Wichtig ist für die Skalierung aber nicht nur das Framework, sondern auch wie diese Skalierung durchgeführt wird.

Nail it before you scale it!

Richtig skalieren beginnt also im Kleinen und geht, wenn man es richtig machen will, nicht schnell oder gar in 90 Tagen. Es gibt nämlich für dein Unternehmen keine Blaupause, die man einfach kopieren und ausrollen kann (so eine Art „Spitify-Modell“ 😛 ) und auf einmal ist alles auf magische Art und Weise über Nacht agil.

Auch sollten wir uns im Klaren sein, dass eine Skalierung die Agilität verringern wird. Glücklicherweise ist es in unserer Hand zu entscheiden wie viel geringer die Agilität dadurch wird. Das richtige Framework und Coaches mit dem richtigen Mindset und Motivation machen hier den größten Unterschied.

Unserer Meinung nach ist Nexus-Framework die beste Wahl, da es eine gute Balance hält zwischen Einfachheit und dennoch dem klaren Fokus die Probleme wie Abhängigkeiten, Kommunikation und Zusammenarbeit zu verbessern. Aber wie immer gilt natürlich, dass das beste Framework sehr vom Unternehmen abhängt und man auch die Möglichkeiten zur Anpassung braucht. Aber Nexus ist unserer Meinung ein sehr gut geeigneter Startpunkt für die meisten Unternehmen auf dem Weg zu skaliertem Scrum.

Diese Liste an Skalierungsframeworks ist natürlich nicht vollständig, da hier z.B. noch Disciplined Agile Delivery (DAD) fehlt, aber wir müssen an einer Stelle einfach einen Strich ziehen, da selbst dieser Artikel schon sehr lang ist. Allerdings werden wir in der Zukunft noch einen ausführlichen Artikel zu den Skalierungsframeworks veröffentlichen. Also den Newsletter unbedingt abonnieren 😉 .

Du willst noch mehr wissen und hast noch Fragen oder bist anderer Meinung?

Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!

Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:

Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.

Und auch der ist komplett kostenlos. Du findest den Glossar hier:

Ausblick

In der nächsten Folge erklären wir dir, das 2. Prinzip von DevOps. Es geht also darum, wie man Feedback-Schleifen von den Operations-Leuten zu den Entwicklern verkürzt und verbessert. Dazu werden wir auch über Telemetrie sprechen und wir werden natürlich auch noch verschiedenste Beispiele für Feedback-Schleifen nennen.

Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:

Unser Podcast

Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster bequem unterwegs hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:

Podcast RSS-Feed

Unser YouTube-Channel

Du stehst auf bewegtes Bild und zusätzliche Grafiken und Visualisierungen? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.

Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.

Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.

Wir freuen uns auf dich in der nächsten Folge.

Deine Agile Coach Academy Gründer Ben und Alex