Raus aus der "Behörde für Agilität„

Agile Teams als Silo 2.0?

Das hatte man sich sicher anders vorgestellt. Aber jetzt hat man mit den ganzen agilen Teams dann doch oftmals den Eindruck der "Behörde für Agilität". Das hat zumindest unsere Umfrage ergeben: über 35% der agilen Implementierungen fühlen sich so oder schlimmer an.

Das liegt sicher nicht daran, dass die agilen Implementierungen per se schlecht wären oder die Leute keine Ahnung hätten. Die Problematik entsteht fast zwangsläufig. Das Problem ist nicht, dass es überhaupt soweit kommt, sondern das häufig der Mut fehlt, die Situation zu ändern. Aber eins nach dem anderen...

Hier ist unser Kollege Stefan zu sehen.

Autor

Stefan Roock

Mehr zum Autor

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.

Fazit

Es gibt nicht den perfekten und einzig richtigen Umgang mit übergreifenden Funktionalitäten. Die vier genannten Ansätze sollen das Spektrum veranschaulichen. Mischformen sind jederzeit möglich. So könnten die Teams in einem Big Room Planning entscheiden, ein temporäres Team für eine übergreifende Funktionalitäten zu bilden.

Am Wichtigsten ist, dass man träge Situationen nicht als unveränderlich hinnimmt (z.B. mit Verweis auf "Trägheit der Masse"), sondern mutig mit verschiedenen Ansätzen experimentiert. So wächst das Verständnis über die eigene Situation und die eigenen Möglichkeiten und man kann zu einer eigenen Lösung finden, die so effizient, stringent und leichtgewichtig ist, wie Agilität immer gedacht war.

Hier ist unser Kollege Stefan zu sehen.

Über den Autor

Stefan Roock

Stefan Roock hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen. 

Veröffentlichungen (u. a.):

E-Mail:Twitter:LinkedIn:

Mehr von Stefan Roock

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben