SCRUM Reihe 1: Feature-Teams versus Komponenten-Teams

Scrum ist inzwischen die wohl bekannteste Vorgehensweise im agilen Kontext und verbreitet sich zunehmend auch außerhalb der IT- und Software-Entwicklung.

Die Faktor Zehn setzt Scrum in der Produktentwicklung und in fast allen Kundenprojekten ein. Aktuell beschäftigen wir uns in mehreren Kundenprojekten mit dem Spannungsfeld zwischen Feature- und Komponenten-Teams. Kommen bei einem größeren agilen Vorhaben mehrere Teams zum Einsatz, so stellt sich stets auch die Frage, wie die einzelnen Teams aufgestellt werden. Soll es Feature-Teams geben, die eine Funktionalität komplett – vom Frontend bis in alle Details des Backends – abschließend entwickeln können? Oder ist es besser, die Teams nach den technischen Komponenten aufzustellen, da ja doch überall Besonderheiten lauern?

Feature-Teams

Ein Feature-Team ist in sich autark und kann eine Funktionalität komplett entwickeln. Wenn das Feature fertig ist, kann es direkt genutzt werden, was wiederum diverse Vorteile mit sich bringt: Feedback kann zeitnah erfolgen und hoffentlich auch der gewünschte Nutzen gewonnen werden. Des Weiteren gibt es bei dieser Teamaufstellung nur wenige Abhängigkeiten zwischen den einzelnen Teams – insbesondere technische Abhängigkeiten werden minimiert.

Allerdings haben auch Feature-Teams ihre Nachteile. Alle arbeiten gleichzeitig an allen Systemen / Komponenten. Dadurch kommt man sich an zentralen Stellen leicht in die Quere. Zudem müssen alle involvierten Kollegen die Kernkonzepte verstanden haben, was viel Kommunikation voraussetzt – und zwar zwischen allen beteiligten Personen.

Je komplexer das Vorhaben und je unterschiedlicher die einzelnen Schichten der Anwendung sind, umso stärker treten diese Nachteile in Erscheinung: Ist die Komplexität gering, so ist die Skalierung relativ einfach, da über Konzepte und Lösungen wenig kommuniziert werden muss. Ist das Umfeld jedoch komplex, so steigt der Kommunikationsaufwand enorm.

Ein weiterer Nachteil von Feature-Teams in komplexen Umfeldern ist, dass die Zuständigkeit für einzelne Komponenten auf alle Teams verteilt ist. Das Problem dabei ist, dass verteilte Verantwortung typischerweise kaum wahrgenommen wird und wenn, dann meist nur von Einzelpersonen getragen wird. Ein Blick in die Kaffeeküche im Büro oder in die WG-Küche zeigt, was das in der analogen Welt bedeutet: Schmutzige Tassen und Teller überall. In der IT-Welt ist das Ergebnis typischerweise in sehr kurzer Zeit eine relativ hohe technische Komplexität.

Komponenten-Teams

Setzt man für ein geplantes Vorhaben auf Komponenten-Teams, ist die Zuständigkeit für eine Komponente eindeutig einem Team zugeordnet. Die Kommunikation über interne Konzepte und Lösungen findet alleine in dem zuständigen Team statt, was ein großer Vorteil ist. Gut funktionierende Komponenten-Teams vereinbaren untereinander Schnittstellen, mit denen gearbeitet wird. Das ist immer noch ein nicht unerheblicher Kommunikations- und Abstimmungsaufwand, aber ein sehr geringerer, als bei reinen Feature-Teams.

Da die Teams voneinander unabhängig sein sollten, bedeutet dies zudem, dass technisch aufeinander aufbauende Feature-Bestandteile meist in aufeinanderfolgenden Sprints umgesetzt werden. Daher kann sich die Realisierung einer vollständigen Funktionalität schon mal über vier oder fünf Sprints hinziehen. Der Nutzen und das Feedback zu dieser Funktionalität kommen also wesentlich später:

Die große Schwierigkeit bei Komponenten-Teams liegt jedoch darin, ein Feature über alle Komponenten hinweg funktionsfähig zu bekommen. Ein Team baut eine Funktionalität in eine Komponente und testet diese für sich – bestenfalls mit einem künstlichen Integrations-Szenario. Denn das eigentliche Feature, mit dem man testen könnte, ist ja noch nicht fertig. Das nutzende Team stellt dann, nachdem das liefernde Team „fertig“ gemeldet hat, leider fest, dass es etwas (ggf. nur geringfügig) anderes benötigt, um eine wirklich gute Lösung zu produzieren. Der Weg des geringsten Widerstandes führt dann zu technisch fragwürdigen und aufwendigen Lösungen. Denn dann muss man mit dem arbeiten, was zugeliefert wurde. Hiervon ist allerdings dringend abzuraten. Bringen die Teams jedoch tatsächlich die Disziplin auf, für ein gutes Resultat noch einmal gemeinsam zu diskutieren, so kann hier durchaus eine gute Lösung entstehen – sie benötigt dann jedoch deutlich mehr Zeit. Die Diskussion muss geführt und danach durch das liefernde Team nachgebessert werden, was meist mindestens eine weitere Iteration bedeutet.

Fazit

Wie immer hängt es von den beteiligten Personen ab, wie gut die gewählte Lösung funktioniert. Schließlich. Es gibt auch ordentliche Kaffeeküchen, wenn auch selten. Je geringer die Komplexität des Vorhabens und je weniger Personen beteiligt sind, umso besser funktionieren Feature-Teams. Je höher die Komplexität und je mehr Beteiligte es gibt, umso mehr sinkt jedoch die Leistung und Qualität.

Komponenten-Teams liefern bei annähernd jeder Komplexität deutlich langsamer und kämpfen häufig mit technischen Abhängigkeiten. Die Qualität der Komponenten ist typischerweise gut, die des entstehenden Gesamt-Systems jedoch meist eher fragwürdig.

Grundsätzlich hat der Feature-Team-Ansatz deutliche Vorteile gegenüber den Komponenten-Teams. Um die negativen Effekte bei steigender Komplexität jedoch zu reduzieren, ist es durchaus sinnvoll, sich aus den Mitteln von Komponenten-Teams zu bedienen. So kann z. B. ein Feature-Team zusätzlich die Verantwortung für eine oder mehrere Komponenten übernehmen.

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*