Agile Teams als Silo 2.0?

How it started

Ein Team reicht heute selten aus, um ein Produkt zu entwickeln. Mehrere Teams müssen koordiniert auf das Gesamtprodukt hin entwickeln. Wir sind inzwischen häufig immerhin soweit, dass jedes Team kundensichtbare Funktionalität End-To-End umsetzen sollte (und nicht mehr Individuen in funktionalen Silos gemanaged werden).
Dazu müssen die Teams passend geschnitten werden: Story Mapping, Customer Journey, Domain Driven Design etc. liefern eine gute Basis für so einen fachlich orientierten Teamschnitt.
Jedes Teams setzt dann Funktionalitäten in seinem jeweiligen Verantwortungsbereich um.
Die Kunden können den Fortschritt der Entwicklung anhand sichtbarer Funktionen bewerten und Feedback geben, das in der weiteren Entwicklung hilft.

How it ended

Wenn das Produkt ein Mindestmaß an Funktionalitäten abdeckt, ändert sich die Situation häufig. Jetzt werden immer mehr übergreifende Funktionalitäten gewünscht.
Wollte Amazon z.B. seinen Kunden Transparenz darüber verschaffen, wie klimaschädlich die jeweiligen Produkte sind, könnte dies über ein einfaches Rating geschehen (0 bis 3 grüne Blätter).
Dazu müssten mindestens der Artikelkatalog, die Suche, die Suchergebnisliste und die Ansicht der Artikeldetails angepasst werden. Vielleicht will man den Kunden auch gleich eine CO2-Kompensation anbieten und klimaneutralen Versand. Dann muss auch der Checkout angepasst werden. Und schwupps braucht man mehrere Teams, um eine businessrelevante Weiterentwicklung des Systems zu bewerkstelligen.

Meistens versucht man die Problematik durch Verwaltung zu lösen und bekommt im Gegenzug Trägheit und schlechte Vorhersagbarkeit.
Man passt die Aufgaben an die (Team-)Struktur an. Viel zu selten wird damit experimentiert, die (Team-)Struktur an die Aufgabe anzupassen.
Zur Veranschaulichung beschreibt dieser Artikel vier exemplarische Möglichkeiten, um übergreifende Funktionalität zu implementieren.

Variante 1: Feature Manager

Viele Unternehmen entscheiden sich, die übergreifende Funktionalität in einzelne Funktionen je Team zu zerteilen; die existierende Teamstruktur kann aufrecht erhalten werden.<{br>Aber darum muss sich jemand kümmern. Ich nenne ihn Feature Manager. Der heißt in der Praxis auch mal Delivery Manager, Chief Product Owner, Programm Manager, Epic Owner, Projektmanager etc.
Der Feature Manager definiert die Aufgabenpakete für die einzelnen Teams, kontrolliert den Fortschritt in der Entwicklung (z.B. indem er sich in Scrum of Scrums Bericht erstatten lässt), stellt die übergreifende Qualitätssicherung sicher (die einzelnen Beiträge der Teams sollen ja auch im Zusammenspiel funktionieren) und kümmert sich um die koordinierte Auslieferung an die Kunden.

Dieser Ansatz kann zu einer Reihe von Problemen führen:

• Die Wünsche des Feature Managers können leicht in Konflikt mit den Prioritäten der Product Owner der Teams geraten.
• Der Feature Manager kann leicht in Command&Control-Verhalten verfallen.
• Die übergreifende Qualitätssicherung findet erst spät statt. Probleme werden also erst spät gefunden und ihre Beseitigung kann dadurch aufwendig werden und die weitere Planung auf den Kopf stellen.
• Die Teams werden von dem entkoppelt, was übergreifend erreicht werden soll. Sie können ihre Kreativität nur noch eingeschränkt einbringen und ihre Motivation leidet.
• Für die Teams stehen die Teilfunktionen, die der Feature Manager sich wünscht, häufig nicht im Fokus und werden "nebenbei" erledigt. Dadurch werden sie häufig zurückgestellt, wenn es im Sprint eng wird.
• Diese Dinge zusammengenommen führen oft zu schlechterer Vorhersage, bis wann bestimmte Dinge fertiggestellt sind.

Variante 2: Big Room Planning

Der Ansatz über Big Room Planning umgeht die Einführung einer zusätzlichen Rolle und setzt auf die Eigenverantwortlichkeit der Teams. Es finden sich alle (!) Teammitglieder für eine gemeinsame Planung zusammen. Das kann eine gemeinsame Sprint-Planung sein oder einen längeren Zeitraum umfassen (wie z.B. das PI-Planning in SAFe). In diesem Big Room Planning zerlegen die Teams die übergreifenden Funktionalitäten selbst und stimmen sich darüber ab, welches Team bis wann was tut.
Daraus entsteht eine geeignete Visualisierung des Big Picture (z.B. als Dependency Matrix, Abhängigkeitsgraph oder Flight Level 2). Dieses Big Picture dient als Hauptwerkzeug in Scrum of Scrums, in denen sich die Teams darüber austauschen, wo sie bzgl. der übergreifenden Funktionalitäten stehen.

Der Ansatz über Big Room Planning vermeidet viele der o.g. Probleme mit dem Feature Manager. Ohne Probleme ist er aber auch nicht.

• Wenn viele Abhängigkeiten vorab geklärt und geplant werden müssen, entsteht ein Abhängigkeitsgraph, der von einem klassischen Gantt-Chart nicht mehr zu unterscheiden ist. Flexible Reaktion auf neue Erkenntnisse in den Teams wird dann kaum noch möglich bzw. würde eine komplette Neuplanung erfordern.
• Auch hier müssen die Einzelfunktionalitäten, die aus der übergreifenden Funktionalität entstehen, gegen die Wünsche der Product Owner priorisiert werden. Das geht hier etwas eleganter als beim Feature Manager-Ansatz, weil alle Beteiligten zur Planung zusammenkommen. Dort können Priorisierungskonflikte gesprochen und ausgeräumt werden.

Variante 3: Team-Zuordnung

Komplett anders sieht es aus, wenn man nicht die Aufgaben an die Struktur anpasst, sondern die Struktur den Aufgaben folgt. Dann wird die übergreifende Funktionalität nicht in Arbeitspakete je Team aufgeteilt. Stattdessen kümmert sich ein Team End-To-End um die übergreifende Funktionalität.
Eine Möglich ist, dass eins der existierenden Teams die übergreifende Funktionalität komplett übernimmt. Wenn die übergreifende Funktionalität in einem Teilbereich des Produktes seinen Schwerpunkt hat, bietet sich das zugehörige Team an.
Das verantwortliche Team nimmt alle Änderungen vor, die für die Umsetzung der übergreifenden Funktionalität notwendig sind - auch in den Produktbereichen der anderen Teams.
Dieser Ansatz folgt der Denkweise aus dem LeSS-Framework: Die Teams sollen stabil bleiben, sich aber der geschäftlichen Priorisierung des einen Product Backlogs unterwerfen.

Dieser Ansatz vermeidet die Probleme der beiden anderen Ansätze, braucht aber eine gewisse Homogenität:

• Je homogener die einzelnen Produktbereiche implementiert sind, desto leichter lässt sich der Ansatz umsetzen. Wenn aber jeder Produktbereich in unterschiedlichen Programmiersprachen mit unterschiedlichen Datenbanken und nach unterschiedlichen Entwurfsprinzipien implementiert ist, wird es für das verantwortliche Teams sehr schwer, die notwendigen Änderungen in den anderen Produktbereichen vorzunehmen.
• Ähnlich verhält es sich, wenn die einzelnen Produktbereiche fachlich sehr kompliziert sind. Dann wird eine Einarbeitung des verantwortlichen Teams sehr aufwändig.

Variante 4: Temporäres Team

Alternativ kann man aus den existierenden Teams ein temporäres Team zusammenstellen, das sich End-To-End um die übergreifende Funktionalität kümmert. Dieses Team nimmt alle Änderungen am Produkt vor, die notwendig sind - auch in den Produktbereichen der anderen Teams.
Nach der Fertigstellung der übergreifenden Funktionalität löst sich das temporäre Team auf und die Mitglieder gehen zurück in ihre Teams. Man hat also mobilere Teammitglieder als in den anderen drei Ansätzen.
Dieser Ansatz folgt grundlegenden Ideen aus Floating Teams und dem FaST-Ansatz.
Der Ansatz über temporäre Teams kann besser mit sehr inhomogenen Produktbereichen umgehen als die Zuordnung eines existierenden Teams. Durch die Rekrutierung der Mitglieder aus existierenden Teams sind im Team die notwendigen Kenntnisse der jeweiligen Produktbereiche vorhanden.
Allerdings geht dies mit eine größeren Abhängigkeit von einzelnen Teammitgliedern einher. Wird ein Teammitglied krank, fehlt das Wissen über den zugehörigen Produktbereich. Das kann dadurch aufgefangen werden, indem in dem Produktbereichs-Team ein Ersatz gesucht wird. Das wirft dann die Frage nach der übergreifenden Priorisierung auf. Opfert man Performance des Produktbereichs-Teams, damit das temporäre Team effizient weiterarbeiten kann?

Gewichtiger sind allerdings die Voraussetzungen für diesen Ansatz:

• Die Mitglieder des temporären Teams müssen in der Lage sein, schnell als Team zu agieren. Wochenlange Teamfindung rentiert sich nicht. Dafür braucht es ein Mindestmaß an psychologischer Sicherheit und ein gehöriges Maß an Pragmatismus bei den Beteiligten.
• Die Mitglieder des temporären Teams müssen qualitativ hochwertige Arbeit übernehmen, auch wenn sie nicht langfristig mit der Weiterentwicklung ihres Codes betraut sind. Dazu müssen die Teammitglieder bereits erlebt haben, was es bedeutet, gemeinsam im Team Verantwortung zu übernehmen.