Feature-Teams vs. Komponenten-Teams

Wenn zur Weiterentwicklung eines Produktes mehr als ein Team benötigt wird, steht jede Organisation zwangsläufig vor der Entscheidung, ob sie Feature-Teams oder Komponenten-Teams bilden soll.

Solange ein Produkt durch ein einzelnes Scrum Team entwickelt wird, ist die Unterscheidung zwischen Komponenten- und Feature-Teams irrelevant, weil Deine Organisation (im besten Fall) ein selbstorganisiertes, interdisziplinäres Produkt-Team aufgestellt hat.

Große Produkte benötigen jedoch meist mehr Manpower als ein einzelnes Scrum Team bieten könnte. Das gilt selbst dann, wenn dieses Scrum Team sehr leistungsstark ist und ein echtes High-Performance Team ist.

Deshalb wird die Entscheidung, ob Feature- oder Komponenten-Teams gebildet werden sollten, für Dich erst dann relevant, wenn Du Dich in einem skalierten Umfeld befindest und beispielsweise Nexus Scrum oder LeSS nutzen möchtest, um mit mehreren Teams an einem einzelnen Produkt zu arbeiten.

Wenn es darum geht, mit mehreren Teams an einem einzigen Produkt zu arbeiten, können diese entweder so organisiert werden, dass sie sich um bestimmte Komponenten kümmern und für diese die Verantwortung tragen. Oder sie sind so aufgebaut, dass sie eine bestimmte Funktionalität für den Nutzer umsetzen können, die dann meistens mehrere Komponenten eines Produktes betreffen.

Wie der Name bereits impliziert, sind Komponenten-Teams für eine oder mehrere Komponenten eines (Software-)Produktes verantwortlich.

Das können beispielsweise die Benutzeroberfläche, das Backend mit dem Admin-Dashboard, die Schnittstellen einer Software oder die dazugehörige Datenbank einer Software sein.

Große Produkte können darüber hinaus aus mehreren Einzel-Komponenten bestehen. Eine ERP-Software kann zum Beispiel eine (zusätzliche) Komponente Kasse beinhalten.

Beispiele für Komponenten-Teams sind Frontend-Teams, Datenbank-Teams, Schnittstellen-Teams oder eben auch Kassen-Teams. Sie alle sind ausschließlich für ihre jeweilige Komponente verantwortlich.

Im Gegensatz zu Komponenten-Teams orientiert sich die Struktur von Feature-Teams an der Funktionalität eines Produktes bzw. den Prozessen oder den Jobs to Be Done der Nutzer. Weil Funktionen oder Prozessschritte der Nutzer jedoch in der Regel auf mehreren Komponenten (bzw. Layern) basieren, kann (und muss) ein Feature-Team deshalb auch alle betreffenden Komponenten verändern und überarbeiten (können).

Ein Feature-Team besteht demnach oft aus einem Frontend-, einem Backend- und einem Datenbank-Entwickler sowie einem Entwickler, der sich gut mit Schnittstellen auskennt.

Darüber hinaus ist es auch denkbar, dass ein Feature-Team für Zahlungsprozesse einer Software verantwortlich ist. Es könnte dann (bei einer großen Software) sowohl die Komponente Kasse, Scanner, Bondrucker etc. weiterentwickeln.

In der Software-Entwicklung werden die Komponenten Frontend, Backend, Datenbank etc. auch häufig als Layer bezeichnet.

Manchmal wird deshalb auch von Layer-Teams gesprochen, wenn sich der Aufbau dieser Teams an diesen Strukturen einer Software orientiert.

Bei kleineren Produkten ist häufig so, dass ein einziges Scrum Team alle notwendigen Komponenten und Layer einer Software kennt und weiterentwickelt. In diesem Fall haben wir es dann mit einem Produkt-Team zu tun.

