Geschrieben von Fachexperten: Anton Skornyakov, Certified Scrum Trainer® und Timon Fiddike, Certified Scrum Trainer®

Crossfunktionale Teams und Komponententeams – eine Gegenüberstellung

Table Of Contents

Komponententeams
Funktionsübergreifende, crossfunktionale Teams
Zusammenfassender Vergleich der Entwicklung mit Komponententeams vs. funktionsübergreifenden Teams
Über die Autoren

In diesem Beitrag möchten wir über die wichtigste Zutat von Scrum sprechen – die funktionsübergreifenden (oder crossfunktionale) Teams. Als Alternative dazu schauen wir uns eine andere typische Strukturierung von Gruppen in Unternehmen an, die Komponententeams. Schließlich zeigen wir typische Auswirkungen von Komponententeams und funktionsübergreifenden Teams auf die Performance der Organisation.

Komponententeams

Ich möchte zunächst ein Modell von Prozessen der Produktentwicklung vorstellen, wie wir sie schon sehr häufig in Unternehmen gesehen habe. Jeder einzelne große Entwicklungsschritt wird von einer dafür verantwortlichen Person oder Gruppe von Personen durchgeführt. Zum Beispiel dem Design-Team, dem Server-Team oder dem QA-Team. Wir nennen diese Teams „Komponententeams“. Der Name kommt daher, dass diese Teams typischerweise die vollständige Verantwortung für einzelne größere Komponenten des Systems haben.

Ist ein Team mit seiner Arbeit fertig, übergibt es die Arbeitsergebnisse (das fertige Design, die dokumentierte Schnittstelle etc.) an das nächste Team.

Planung der Arbeit

Alles beginnt mit einem Product-Backlog, der Liste von Dingen, die von dem/den Team(s) am Produkt zu tun sind. Wir nennen diese Dinge hier zur Einfachheit „Features“.

Im besten Fall ist diese Liste geordnet, ganz oben steht aus Sicht des gesamten Produkts das wertvollste nächste Feature. Es ist eines, das einen hohen Mehrwert mit (vergleichsweise) geringem Ressourceneinsatz erreicht. Ein gutes Backlog zu erstellen ist nicht einfach, und: Für diesen Beitrag nehmen wir an, dass es diese geordnete Liste der Dinge gibt. In der einen oder anderen Form ist eine solche Liste aber nahezu immer vorhanden, manchmal heißt sie auch Roadmap, Projektplan, Releaseplan etc.

Stellen wir uns nun vereinfachend vor, dass die Arbeit gerade erst anfängt und der Einsatz der Teams geplant wird. Für die Arbeit an “Feature 1” muss an allen 5 Komponenten unserer Produktentwicklung gearbeitet werden. Zuerst ist das Design-Team fertig und es übergibt seine Arbeit an das Client-Code-Team. Diese übergibt dann an das Server-Code-Team und anschließend geht das Ergebnis durch die Qualitätssicherung (QA) bevor es schließlich ausgeliefert wird (Deployment).

Planung: Weitere Features und Lücken in der Auslastung

Genau wie das erste Feature, wird nun auch das “Feature 2” geplant. Das zweite Feature braucht mehr Arbeit im Client-Code, dadurch ergibt sich, wie man im nächsten Bild sieht, eine Lücke für die Verantwortlichen für den Server-Code, die Qualitätssicherung und Auslieferung.

Was passiert normalerweise mit dieser “Lücke”? Typischerweise sucht man nach anderen Features, die in dieser “Lücke” sinnvoll bearbeitet werden können. In unserem Beispiel, war es möglich in “Feature 4” etwas zu finden, das schon vorweg im Server-Code gemacht werden kann. Dadurch konnte eine Lücke geschlossen werden. Für QA und Deployment konnten aber keine sinnvollen Aufgaben gefunden werden. Danach wurde das dritte Feature eingeplant.

