Prinzipien agiler Skalierung
Es ist sicher verlockend, einfach eine erfolgreiche skalierte Struktur eines anderen Unternehmens als Blueprint zu verwenden und zu kopieren. Allerdings geht das am Kern vorbei und behindert in der Regel sogar die agile Skalierung.
Gemäß der ersten Wertaussagen des agilen Manifests sind uns Individuen und ihre Interaktionen wichtiger als Prozesse und Tools. Wir sollten also mit den spezifischen Besonderheiten unseres Unternehmens und den darin arbeitenden Menschen beginnen und daraus eine eigene Struktur ableiten.
Wenn man sich die erfolgreichen agilen Skalierungen von z. B. Spotify, Jimdo oder Wooga (siehe unten) ansieht, stellt man vor allem eines fest: Keine folgt einem Blueprint. Alle diese Unternehmen haben ihre eigene Struktur gefunden, die optimal auf das Unternehmen und das Business passt.
Die agilen Prinzipien bilden die Leitplanken, die das Entstehen der eigenen agilen Skalierungsstruktur absichern. Wenn wir uns konsequent an diesen orientieren und gleichzeitig die Gesamtwertschöpfung unseres Unternehmens im Auge haben, stehen die Chancen gut. Einzelne Praktiken aus anderen Unternehmen können uns dann gerne als Inspiration dienen.
Bei der agilen Skalierung sollten diese Prinzipien besonders beachtet werden:
Persönlicher Kontakt. Es gibt zwischen den Teams und mit den für das Projekt entscheidungsrelevanten Personen kontinuierlichen persönlichen Kontakt. Damit können sich die Teams untereinander und mit den Verantwortlichen schnell und unbürokratisch abstimmen.
Lieferbare Produktinkremente. So wie ein Team jeden Sprint ein lieferbares Produktinkrement erstellt, erstellen alle Teams eines größeren Produktes lieferbare – vollständig integrierte – Produktinkremente mit jedem Sprint.
Inspect & Adapt auf Produktebene. Die häufige Inspektion des Gesamtproduktes und die Adaption der weiteren Planung muss auch in skalierten Umgebungen gewährleistet sein. Die Strukturen zur Skalierung dürfen nicht dazu führen, dass Ergebnisse aus der Inspektion lange Wege gehen müssen oder Entscheidungen über Plananpassungen verzögert werden.
Inspect & Adapt auf Prozessebene. So wie der Prozess im Team den Teammitgliedern gehört, sollte der Prozess zwischen den Teams den Teams gehören. Die Teams sollten gemeinsam darüber reflektieren, was in der Zusammenarbeit zwischen den Teams gut und weniger gut funktioniert, und daraus passende Verbesserungsmaßnahmen ableiten.
Autonome cross-funktionale Teams. Die Teams können möglichst unabhängig voneinander arbeiten. Dazu besitzen sie die Skills, die notwendig sind, um ihr Produkt/Produktsegment zu erstellen (Cross-Funktionalität).
Dezentrale Strukturen. Für die Koordination mehrerer Teams ist keine Hierarchie notwendig, die über Command & Control steuert. Selbstorganisation und Eigenverantwortung funktioniert nicht nur innerhalb eines Teams, sondern auch zwischen den Teams.
Globale Optimierung. Die Teams arbeiten zusammen an der globalen Optimierung des Produktes und der Wertschöpfungskette.
Flow & Rhythmus. Was für ein Team an Flow und Rhythmus erreicht wurde, wird durch Skalierung nicht wieder reduziert, sondern bleibt mindestens erhalten. Insbesondere unter dem Gesichtspunkt der horizontalen Skalierung breitet sich ein Verständnis von Flow und Rhythmus über die gesamte Wertschöpfungskette aus. Schwachstellen (Bottlenecks) werden in der gesamten Wertschöpfungskette identifiziert und beseitigt.
Limit Work-in-Progress. So wie Teams ihr Work-in-Progress limitieren, limitiert das Unternehmen die Menge parallel bearbeiteter Themen und fokussiert auf die wichtigen Themen.
Passende Software-Architektur. Durch eine passende modulare Software-Architektur können Abhängigkeiten zwischen Teams minimiert werden. Dann fällt es den Teams leichter, sich selbstorganisiert untereinander zu koordinieren.
Transparenz. Alle Teams haben Einblick in alle Informationen, die sie benötigen, um sinnvolle Entscheidungen zur Optimierung der Gesamtsituation zu treffen.
