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.
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!
Aufmacherbild: elephant running across a tightrope von Shutterstock / Urheberrecht: eelnosiva
