Agile Skalierungsframeworks sollen eine Möglichkeit bieten, mit mehreren Teams in einem agilen Setting an einem (manchmal auch mehreren) Produkten zusammenzuarbeiten. Die meisten dieser Skalierungsframeworks haben einen bestimmten Fokus, der mit Ihren Zielen und Herausforderungen übereinstimmen muss, um eine sinnvolle Anwendung zu ermöglichen.
Was sind Skalierungsframeworks?
Ich bezeichne im Folgenden alles als Skalierungsframework, welches sich mit mehreren Teams befasst, die an einem oder mehreren Produkten arbeiten.
Make oder Buy Entscheidungen
Bei jeder Art von Skalierung stellt sich die Frage, ob Sie einen eigenen Weg einschlagen wollen oder nicht. Klar, eigene Wege kosten Zeit, sind dafür aber sehr gut auf die eigene Organisation abgestimmt, wenn der richtige Weg eingeschlagen wird. Sie können mit einem reinen Scrum starten und sich Ihre Skalierung erarbeiten und organisch wachsen.
Häufig ist es natürlich bereits so, dass Sie nicht alleine mit Ihrem konkreten Weg sind. Vor Ihnen haben sich bereits Menschen, Teams oder Organisationen sich mit ähnlichen Fragestellungen herumgeschlagen. Von diesen können Sie zwar nie etwas 1:1 kopieren, sich aber sehr wohl bestimmte Muster abschauen oder versuchen emergente Praktiken abzuleiten.
Anstelle sich also alles selbst zu überlegen (make), übernehmen Sie etwas (buy), was so oder in ähnlicher Form schon auf dem Markt existiert. Und hier kommen die Frameworks ins Spiel. Einige werden Ihnen dabei nützlich sein, andere weniger.
Skalierungsframeworks sind Teilabbildungen auf die Realität
Alle Modelle sind falsch aber einige nützlich. Modelle sind immer eine Vereinfachung der Realität bzw. stellen eine bestimmte Sicht darauf zur Verfügung. Lassen Sie uns dazu ein Beispiel aus der Realität nehmen, das jeder kennt: eine Stadt wie München.
München ist nun unser System, unsere Realität in der wir etwas tun wollen. Es wird schnell klar, dass Sie München als Realität nicht 1:1 abbilden können. Sehr viele Informationen, also praktisch alle des System umfassenden Informationen können Sie nie greifen. Deswegen arbeiten wir immer mit Modellen (einen großen Elefanten essen Sie ja auch nicht am Stück, sondern schneiden ihn in kleine Teile).
Nehmen wir uns nun aber einen Teilbereich aus München heraus. Sagen wir, Sie interessieren sich für Kino. Was machen Sie dann? Wahrscheinlich ist der Griff zur Kinozeitschrift oder zur Webseite des Kinos eine gute Wahl. Das ist nichts anderes, als eine Abbildung in einem bestimmten Modell. Wenn Sie sich aber den Fokus nicht auf dem Kino haben, sondern auf der Kanalisation von München, dann werden Sie nicht auf die Idee kommen, sich das Kinoprogramm anzusehen.
Ob der Vergleich nun etwas hinkt oder nicht, Fakt ist, dass immer wieder Modelle (also hier Skalierungsframeworks) auf Situationen, Probleme oder Herausforderungen losgelassen werden, für die sie nicht gemacht ist. Dann kann das Ganze - wie beschrieben - nicht funktionieren. Ebenso sind Rahmenbedingungen und ein entsprechender Kontext unbedingt mit zu berücksichtigen.
Auswahl bekannter Skalierungsframeworks
Scrum@Scale
Scrum@Scale ist das von Scrum Gründer Jeff Sutherland entwickelte Skalierungsmodell, welches sich auf die organische Entwicklung von Organisationen stützt. Die Scrum Alliance und Scrum Inc. arbeiten zusammen. Jeff nutzt die Grundlagen von Scrum und hat nur wenig um dieses Framework für die Skalierung erstellt.
Large Scaled Scrum (LeSS)
Das LeSS Framework ist das von Craig Lairmann und Bass Vode entwickelte Skalierungsmodell. Die Scrum Alliance hat sich zu diesem Modell schon etwas länger bekannt, gerade wenn es um Softwareimplementierungen geht. Craig und Bass legen sehr viel Wert auf Experimente. Sie haben viele Erfahrungen durch selbst durchgeführte Experimente gelernt. Diese gegeben Sie ebenfalls in Büchern weiter.
Scaled Agile Framework (SAFe)
Dean Leffingwell hat mit dem Scaled Agile Framework ein weiteres Skalierungsmodell entworfen. Dieses Modell ist mit Sicherheit das umfangreichste Skalierungsframework, dass es gibt. Es existiert eine Internetseite und detaillierte Ausarbeitung von Material und Referenzen. Aus dem reinen, eigenen Empfinden ist das eines der umstrittenen Modelle, allerdings müssen wir auch das in Ruhe und detailliert betrachten, um eine Aussage überhaupt treffen zu können.
Aus der eigenen Erfahrung kann ich sagen, dass viele Organisationen das Modell bereits kennen und es eine hohe Verbreitung besitzt. Viele Kunden aus der Automobilzulieferer Industrie und auch Automobilhersteller kennen dieses Modell und es wird oft genannt, auch wenn nur Teile oder Ausschnitte genutzt werden.
Anzumerken bleibt aber noch, dass in diesem Framework viele Dinge Einzug gefunden haben, die nichts mit dem Framework selbst zutun haben. So haben Lean Start-Up, DevOps oder auch Verzögerungskosten Einzug in das Framework gehalten.
Nexus
Nexus ist das von Ken Schwaber entwickelte und von der Scrum.org präferierte Skalierungsmodell. In meinen Projekten und meinem Umfeld tauch es ab und an mal auf, hat aber wenig Verbreitung. Es bedarf dabei mehr Eigenleistung für die konkrete Ausgestaltung und ein gutes grundsätzliches Verständnis der Prinzipien und Werte, ähnlich wie Scrum selbst oder Scrum@Scale.
Und was ist mit Scrum?
Sie können natürlich auch das reine Scrum nutzen und Ihre Skalierung Stück für Stück aufbauen. Ebenso wie die anderen Skalierungsframeworks werden Sie dann zu einem bestimmten Ergebnis kommen. Dieses Ergebnis ist sehr auf Ihre Bedürfnisse zugeschnitten und wenn es auf agilen Prinzipien und Scrum Werten beruht, dann besteht auch hier eine gute Möglichkeit, dass Sie eine gute Lösung für sich bekommen.
Sind nicht alle Modelle etwas gleich?
Jedes Modell hat natürlich seine Stärken und Schwächen. Wie eingangs erwähnt geht es oft um eine Make-or-Buy Entscheidung. Doch es geht weiß mehr um das. Und das möchte ich an dem nachfolgenden Beispiel kurz erklären.
Wie gemeinsame Planungen nur ablaufen können
Immer wieder ranken Mythen um die Planungen in Skalierungsframeworks. Dabei ist die Sache ganz einfach, denn es gibt praktisch nur drei echte Lösungen, wie mehrere Teams, die an einem Produkt arbeiten, planen können.
Gar nicht
Wenn die Teams keine Abhängigkeiten haben, dann brauchen Sie auch nicht gemeinsam zu planen.
Stellvertreter
Existieren Abhängigkeiten, dann können die Teams Stellvertreter schicken und diese planen gemeinsam.
Gemeinsam
Ebenso können bei Abhängigkeiten alle Beteiligten sich treffen und gemeinsam planen.
Und jedes Skalierungsframework geht da etwas anders vor. Während zum Beispiel Scrum@Scale sehr organisch vorgeht, erlaubt das LeSS das Planen mit Stellvertretern und das Scaled Agile Framework plant in einem PI Planning mit allen.
Wie Kadenzen interpretiert werden können
Nicht jede Organisation kann oder will eine Synchronisation von zwei Wochen durch das gesamte Unternehmen leisten. Das muss es auch nicht. Kadenzen, Iterationen oder auch Sprints können und müssen immer nach Sinnhaftigkeit und Nützlichkeit überprüft werden.
Nutzen Sie auch hier bei Unsicherheit typische Verschwendungsarten und reflektieren Sie gegen genau diese, ob Ihre Interpretation für Ihre Kadenz sinnhaft und nützlich ist.
Planungshorizonte
Es gibt je nach Produkt und Markt unterschiedliche Planungshorizonte, die betrachtet werden können. Können, weil auch das kein Muss ist. Für die einen ist das alles wenig agil, für die anderen die einzige Möglichkeit auf dem Markt den richtigen Blick einzunehmen.
Ich deute mit Absicht die "..." an, denn auch bei Ihrem Skalierungsframework kann das wiederum anders aussehen. Es gibt viele Möglichkeiten und Sie müssen sich dann für eine passende Variante entscheiden.
Berücksichtigen Sie an dieser Stelle auch immer den Optimalzustand von Ihren Zustand. Wer es heute noch nicht schafft in jedem Sprint ein funktionierendes Inkrement zu erstellen, der sollte es aber immer vor Augen haben. Allerdings ist es besser zu beginnen und mit einer Version zu starten, als gar nicht zu beginnen. Sie lernen und verbessern sich auf dem Weg über Retrospektiven und kontinuierliches Lernen.
So finden Sie Ihr Modell oder eben nicht
Ziele für Skalierungsframeworks finden
Eine Möglichkeit sich einem (möglichen) Skalierungsframework zu nähern ist es, die eigenen Ziele sauber herauszuarbeiten. Wer zum Beispiel nicht auf Dinge wie Flexibilität und Kundennutzen Wert legt, der wird sich schon alleine mit einem reinen Scrum nicht wohlfühlen und folglich (da es auf Scrum basiert) auch nicht mit einem LeSS.
Ziele für Skalierungsframeworks lassen einen Abgleich zu, ob Wunsch und Realität auseinander gehen oder eben nicht.
Die meisten Unternehmen haben nicht die klare Vision und auch nicht die klaren Ziele, um zielorientiert eine Auswahl zu treffen. Nur wer sich grob einmal vorstellt, wo er landen möchte (Vision) und daraus kontinuierlich und immer verfeinert konkrete Ziele ableitet, wird bei einem nutzbaren Skalierungsframework landen.
Prinzipien und Werte
Während ich mich beim Schreiben ärgere, dass ich über agile Prinzipien noch keinen Artikel geschrieben habe, so habe ich zumindest einen Link für die Scrum Werte. Starten Sie immer bei den Prinzipien und Werten und interpretieren Sie diese in Ihrem konkreten Kontext. Alle Skalierungsframeworks benötigen ebenso diese Betrachtung!
Diese Arbeit wird leider häufig gar nicht vollzogen. Auch das ist schade, denn so wird schnell jegliches agiles Arbeiten auch typische mechanische Tätigkeiten reduziert.
Verschwendung
Ich schaue mir immer gerne den (vereinfachten) Wertstrom einer Organisation an. Und dann nutze ich zum einen Fragetechniken, zum anderen Kennzahlen, um zu ermitteln, wie effizient der Wertstrom ist.
Es gibt typische 10 Verschwendungsarten, die man im Kopf haben sollte. Lesen Sie sich dazu einfach einmal den Artikel durch und nutzen Sie diesen zur Reflexion.
Probleme & Herausforderungen herausarbeiten
Ich bediene mich immer gerne den Denkprozessen der Engpasstheorie, wenn es um ein aktuelles System geht, dass ich auf unerwünschte Wirkungen (Probleme) hin untersuche. Nur wenn ich die Herausforderungen und das System wirklich kenne, dann bin ich in der Lage dafür auch etwas zu liefern. Nicht zu wissen wohin es gehen soll, endet oft mit einem nicht gelebten Skalierungsframework.
Ein Gegenwartsbaum erlaubt es zum Beispiel das aktuelle System zu betrachten und die Betroffenen Stakeholder diese eben genannten unerwünschten Wirkungen erarbeiten. Davon ausgehend, oder auch auf Basis anderer Ideen, können wir dann mit einem Zukunftsbaum überlegen, ob wir mit unseren Ideen wohl das gewünschte Ziel treffen.
Fazit
Ich möchte keines der Skalierungsframeworks, die ich kenne, missen. Sie haben mir alle die Möglichkeiten gegeben zu reflektieren und zu lernen. Wenn Sie das Grundprinzip verstanden haben, dann ist es auch egal an welchem Modell Sie sich orientieren und wie das letztendlich aussieht. Sie finden Ihren Weg!
Große Organisationen
Je größer die Organisation ist, desto eher stelle ich fest, dass es nicht darum geht, welches der Skalierungsframeworks besser ist. Es geht oft darum, überhaupt ein sinnvolles Zusammenarbeitsmodell zu finden. Klingt hart, aber häufig gibt es keine gemeinsame, verstandene Vorwärtsbewegung!