Irgendwann ist das Team einfach zu groß geworden – was dann?
Es passiert schleichend – und fast immer aus guten Gründen. Ein App-Produkt-Entwicklungsteam liefert gut, also bekommt es mehr Verantwortung. Mehr Verantwortung braucht mehr Kapazität. Also kommen Menschen dazu. Und noch mehr. Irgendwann sitzt man mit 15 Personen in einem Team, das für 5 bis 8 gebaut war – und fragt sich, warum trotz gewachsener Kapazität die Lieferfähigkeit stagniert.
Wann haben Sie zuletzt geprüft, ob Ihre Teams noch richtig organisiert sind?
Das eigentliche Problem: Kognitive Last schlägt Kopfzahl
15 iOS- und Android-Entwickler, mehrere Mobile-Apps, ein gemeinsames Backlog, ein geteilter Tester. Das Team hatte seine Situation längst selbst diagnostiziert: zu viel Abstimmungsaufwand, zu wenig Fokus, zu wenig Eigenverantwortung.
Das Konzept der kognitiven Last – wie es Matthew Skelton und Manuel Pais in Team Topologies beschreiben – erklärt warum: Je mehr Apps, Kontexte und Abhängigkeiten ein Team gleichzeitig bedient, desto mehr Energie fließt in Koordination statt in Wertschöpfung. Brooks’ Law gilt nicht nur beim Hinzufügen neuer Mitglieder – es gilt im Dauerbetrieb. Bei 6 Personen gibt es 15 mögliche Kommunikationsbeziehungen. Bei 15 Personen sind es 105.
Die Konsequenz ist keine Theorie: Sie zeigt sich in verlangsamten Entscheidungen, in Retrospektiven die kreisen ohne zu landen, in Sprints die immer irgendwie überladen fühlen.
Warum der Schnitt erst nach 1,5 Jahren kam
Der Wunsch nach Aufteilung war früher da als die Möglichkeit dazu. In Hochlastphasen wurde die gesamte Kapazität aller 15 Personen für übergreifende Lieferziele gebraucht. Eine frühere Aufteilung hätte die Delivery dieser Produktziele gefährdet.
Was ich stattdessen tat: Ich begann frühzeitig, auf die Budgetplanung und die dazu gehörigen Release Daten Einfluss zu nehmen. Das Ziel war, dass die Mittel für das Folgejahr so geschnitten werden, dass zwei eigenständige Teams finanziell tragfähig und machbar sind. Diese Arbeit beginnt nicht kurz vor der Aufteilung – sie beginnt im Sommer davor, wenn Themen noch formbar sind. Ein Teamschnitt ohne Budgetgrundlage ist kein strategisches Vorhaben. Er ist eine idealisierte Hoffnung.
Bevor ein Vorschlag gemacht wurde, habe ich mehrere Szenarien bewertet: fachliche, technische, funktionale und komponentenbasierte Schnitte. Das Ziel war klar: zwei stream-aligned Teams im Sinne von Team Topologies – mit end-to-end-Verantwortung für je einen Produktbereich und nach Möglichkeit minimalem Koordinationsbedarf nach außen.
Der Schnitt: Empirisch belegt, menschlich gestaltet
Als der Favorit für den Schnitt feststand, lohnte sich ein Blick in die Vergangenheit – und dieser Blick war aufschlussreich: Die historische Ticket-Verteilung der Vorjahre, aufgeteilt nach den geplanten Produktbereichen, lag bei ca. 47 % zu 53 %. Hätten wir die Delivery früher anders organisieren können, hätten wir diesen Schnitt allein auf Basis dieser Abschätzung schon länger fahren können. Die Voraussetzungen waren strukturell vorhanden – nur die äußeren Bedingungen noch nicht.
Kurz vor Weihnachten war ich dann sicher: Die Budgets standen. Lange Gespräche und Erinnerungen innerhalb unseres Produktmanagement-Teams hatten sich ausgezahlt. Erstmals gab es eine Lieferziel-Timeline, die das Change-Vorhaben nicht gefährdete, sondern ermöglichte. Nach 1,5 Jahren strategischer Geduld – meine Vorfreude stieg. Den eigentlichen Change führte ich in zwei Phasen durch. Von Herbst bis Weihnachten: ausschließlich Problemraum. Einzelgespräche, Retrospektiven, Datenerhebung. Keine Lösungsvorschläge.
Auch die letzte Retro des Jahres und die Jahresreflexion waren sehr bewusst gestaltet: Das Team konnte sehen, wie viel wir gemeinsam geschafft hatten. Gleichzeitig ließ ich Raum für die Frage, was uns gebremst hatte. Die Antworten kamen vom Team selbst. Dieses Spannungsfeld – Stolz auf das Erreichte aber auch gesunde Zweifel an der bestehenden Struktur – war nicht einfach zu erzeugen. Aber es gelang gut. Das Team ging so mit einem gutem Gefühl in die Weihnachtspause – nicht mit Unruhe über offene Gestaltungsfragen aber durchaus mit gesundem Zweifel und damit einer hohen Motivation und Neugier für Veränderung im neuen Jahr. Nach den Ferien: Am erstem gemeinsamen Vorort Tag ging es los!
Ein Self-Designing Team Workshop. Ich legte den Rahmen fest – App-Zuordnung, Kapazitätsbalance, Kriterien für Motivation, Lernkultur und Teamfit. Die eigentliche Aufteilung übernahm das Team. Und hier war es nicht reibungslos. Zwei Personen wollten ins gleiche Team – obwohl die Kapazitäten das nicht zuließen. Eine Person war sich lange unsicher, welcher Bereich ihr wirklich liegt. Diese Spannungen haben wir im Raum gelassen. Nicht aufgelöst, nicht glattgebügelt – sondern ausgehalten, bis das Team selbst zu einem Ergebnis gekommen ist. Nach mehren 30 Minuten Blöcken nach denen wir entweder Feedback gaben oder Fragen der Entwickler beantworten stand eine Lösung, die dem Team gehörte und die das Team wollte. Es war auch nicht exakt die Lösung die wir uns gedacht hatten, aber eine absolut tragfähige. Ownership entsteht durch Selbstwirksamkeit, nicht durch Ansage. Wer seine Teamstruktur mitgestaltet, trägt sie auch in schwierigen Phasen.
Das strukturelle Detail, das den Flow verändert hat
Beide Teams teilen sich einen Tester. Früher kamen Testaufgaben kurz vor dem gemeinsamen Sprintende in Wellen. Jetzt sprinten die Teams versetzt – um eine Woche. Der Tester arbeitet kontinuierlich statt in Peaks. Gleichmäßiger Fluss schlägt Batch-Verarbeitung – das ist eines der ältesten Prinzipien aus Lean. Es klingt trivial. Die meisten Organisationen bauen ihre Teamstrukturen trotzdem nach Organigramm-Logik, nicht nach Flow-Logik.
Was die Zahlen nach 6 Wochen zeigen – und was nicht
Sechs Wochen sind kein Langzeitbeweis – das wird hier nicht als solcher verkauft. Saisoneffekte, Hawthorne-Effekt und parallele Veränderungen lassen sich kurzfristig nicht ausschließen. Deshalb haben wir bewusst einen Testballon von vier Monaten vereinbart, mit offener Retrospektive danach. Die KPIs zeigen eine klare Richtung – ohne dass ich behaupten will, die Neuorganisation sei allein dafür verantwortlich. Zu viele Variablen wirken gleichzeitig auf solche Kennzahlen ein. So berichtete mir ein Entwickler, dass er glaube, das gemeinsam erarbeitete technische Verbesserungen vor Weihnachten, seitdem die Lieferung bestimmter Stories in einem der Teams beschleunigen. Hierzu vielleicht ein anderes Mal mehr. Solche parallelen Entwicklungen spielen eine Rolle. Was ich sagen kann: Die Frühindikatoren motivieren, dass wir auf dem richtigen Weg sind. Verglichen wurden 6 Wochen nach dem Change mit einem halben Jahr in die Vergangenheit. Was die Frühindikationen zeigen:
- Durchsatz (Vorgänge/Woche): Mittelwert von Ø 8,7 auf Ø 12,0 (+38 %) – Standardabweichung von 5,0 auf 2,6
- Velocity (Story Points/Woche): Mittelwert von Ø 10,1 auf Ø 16,2 (+60 %) – Standardabweichung von 6,4 auf 4,5
Kommentare
Kommentar veröffentlichen