Wer schon einmal beim Launch eines Agile Release Train dabei war, kennt die Situation. Am Ende des ersten PI Plannings schauen wir etwas ehrfürchtig und nachdenklich, aber auch ein wenig stolz auf das Program Board.
Der Begriff Agile Release Train stammt aus dem Scaled Agile Framework. Wir verstehen darunter ein “Team von agilen Teams”, welches durch eine gemeinsame Mission verbunden ist. Es realisiert in der Regel gemeinsam ein Produkt oder eine Produktgruppe. Dazu synchronisieren sich die Teammitglieder mittels gemeinsamen Ritualen und Prozessen.
Das PI Planning ist das Zentralste dieser gemeinsamen Rituale. Ähnlich des Sprint Plannings bei einem Scrum Team trifft sich der ganze Agile Release Train zu Beginn einer Iteration (des Program Increments, ca. 8-12 Wochen), um einen Grobplan zu erstellen, Abhängigkeiten und Risiken zu identifizieren und sich zu einer gemeinsamen Zielsetzung zu synchronisieren.
Das Program Board ist eines der Artefakte, welches im PI Planning entsteht. Auf diesem Grobplan ist ersichtlich, welche Features die Teams in den Iterationen (= Sprint) des kommenden Product Increments fertigzustellen gedenken, und die damit verbundenen Abhängigkeiten zu anderen Teams werden aufgezeigt. Entsprechend dem agilen Wert “Responding to change over following a plan” ist dieser Plan nicht fix, sondern die Basis, um die Konsequenzen von Planänderungen im Griff zu haben.
Es zeigt, welche Features und Stories die einzelnen Teams in den nächsten vier Sprints umzusetzen beabsichtigen. Mit roten Linien werden Features verbunden, an denen bei der Umsetzung mehrere Teams zusammenarbeiten müssen. Solche Abhängigkeiten waren es, welche uns in der Vergangenheit bei der rechtzeitigen Fertigstellung von Projekten und Vorhaben das Leben schwer gemacht haben. Für einen Projektleiter war es praktisch unmöglich, all diese Abhängigkeiten im Projektplan im Griff zu haben.
Nun haben wir mit dem vorliegenden Program Board einen grossen Schritt gemacht. Endlich sind die Abhängigkeiten für das nächste Produkt-Inkrement (welches beispielsweise fünf Sprints à zwei Wochen umfassen kann) transparent gemacht. Die Teams haben eine gute Vorstellung davon, wo sie auf die Vorarbeit anderer Teams angewiesen sind und bei welchen ihrer Features und Stories andere Teams auf eine Integration warten.
Natürlich ist man auch mit SAFe nicht vor Planänderungen gefeit. „Responding to change over following a plan“ ist ja schliesslich einer der dem Framework zugrundeliegenden Werte aus dem agilen Manifest. Die Teams haben dabei die Verantwortung, bei Änderungen an ihrem PI-Plan mit den abhängigen Teams in den Dialog zu treten und Lösungen zu finden, um die gemeinsam am PI Planning definierten PI Objectives trotzdem zu erfüllen. Das Program Board wird während der Umsetzung des Produkt-Inkrements laufend aktualisiert und bleibt damit ein wichtiges Arbeitsmittel für die Teams. Regelmässige Sync Events zwischen den Product Ownern und Scrum Mastern helfen zusätzlich bei der Bearbeitung der Abhängigkeiten und daraus resultierenden Impediments.
Das könnte das Ende dieses Blog-Artikels sein. Eine Erfolgsgeschichte, denn die betroffene Firma hat damit ein Mittel gefunden, einer grossen Herausforderung Herr/Frau zu werden. Wäre da nicht der Blogtitel, der in eine andere Richtung weist.
Abhängigkeiten beseitigen
Denn dieser Erfolg ist trügerisch. Unbestritten sind das Transparentmachen von Abhängigkeiten und ein selbstorganisierter Umgang damit ein echter Fortschritt eine Organisation. Allerdings täuscht diese grosse Stärke von SAFe gerne über das eigentliche Problem hinweg: die vielen Abhängigkeiten werden immer eine schnelle, regelmässige Werterzeugung torpedieren. Eine Integration über mehrere Teams hinweg ist immer schwerfälliger, aufwändiger und fehleranfälliger, als wenn ein einzelnes Team Features vollständig umsetzen, integrieren, deployen und damit Customer Value erzeugen kann.
Anstatt ein Organisationssystem auf ein möglichst gutes Abhängigkeiten-Management zu optimieren, sollten wir die Ursachen für die Abhängigkeiten erforschen und systematisch beseitigen. Bei unserer Kundschaft beobachten wir, dass diese Ursachen mannigfaltig sind. Fast immer spielt die Architektur eine grosse Rolle, diese wiederum wird (so besagt Conway‘s Law) durch die gewählte Organisations-Struktur mehr beeinflusst, als uns lieb ist. Das Organigramm ist oft „hierarchisch gewachsen“ und hat viel mit den bestehenden Führungs- und Machtstrukturen zu tun. Selten aber wird die Organisation wirklich auf einen optimalen Wertfluss ausgerichtet.
Wenn wir die Abhängigkeiten zwischen Teams eliminieren und ganzheitliche Wertschöpfung durch die Teams fördern – dann können wir die Früchte agilen Arbeitens wirklich ernten und unsere Organisation bereit für die Anforderungen unserer Kunden machen.
Mit unserem ganzheitlichen und systemischen Organisations-Assessment und der Begleitung und Unterstützung von Teams und Organisationen bei Inspect & Adapt haben wir viel Erfahrung dabei, solche Situationen nachhaltig zu verbessern. Nehmen Sie für einen unverbindlichen Austausch gerne Kontakt mit mir oder einer meiner Kolleg/innen auf.