Es sind wieder neue Lücken entstanden. Der Koordinationsaufwand, um die Lücken zu schließen wird typischerweise von einem Manager übernommen. Er verhandelt und spricht mit den verschiedenen Teams. Nehmen wir der Einfachheit halber an, dass fast alle Lücken mit sinnvollen Aufgaben geschlossen worden sind.

Beobachtungen: Konsequenzen

Zunächst einige Beobachtungen zu diesem Planungsmodell, wenn alles gut geht und der Plan funktioniert:

Verschiedener Fokus: In jedem Augenblick arbeiten alle Komponententeams an verschiedenen Features. Während das Design-Team an „Feature 1“ arbeitet, arbeitet das Client-Code-Team immer an einem anderen Feature.
Team-Verantwortung: Jedes Komponententeam trägt die Verantwortung für sein Arbeitsergebnis. Da hört auch meist die Verantwortung des Teams auf. Schließlich haben die Mitglieder des Komponententeams keinen Einfluß auf die Arbeit der anderen.
Verantwortung für Features: Meist trägt ein Außenstehender – ein Manager – die Verantwortung für das Gelingen eines ganzen Features. Häufig ist es auch der gleiche Manager, der die Planung verantwortet.
Auslastung: Jedes Komponententeam ist voll ausgelastet mit der Arbeit an seiner Komponente. Das ist auch häufig das, was diese Art von Planung (unausgesprochen) versucht zu maximieren – die Auslastung der teuren Ressource „Entwickler“.
Frühe Planung: Wie lange welches Team an einem Feature zu arbeiten hat, muss bei dieser Art von Einsatzplanung früh bekannt sein. Nue so hat der planende Manager eine Grundlage für seinen Zeitplan. Je früher Features geplant werden, desto mehr Spielraum gibt es um die “Lücken” in der Auslastung zu füllen.

Was passiert bei Veränderungen

Viele Unternehmen planen so, wie wir es oben erklärt habe, weil sie versuchen die knappen und teuren Ressourcen – gute Produktentwickler – möglichst effizient einzusetzen. Diese Art von Planung funktioniert aber nur dann, wenn alles wie geplant läuft. Wie in einem vergangenen Artikel erklärt, gibt es viele Quellen von Unsicherheit und Veränderung im Produktentwicklungsprozess. Die meisten dieser Quellen beruhen auf Faktoren, auf die eine Organisation keinen Einfluß hat. Lassen sie uns exemplarisch untersuchen, was mit der obigen Planung passiert, wenn einige solcher Veränderungen eintreten.

Szenario A: Aufwandsänderung

Beschreibung: Der geplante Zeitaufwand eines Teams für die Arbeit in ihrer Komponente stellt sich als deutlich zu klein oder zu groß heraus. Mögliche Gründe: Änderungen in der Verfügbarkeit des Personals, Updates von Werkzeugen oder verbundenen Technologien, unvorhergesehene interne Abhängigkeiten, technische Schulden oder Grenzfälle.

In diesem Beispiel ist der Aufwand für das Server-Code-Team deutlich größer geworden und kollidiert nun mit der Planung der Arbeit an Feature 4 und 6. Was wird jetzt wahrscheinlich passieren?

Option A: Längere Bearbeitungszeit akzeptieren. Konsequenz: Es entstehen wieder Auslastungslücken bei anderen Teams. Die gesamte Planung muss sich ändern, um die Gesamtauslastung wieder auf das vorherige Niveau zu steigern. Das bedeutet Mehrarbeit für den planenden Manager, Verhandlungen, Ablenkung der anderen Teams.

Option B: Das Server-Code-Team aufteilen und die Teile an mehreren Features gleichzeitig arbeiten lassen. Konsequenz: Am Ende dauert hierbei die Bearbeitung von Feature 1 noch länger, die Zeitpläne für Feature 4 und 6 ändern sich, da nicht das gesamte Team daran arbeitet. Das heißt wieder Arbeit für den Manager und Ablenkung für andere Teams, wie bei Option A. Dadurch, dass innerhalb eines Teams nun an verschieden Features gearbeitet wird, steigt der Zeitaufwand zusätzlich auch aus einem anderen Grund: wenn jemand bei einem Problem Unterstützung von einem Kollegen braucht, der jedoch momentan an einem anderen Thema arbeitet, muss sich dieser erst in das Feature mit den Problemen hinein denken. Der Zeitaufwand dafür kann bei anspruchsvollen Features durchaus groß sein, und anschließend kann der Aufwand dafür, in das vorherige eigene Thema wieder zurück zu wechseln, nach einer längeren Unterbrechung durchaus auch erheblich werden.

