“so einfach wie möglich, aber nicht einfacher”

Alignment und das Pull-Prinzip 

Alignment ist einer der Kernwerte von SAFe. In agilen Methoden steht andererseits das Pull-Prinzip im Zentrum. Wie passt das zusammen? Wer entscheidet jetzt wirklich, woran im Team gearbeitet wird?

Eine etwas provokative, verkürzte Antwort:

Das Program Backlog ist eine Wunschliste — keine Bestellung, schon gar kein Befehl. 

Das Program Backlog als Wunschliste

Der Product Manager erfasst im Program Backlog alle erwünschten Änderungen am Verhalten und den Fähigkeiten des Systems; dabei steht der erwünschte Nutzen (Outcome) im Vordergrund und nicht der Anspruch, alle im ART anfallenden Tätigkeiten (Output) abzubilden.

Bei der Identifikation, Verfeinerung und Bewertung des Program Backlogs arbeitet das Program Management eng mit vielen Stakeholdern zusammen, neben Business-Vertreten unter anderem auch mit System Architekten und den Product Ownern der Teams. Bei der Anwendung der WSJF-Methode bezieht es alle so gewonnenen Erkenntnisse ein, um eine möglichst ganzheitliche Bewertung und Priorisierung der Features zu erzielen. Zentral ist dabei das Verhältnis des erwarteten Nutzens zum geschätzten Umsetzungsaufwand.

Das Program Backlog enthält neben Features aus dem Business auch Enabler, d.h. (oftmals technische) Vorbereitungsarbeiten für zukünftige Features. Das Product Management steuert das Verhältnis zwischen diesen beiden Arten von Features in Zusammenarbeit mit den System Architekten aktiv, um die langfristige Qualität des Systems sicherzustellen.

Als Ergebnis steht dem ART somit jederzeit eine nach Priorität sortierte Liste von gewünschten Änderungen am System zur Verfügung. Dabei ist es noch unwichtig und auch ungeklärt, welche Teams dazu welchen Beitrag leisten können, wie ihre Kapazitäten aussehen etc. — es handelt sich also nicht um einen Plan, eine Bestellung, einen Auftrag oder gar einen Befehl an die Teams.

Team-Autonomie 

Jedes Team führt sein eigenes Backlog, in dem es alle Arbeiten führt, die es auszuführen beabsichtigt, um seinen Beitrag zum Gesamtsystem zu leisten.

Bei der Verfeinerung der Features im Program Backlog identifiziert jedes Team seinen Beitrag zum Feature und erfasst entsprechende Stories in seinem Team Backlog. Diese Stories haben einen direkten Bezug zum Program Backlog und das Team wird die Arbeit an diesen Stories oftmals mit anderen Teams koordinieren, um das Feature gemeinsam umzusetzen und den entsprechenden Wert zu realisieren.

Das Team trägt aber in seinem Backlog auch alle Tätigkeiten ein, die es in eigener Verantwortung als wertvoll identifiziert hat. Darunter fallen insbesondere Team-interne Arbeiten, Erkenntnisse aus Retrospektiven, aber auch Wartungsarbeiten an Systemen und viel anderes "unter dem Radar". Der SAFe-Wert der Built-In Quality verpflichtet das Team, seine Anteile am System zu warten und in gutem Zustand zu erhalten, auch wenn dadurch keine aussenwirksame Veränderung erreicht wird und dies deshalb im Program Backlog nicht abgebildet wird.

Der Product Owner des Teams entscheidet über die Prioritäten für sein Team. Analog zum Product Manager kommuniziert er dafür mit vielen Stakeholdern, um ein Gesamtbild zu erhalten. Der Product Manager kann und soll sich aktiv einbringen und dem Team die Prioritäten sowie Abhängigkeiten auf ART-Ebene aufzeigen. Die Kompetenz und auch die Verantwortung für die Priorisierung der Arbeiten im Team bleibt aber beim Product Owner des Teams.

Stories ohne Bezug zum Program Backlog sind nicht weniger wertvoll und haben nicht grundsätzlich eine tiefere Priorität. Im PI Planning kann ein Team auch PI Objectives erarbeiten, die sich nicht auf Features im Program Backlog beziehen; es wird den Business Ownern den entsprechenden Wert aufgrund seines eigenen Wissens auch so aufzeigen können.

Beispiel

Ein Team betreut eine vom ART intern genutzte Plattform. Aufgrund strategischer Überlegungen hat das Management den Vertrag mit dem bisherigen Hosting-Anbieter gekündigt und einen Vertrag mit einem anderen Anbieter abgeschlossen. Die Kündigung ist auf einen festen Zeitpunkt am Ende des kommenden PI erfolgt.

Um die Plattform zum neuen Anbieter zu übertragen, sind erhebliche Aufwände notwendig. Das zuständige Team hat in Gesprächen mit den anderen Teams sichergestellt, dass die Plattform für sie wichtig ist und verfügbar bleiben soll.

Das Team nimmt alle für die Übertragung notwendigen Tätigkeiten in sein Team-Backlog auf und priorisiert sie hoch, damit die Übertragung vor der Abschaltung durch den alten Anbieter erfolgen kann.