Diese Teams sind – wenn Du so möchtest – ebenfalls Feature-Teams, da sie alle notwendigen Fähigkeiten besitzen (müssen), um das Produkt als Ganzes weiterzuentwickeln.

Wenn Organisationen neue, innovative Produkte entwickeln, bilden sie sehr häufig zunächst ein kleines Produkt-Team, das die Entwicklung dieses Produktes vorantreiben soll. Wenn es gut läuft, bilden sie in diesem Moment ein interdisziplinär arbeitendes Scrum Team.

Oft ist dieses Produkt jedoch nicht das einzige des Unternehmens, sondern steht in Verbindung mit weiteren Produkten der Firma oder ist in Wirklichkeit Teil eines großen Portfolios.

Solange die Entwicklung solcher neuen Produkte unabhängig vorangetrieben wird, entstehen wenig bis keine Probleme. Wird das neue Produkt jedoch in ein größeres Produkt integriert, wird das bisherige Team “so wie es ist”, in die existierende Struktur der anderen Teams übernommen. In diesem Kontext wird das vorherige Produkt-Team zu einem Komponenten-Team.

Ein weiterer Grund für die Entstehung von Komponenten-Teams sind natürlich auch existierende Abteilungen in einem Unternehmen. Wenn in einer Organisation eine Abteilung für Datenbanken existiert, werden nur selten interdisziplinäre Teams gegründet, deren Mitglieder alle einen Datenbank-Experten besitzen. Vielmehr wird die Entstehung von Datenbanken-Teams gefördert.

Bei der Umsetzung einer Funktion für Nutzer und Kunden entstehen zwangsläufig Abhängigkeiten zwischen allen beteiligten Komponenten-Teams.

Beispielsweise kann die Umsetzung eines Features Änderungen und Erweiterungen am Frontend, dem Backend oder der Datenbank eines Softwareproduktes erfordern.

Diese Abhängigkeiten zwischen den Komponenten-Teams müssen deshalb durch Übergaben, Koordination oder passende Prozesse geregelt werden.

Unterschiedliche Priorisierungen in den einzelnen Komponenten-Teams, die durch Anforderungen von (abteilungsinternen) Projekten entstehen, machen es beinahe unmöglich, hier ein Gleichgewicht herzustellen. Oft ist der absolute Stillstand die Folge.

Wenn Teams so zusammengestellt sind, dass sie lediglich für eine einzelne Komponente verantwortlich sind, entstehen neben den ungewollten Abhängigkeiten zwangsläufig auch (reine) Spezialisten. Die Mitglieder solcher Teams kennen sich dann lediglich in einem einzigen, bestimmten Thema gut aus, ohne eine Blick für benachbarte Wissensgebiete zu besitzen. Langfristig werden diese Teams (und ihre einzelnen Teammitglieder) zu Wissensinseln. Ohne ihr Know-how lässt sich dann gar nichts mehr bewegen.

Feature-Teams eliminieren diese Nachteile von Komponenten-Teams, weil sie eine Funktion für den Nutzer über mehrere Komponenten hinweg umsetzen können. Das notwendige Know-how ist also nicht mehr auf mehrere, voneinander abhängige Teams verteilt, sondern in einem einzigen Team vereint.

Dadurch entfallen Koordination, notwendige Prozesse aufgrund von Abhängigkeiten und letztlich auch Wartezeiten durch unterschiedliche Priorisierungen in verschiedenen Teams. Feature-Teams können deshalb selbstorganisiert und autonom Nutzen für Kunden stiften.

In Teams, die nach dem Feature-Prinzip strukturiert sind, entwickeln die einzelnen Mitglieder (langfristig) sogenannte T-Shaped Skills.

Das bedeutet, dass sie neben ihrem Spezialwissen auch Know-how in anderen und verwandten Wissensdomänen erlangen.

Dieser Prozess entsteht beispielsweise schon alleine durch gemeinsame Backlog Refinements, kann aber natürlich auch durch Pair Programming und andere Methoden aktiv gefördert werden.