Option C: Überstunden fürs Server-Code-Team. Diese Option hat ihre natürlichen Grenzen, führt häufig zu geringerer Qualität und ist aus dem Blickwinkel der teuren und knappen Ressourcen – gute Produktentwickler – auf Dauer riskant.

Aufwandsänderungen führen also meistens zu einer Ablenkung mehrerer Teams, und damit einer Verringerung ihrer Effizienz. Die Team-Auslastung mag zwar auf dem Papier nicht kleiner werden, aber die Menge der Zeit, in der sich die Teams mit Verhandlungen und Planungsänderungen auseinandersetzen verringert die effektive Auslastung. Das Gegenteil vom erwünschten Ergebnis tritt ein.

Eine weitere Konsequenz von Aufwandsänderungen in diesem System ist, dass sich auch die Auslieferungstermine anderer Features ändern. Passieren solche Änderungen mehrmals in der Bearbeitungszeit eines Features, werden die Auslieferungstermine unverlässlich. Für Stakeholder, die vor allem auf die Auslieferung von Ergebnissen der Produktentwicklung achten, wird der Entwicklungsprozess dann häufig zu einer Blackbox, in die Anforderungen hineingehen und aus der irgendwann Ergebnisse zurückkommen.

Szenario B: Internes Feedback

Beschreibung: In diesem Szenario nehmen wir an, dass z.B. im Qualitätssicherungsprozess ein Problem aufgetaucht ist. Nicht alle Anforderungen, die mit dem Feature 1 verbunden sind, wurden erfüllt. Es braucht Nacharbeit im Design, Client-Code, Server-Code etc.

Wie im vorherigen Szenario muss die gesamte Planung (auch anderer Features) angepasst werden. Es gibt aber zusätzliche Optionen mit verschiedenen Konsequenzen:

Option A: Die entsprechenden Teams müssen die neuen Aufgaben für Feature 1 so früh wie möglich einplanen, schließlich ist es das wichtigste Feature. Konsequenz: Die Teams, die bereits in der Bearbeitung anderer Features stecken, müssen diese Arbeit zur Seite legen und sich wieder Feature 1 widmen. Wenn es fertig ist, gehen sie wieder zurück an die Arbeit am vorherigen Feature. Das sind mindestens zwei Änderungen des Arbeitskontexts, die jeweils einen eigenen Zeitverlust und damit Effizienzverlust bedeuten.

Option B: Die Teams dürfen zunächst die Aufgaben erledigen, an denen sie gerade arbeiten, um sich Feature 1 zu widmen. Konsequenz: Das Feature mit der ursprünglich höchsten Priorität wird nicht als erstes ausgeliefert. So werden die Ressourcen des Unternehmen nicht mehr optimal eingesetzt.

Grundsätzlich führt dieses Szenario auch wieder zur geringeren Effizienz aller Beteiligten, Mehrarbeit für den planenden Manager und zu einer geringeren Vorhersagbarkeit des Entwicklungsprozesses als Ganzes.

Szenario C: Veränderung im Backlog

Beschreibung: In diesem Szenario hat sich der Informationsstand des Unternehmens in Hinblick auf die Bedürfnisse der Kunden verändert. Das kann zum Beispiel aufgrund von Kundenfeedback geschehen, das ein Prototyp des Produkts zu Tage gefördert hat. Mit dem neuen Wissensstand werden Feature 4, 5 und 6 viel weniger wichtig. Feature 2 wird aber dafür deutlich umfangreicher und wichtiger.