Das Team stellt fest, dass es aufgrund dieser hohen Arbeitslast im kommenden PI nahezu keinen Beitrag an Arbeiten aus dem Program Backlog wird leisten können. Es informiert den Product Manager über diese Situation. Der Product Manager nimmt dies zur Kenntnis, ohne deshalb das Program Backlog zu verändern.

Im PI Planning prüft das Team, in welchen hoch priorisierten Features sein Beitrag erforderlich ist, und übernimmt nur im Rahmen seiner sehr beschränkten verfügbaren Restkapazität entsprechende Stories und Objectives.

Es kommuniziert transparent, dass seine oberste Priorität in diesem PI die Übertragung der Plattform ist. Es zeigt den Business Ownern auf, welchen Wert die Plattform für den gesamten ART hat und wird somit die Übertragung als höchstbewertetes PI Objective führen, obschon es dazu kein Feature im Program Backlog gibt.

Alignment heisst nicht Command-and-Control

Ein agiles Team übernimmt als Ganzes eine gemeinsame Mission und somit die Verantwortung für gewisse Systemteile und Arbeiten. Dadurch haben die Teammitglieder gemeinsame Ziele. Das ist das Alignment des Teams. 

In einem agilen Team gibt es jedoch keine zentrale Stelle, welche die Arbeit auf die Teammitglieder verteilt und den Fortschritt kontrolliert. Viel mehr übernehmen die Teammitglieder eigenverantwortlich gewisse Arbeiten, um ihren Beitrag zu den Zielen des Teams zu leisten. Daneben führen die einzelnen Teammitglieder diejenigen Arbeiten aus, die sie direkt selber verantworten, z.B. aufgrund von Spezialrollen wie Linienfunktionen, Lernendenbetreuung etc. — diese Tätigkeiten reduzieren die Kapazität, die für die gemeinsamen Ziele eingesetzt werden kann. Es obliegt jedem einzelnen Teammitglied, die Balance zu finden und den eigenen Arbeitseinsatz optimal zu priorisieren. Das ist eine schöne Anwendung der SAFe-Prinzipien #1 – Take an economic view, #2 – Apply systems thinking und #9 – Decentralize decision-making.

A Team of Teams

SAFe beschreibt einen Agile Release Train als Team of Teams. Diese Analogie funktioniert hervorragend, um das Spannungsfeld zwischen dem Program Backlog und den einzelnen Teams zu beschreiben: Genauso, wie ein agiles Team ein Alignment durch gemeinsame Ziele und ein gemeinsames Backlog hat, hat der ganze ART gemeinsame Ziele und ein gemeinsames Program Backlog. Und wie jedes einzelne Teammitglied seine eigenen Arbeiten und die Arbeiten in Hinblick auf die Teamziele eigenverantwortlich priorisiert, tun dies die Teams im ART. In einem guten agilen Team haben zwar alle einen gemeinsamen Plan, aber alle sind bereit, auf veränderte Situationen zu reagieren und ihren Beitrag entsprechend anzupassen — das gleiche sollte auch zwischen den Teams im ART erfolgen.

Konkret verantwortet der Product Owner die kurzfristige, taktische Priorisierung des Backlogs. Er ist jedoch aufgefordert, mit seinem Team einen möglichst grossen Beitrag zur Erledigung des Product Backlogs — entsprechend der vom ART vorgegebenen Priorisierung — zu leisten. Typischerweise bedeutet das, dass er mit seinem Team die Features von oben nach unten aus dem Program Backlog pullt, sofern keine zwingenden Gründe das verhindern.

Ein ART kann in Form einer Capacity Allocation als Richtwert festlegen, welcher Anteil der Team-Kapazität für das Program Backlog eingesetzt werden soll (z.B. 80% Feature-Stories, 20% Team-Stories), oder auch mit Guardrails definieren, welche Aufwände vollständig Team-intern (d.h. ohne Rücksprache mit dem Product Management) eingesetzt werden dürfen (z.B. ab 10PT Aufwand muss es ins Product Management). Viel wichtiger als solche starren Werte bleibt aber die aktive, an gemeinsamen Zielen ausgerichtete Zusammenarbeit zwischen dem Product Management und den Product Ownern aller Teams.

Pull, aber aligned

Zusammengefasst löst sich das vermeintliche Spannungsfeld auf:

  • Jedes einzelne Teammitlied, jedes einzelne Team — und übrigens auch jeder ART im Kontext des Gesamtunternehmens — entscheidet selber, woran es als nächstes arbeiten wird. Dabei bezieht es sein eigenes Wissen und seine eigene Situation ein. Dies ist die Umsetzung des agilen Pull-Prinzips.
  • Durch gemeinsame übergeordnete Ziele sowie ein gemeinsames übergeordnetes Backlog haben alle einen Orientierungsrahmen und gemeinsame Interessen. Dies schafft Alignment.
  • Eine häufige Kommunikation zwischen allen Beteiligten schafft Transparenz, gegenseitiges Verständnis und damit die Grundlage für optimale Entscheidungen aller Beteiligten.