Kolumne

Groß und (fr)agil: Feature-Team schlägt Komponenten-Team

Timo Becker

(c) Shutterstock / eelnosiva

Vielleicht kennen Sie die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Schnell steht der agile Protagonist auf unbekanntem Terrain: Wie skalieren Product-Owner, Aufgabenverteilung und teamübergreifende Abstimmungen? In dieser Kolumne wollen wir erprobte Lösungspraktiken und Patterns aus bekannten Skalierungs-Frameworks aufzeigen. Heute geht es um den richtigen Schnitt von Teams.

Go Teams

Neun Menschen – größer sollte ein Scrum-Team idealerweise nicht sein. Dem einzelnen Team sind damit Kapazitätsgrenzen gesetzt. Benötigt ein Projekt mehr Mitstreiter, werden häufig weitere Teams gebildet. Die anstehenden Aufgaben müssen dann nach sinnvollen Kriterien auf die Teams verteilt werden: neue Anforderungen und User-Storys aufnehmen, hinsichtlich der Komplexität schätzen, in einen Sprint einplanen und schließlich umsetzen.

Es gibt aus meiner Sicht zwei unterschiedliche Lösungsansätze:

Sogenannte Komponenten-Teams sind für eine oder mehrere Komponenten des Systems zuständig, beispielsweise die Präsentationsschicht, die Business-Logik oder die Datenbank, und haben auf diesem Gebiet spezielle Expertise. Die Organisation in Komponenten-Teams ist ein technischer, horizontaler Schnitt durch das Gesamtsystem. Dafür braucht man einen Backlog aus technischen Storys, die meist nur einen Teil eines Kunden-zentrierten Features umsetzen. Neue Features mit Berührungspunkten zu mehreren Komponenten müssen daher von mehreren Teams bearbeitet werden, was ungewünschte Abhängigkeiten zwischen den Teams impliziert.

Der Gegenentwurf sind Feature-Teams. Ein Feature-Team ist für ein ganzes Kunden-zentriertes Feature verantwortlich und deckt potenziell alle Schichten des Systems ab. Die Organisation in Feature-Teams ist somit ein fachlicher, vertikaler Schnitt durch das System – mit einem Backlog aus “echten”, fachlichen User-Storys. Statt spezieller Expertise – für Datenbank oder UX – wird stärker ein generalizing-specialist-Ansatz verfolgt: Jedes einzelne Team bearbeitet ein möglichst breites Feld an Themen.

groß agil

Abbildung 1: Komponenten-Teams koordinieren sich auf Team-Ebene, Feature-Teams auf Quellcodeebene. Synchronisation auf Quellcodeebene wird von Versionierungstools unterstützt.

Feature-Team schlägt Komponenten-Team

Feature-Teams haben gegenüber Komponenten-Teams viele Vorteile: Nicht nur, dass fachliche User-Storys den Geschäftswert in den Fokus rücken und damit stärker agilen Prinzipien folgen. Zudem ist der Lernfaktor in einem Feature-Team höher, da Wissen auf allen Ebenen des Technologie-Stack aufgebaut wird. Das erhöht die Flexibilität in den Teams und verringert Abhängigkeiten zwischen ihnen, was wiederum zu geringeren Wartezeiten und weniger Übergaben führt. Außerdem fördern Feature-Teams den gemeinsamen „Ownership“ des Codes. Jeder im Team fühlt sich für den Code insgesamt verantwortlich.

Ein großes agiles Projekt sollte nach Möglichkeit von Anfang an Feature-Teams etablieren. Existiert in einem bestehenden Projekt bereits ein Schnitt nach Komponenten, empfehlen wir, die Teams sukzessive zu Feature-Teams umzuformen: Dafür wird zunächst ein einzelnes Feature-Team aus Vertretern mehrerer Komponenten-Teams gebildet. So sind alle nötigen Kenntnisse im Team vereint. Glückt das Experiment, können weitere Feature-Teams nach demselben Schema folgen.

Rechnen Sie bei der Organisation in Feature-Teams allerdings auch mit einigen neuen Herausforderungen: Es entsteht erhöhter Lernaufwand, um das notwendige Wissen zur Umsetzung fachlicher User-Storys im Team aufzubauen. Agile Techniken wie Pair- oder Mob-Programming [1] fördern hier schnellen Wissenstransfer. Andererseits verschiebt sich der Koordinationsaufwand von einer interpersonellen auf eine technische Ebene: Während Komponententeams häufig gemeinsam an einem Feature arbeiten und dadurch kontinuierlich teamübergreifende Absprachen treffen müssen, bearbeiten Feature-Teams jeweils ein isoliertes Feature. Das muss wieder in den gemeinsamen Quellcode integriert und mit den Features der anderen Teams zusammengeführt werden. Technische Hilfsmittel wie Versionsverwaltungssysteme vereinfachen diese Aufgabe jedoch erheblich.

Welche Erfahrungen haben Sie beim Schnitt Ihrer Teams gemacht? Was funktionierte gut, was weniger gut? Wir freuen uns auf Ihre Kommentare!

Groß und (fr)agil?

In der Kolumne Groß und (fr)agil? stellen Christoph Niemann und Timo Becker (MaibornWolff) Lösungsansätze vor, um agile Entwicklung auf große Szenarien zu skalieren. Ganz nach dem Motto: Groß und agil – das muss kein Widerspruch sein!

Bisher erschienen:


Aufmacherbild: elephant running across a tightrope von Shutterstock / Urheberrecht: eelnosiva

Geschrieben von
Timo Becker
Timo Becker
Timo Becker ist Software-Ingenieur bei MaibornWolff und entwickelt aktuell Individual-Software in einem großen agilen Projekt.
Kommentare
  1. Christian2017-06-16 11:54:13

    Ich halte die Unterscheidung in "Komponententeams" und "Featureteams" für etwas unglücklich, denn wenn die Architektur nicht die Organisation widerspriegelt (Stichwort: Conways Law), entstehen Konflikte, weil mehrere Teams möglicherweise an einer _technischen_ Komponente arbeiten. Viel besser wäre es, wenn es auch fachliche Komponenten gäbe. Dann wären Featureteams und Komponententeams deckungsgleich, weil die Architektur zur Organisation passt und es echte Entkopplung zwischen Teams gibt, was auch ein beliebtes Argument für die Einführung von Microservices ist (was nicht heißt, dass man das nicht auch ohne sie erreichen könnte).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.