Agile Skalierung über die Prinzipien

Agile Skalierung bedeutet, eine lernende Organisation zu gestalten. Dabei hilft es nicht, einen Blueprint für Skalierung (wie z.B. das Scaled Agile Framework™) zu kopieren. Stattdessen müssen die agilen Prinzipien konsequent angewendet werden, um den eigenen Weg zu finden.

Diese Art der agilen Skalierung findet Anwendung, wenn mehrere Teams am selben Produkt arbeiten und/oder Agilität für das ganze Unternehmen verwendet werden soll.

Bei der agilen Skalierung verfallen Unternehmen leider all zu oft in alte Verhaltensweisen und Strukturen. Was im Pilotprojekt noch selbstorganisiert wunderbar funktioniert hat, wird jetzt durch Hierarchie und zusätzlichen Rollen (Release-Manager, Chef-Architekt etc.) wieder eingeschränkt und die Vorteile der Agilität schwinden. Wir beschreiben hier die Prinzipien, die bei der agilen Skalierung zu berücksichtigen sind, um letztlich im großen Stil die Vorteile der Agilität nutzen zu können.

Grundsätzliche Feststellungen

Seit 1999 haben wir unzählige agile Projekte und Transitionen begleitet. Manchmal haben „nur“ vier Teams am selben Produkt gearbeitet, manchmal über zehn. Mal waren nur 50 Personen von der Transition betroffen, mal mehrere tausend. Wir haben dabei gesehen, was funktioniert und was nicht. Daraus lassen sich einige grundsätzliche Feststellungen ableiten:

Agil bedeutet Kulturwandel. Agile Entwicklung erfordert einen Kulturwandel hin zu Offenheit, Kundenorientierung und Kooperation. Dieser Kulturwandel kann nicht von oben verordnet oder durch einen vorgegebenen Prozess herbeigeführt werden. Die neue Kultur muss langsam wachsen. Daher sollte agile Entwicklung in einem überschaubaren Bereich begonnen und dann langsam im Projekt oder Unternehmen ausgebreitet werden.

Jede Organisation ist anders. Jedes Unternehmen hat sein einzigartiges Business (Mitarbeiter, Kunden, Produkte, Fertigung, ...). Die Skalierungsstruktur muss dieses Business angemessen abbilden und kundenorientiert aufgestellt sein. Ein allgemeiner Blueprint kann diese Anforderung nicht erfüllen (wenn es den einen optimalen Blueprint gäbe, wären alle Unternehmen gleich).

Einführung von Agilität ist eine komplexe Aufgabe. Agilität zu skalieren ist eine komplexe Aufgabe, die nicht von Anfang bis Ende vorab geplant werden kann. Wir müssen wie bei der agilen Entwicklung damit rechnen, dass die Realität immer wieder von unseren Plänen abweicht, und müssen daher unsere Pläne häufig anpassen. Daher muss die Einführung von Agilität iterativ erfolgen und erfordert häufiges Inspect&Adapt.

Leadership. Bei der agilen Skalierung ist noch stärker als bei der Einführung von Scrum für ein Team modernes Leadership (Führung) gefragt. Führungskräfte geben keine Anweisungen, wie etwas zu geschehen hat. Sie überlassen die Mitarbeiter aber auch nicht sich selbst. Sie geben eine Richtung vor und setzen Randbedingungen (Constraints), in denen sich Selbstorganisation entfalten und die passende Organisationsstruktur finden kann.

Zusammengenommen bedeutet agile Skalierung, ein lernendes Unternehmen aufzubauen.

Vertikale und horizontale Skalierung

Wenn wir an agile Skalierung denken, denken wir zunächst sicher daran, mehr agile Teams zu installieren, die denselben Ausschnitt aus der Wertschöpfungskette (z.B. Software entwickeln) abdecken. Diese Art der Skalierung kann man vertikale Skalierung nennen.

Es gibt eine zweite Option für die Skalierung, die uns zunächst weniger bewusst ist. Bei der horizontalen Skalierung wird der Bereich der Wertschöpfungskette ausgeweitet, für den das Team verantwortlich ist.

Abwärts der Wertschöpfungskette (downstream) könnte dies z.B. bedeuten, dass das Team auch für die Inbetriebnahme oder sogar den Betrieb der Software verantwortlich wird. Das Thema DevOps (Teammitglieder, die sowohl die Entwicklung – Dev – wie auch den Betrieb – Ops – der Software beherrschen) passt hier gut ins Bild. Die Verantwortung des Teams in die andere Richtung der Wertschöpfungskette (upstream) auszuweiten kann bedeuten, das Design, die User Experience, die Marktforschung und den Vertrieb in das Team zu integrieren. Ob es sinnvoll ist, alle Mitarbeiter in agilen Teams arbeiten zu lassen und ob diese Teams jeweils die komplette Wertschöpfungskette verantworten sollten, hängt vom Unternehmen und dem Geschäft ab. Anteile, die standardisiert stattfinden und in denen Lernen keine große Rolle spielt, profitieren von Agilität viel weniger als die Bereiche, in denen Lernen unumgänglich ist. Entsprechend kann man auch nicht sagen, dass vertikale oder horizontale Skalierung besser wäre oder dass man immer mit vertikaler Skalierung beginnen sollte. In den meisten Fällen wird eine Mischform angemessen sein.

vertikale und horizontale Skalierung

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 relevanten Entscheidern kontinuierlichen persönlichen Kontakt. Damit können sich die Teams untereinander und mit den Entscheidern 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 des Entwicklungsteams, 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 mind. 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.

Praktiken zur agilen Skalierung

Es gibt unzählige Praktiken zur agilen Skalierung und ständig entdecken Unternehmen neue Praktiken. Generell gilt: je weniger zusätzliche Praktiken zur agilen Skalierung benötigt werden, desto leichtgewichtiger und flexibler ist man unterwegs. Viele Unternehmen stellen fest, dass die Standard-Praktiken von Scrum und Kanban auch für skalierte Umfelder ausreichen. Darüber hinaus eingeführte Praktiken sollten den agilen Grundprinzipien nicht zuwiderlaufen (es sollten also insbesondere keine zusätzlichen Hierarchien eingeführt und Selbstorganisation eingeschränkt werden).

Es lassen sich grob vier Felder unterscheiden, die man bei der agilen Skalierung betrachten sollte.

Organisation Product Ownership: Product Ownership muss so organisiert werden, dass die Produktentscheidungen mit dem Blick auf das ganze Produkt und seine Wertschöpfungskette gefällt werden und nicht nur lokal auf einen bestimmten Aspekt hin optimiert wird.

Für die Organisation des Product Ownership werden z.B. folgende Praktiken verwendet:

  • Ein Product Owner und ein Product Backlog für das ganze Produkt.
  • Gemeinsames Sprint-Planning 1 (der "Was"-Teil) mit allen Teams.
  • Gemeinsames Sprint-Review mit allen Teams.

Abstimmung der Entwicklungsteams: Die Entwicklungsteams müssen dafür sorgen, dass sie sich technisch nicht gegenseitig behindern und sinnvolle Synergien zwischen den Teams sichtbar und genutzt werden. Gleichzeitig muss dafür gesorgt werden, dass trotz der großen Menge der beteiligten Personen bei jedem Entwickler das Verantwortungsgefühl für das Produkt und seine Qualität erhalten bleibt.

Für die Abstimmung der Entwicklungsteams werden z.B. folgende Praktiken verwendet:

  • Teams besuchen sich gegenseitig bei ihren Daily Scrums
  • Scrum of Scrums

Software-Architektur: Die Software-Architektur hat einen erheblichen Einfluss auf die Abstimmungsaufwände bei Product Ownership und zwischen den Teams.

Bei der Software-Architektur werden z.B. folgende Praktiken verwendet:

  • Arbeit mit Architekturvisionen
  • Share Nothing-Architekturen
  • Serviceorientierte Architekturen
  • Austausch der Entwickler während der Entwicklung bei einer Community of Practice zur Architektur.

Entwicklungspraktiken: Über die passenden Entwicklungspraktiken stellen die Teams sicher, dass nicht nur die eigene Komponente eine hohe Qualität hat, sondern auch im Zusammenspiel mit den Komponenten der anderen Teams ein hochqualitatives Produkt ergibt.

Für agile Skalierung werden z.B. folgende Praktiken verwendet:

  • Continuous Integration
  • automatisierte Unittests
  • automatisierte Akzeptanztests
  • Pair-Programming mit Mitgliedern aus anderen Teams desselben Produktes
  • Continuous Deployment 

Whitepaper zur agilen Skalierung für Führungskräfte

Wir haben in einem Whitepaper zusammengestellt, was Führungskräfte über agile Skalierung wissen sollten. Download