Im Grunde sind die Konsequenzen dieser Veränderung ähnlich wie in den o.g. Szenarien. Zusätzlich kommt hinzu, dass ggf. Arbeit, die bereits an Feature 4, 5, 6 geleistet wurde, geparkt oder verworfen wird, da jetzt Feature 2 die höchste Priorität hat. Technisch unfertige Arbeit an Feature 4, 5, 6 später wieder zu verstehen und zu einem sinnvollen Abschluss zu führen, ist je nach Arbeitsstand mehr Aufwand, als frisch damit anzufangen. Da die hieran bereits geleistete Arbeit somit häufig später nur noch wenig Wert hat, bedeutet dies einen weiteren Zeit und Effizienzverlust.

Funktionsübergreifende, crossfunktionale Teams

In Scrum – einem populären agilen Framework – wird die Arbeit am Produkt von funktionsübergreifenden Teams erledigt. Die Teams sind per Definition dafür verantwortlich, in sich abgeschlossene Anforderungen, in unserem Beispiel Features, jeweils vollständig selbst zu implementieren. Teams sind dazu so zusammengesetzt, dass sie aufgrund ihrer gemeinsamen Fähigkeiten in der Lage sind alle Aktivitäten auszuführen, die dafür notwendig sind. In unserem Beispiel würden also die Teams typischerweise aus Personen bestehen die designen, Client-Code und Server-Code schreiben, die Qualität sichern und das Endprodukt ausliefern können.

Das folgende Schaubild stellt beide Planungsmodelle nebeneinander:

Scrum vs. Waterfall, Component-vs-crossfunctional-teams

Kennzeichen eines funktionsübergreifenden Teams

Einige wichtige Kennzeichen der Arbeit von funktionsübergreifenden Teams sind:

Zur gleichen Zeit Arbeiten alle Teammitglieder an einem Feature, oder es arbeiten zumindest jeweils mehrere Teammitglieder an jeweils einem Feature zusammen, so dass insgesamt nur sehr wenigen Features gleichzeitig in Arbeit sind. Mit der Arbeit an neuen Features wird erst dann angefangen, wenn ein anderes Feature vollständig fertig ist.
Am Ende einer Iteration sind mehrere Features vollständig fertig.
Während der Arbeit stimmen sich die verschiedenen Teammitglieder, und damit auch die verschiedenen Gewerke, in kurzen Abständen immer wieder miteinander ab. Unter Entwicklern, die bereits am gleichen Feature arbeiten, erzeugt die Abstimmung keine Ablenkung, da sie ohnehin einen sehr ähnlichen Kontext haben.
Es gibt viele gemeinsame Feedbackschleifen: Vom Design zum Client Code, vom Server Code zum Design, von QA an Client Code etc.
Mitarbeiter mit Hauptschwerpunkt in einem Bereich, z.B. Server-Code, verbringen regelmäßig Zeit in den Spezialgebieten ihrer Kollegen, und zwar jeweils dann, wenn sie dort gerade sinnvoll unterstützen können. Hierdurch sind die Arbeitsaufwände in den jeweiligen Gewerken nicht die gleichen, wie die Aufwände der Komponententeams. Die Aufwandsspitzen (z.B. besonders viel Arbeit am Client-Code) werden geglättet, da diese von Kollegen aus anderen Bereichen zum Teil aufgefangen werden können. Wir haben schon oft erlebt, dass motivierte Entwickler sehr gerne die Chance nutzen, auf dieser Weise dazu zu lernen und Features werden deutlich schneller fertig.
Man kann hier wirklich von einem Team sprechen: Ein Team im engeren Sinne ist eine Gruppe von Menschen, die zur gleichen Zeit gemeinsam aufs gleiche Ziel hin arbeiten.
Das funktionsübergreifende Team braucht wenig Aufmerksamkeit bzgl. Planung der Arbeitsaufgaben, da die Abstimmung der Gewerke innerhalb des Team stattfindet und dadurch größtenteils offensichtlich ist.