Funktionsübergreifende Teams und Komponententeams – eine Gegenüberstellung

By am 28.03.2016 in Agile, Scrum

In diesem Beitrag möchte ich ü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 zeige ich typische Auswirkungen von Komponententeams und funktionsübergreifenden Teams auf die Performance der Organisation.

Product-Backlog

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

scrum: crossfunctional teams warum

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 wir schreiben darüber noch in zukünftigen Beiträgen. Für diesen Beitrag nehmen wir aber einfach 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.

Komponententeams

Ich möchte zunächst ein Modell von Prozessen der Produktentwicklung vorstellen, wie ich 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

Stellen wir uns nun vereinfachend vor, dass die Arbeit gerade erst anfängt und der Einsatz der Entwicklungsmannschaften 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).

scrum: funktionsübergreifende Teams 2

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.

Scrum: krossfunktionale Teams 3

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.

Scrum: krossfunktionale Teams 3

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.

Waterfall Complete

Beobachtungen

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 ich 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.

Mehr-Aufwand-Szenario

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 und Verhandlungen mit Ablenkungen 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. Es gibt noch eine Reihe von weiterer Nebeneffekte dieser Option, über die wir in einem anderen Blogpost sprechen wollen.

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 aller 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 ursprünglich erwarteten Ergebnis tritt ein.

Eine weitere Konsequenz von Aufwandsänderungen in diesem System ist, dass sich auch die Auslieferungstermine aller Features ändern. Passieren solche Änderungen mehrmals in der Bearbeitungszeit eines Features, werden die Auslieferungstermine unvorhersagbar. 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.

Internes-Feedback-Szenario

Wie im vorherigen Szenario muss die gesamte Planung aller 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 großen 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.

Market-Change-Szenario

Im Grunde sind die Konsequenzen dieser Veränderung ähnlich wie in den obigen Szenarien. Zusätzlich kommt hinzu, dass ggf. Arbeit die bereits an Feature 4,5,6 angefangen wurde verworfen wird, da jetzt Feature 2 die höchste Priorität hat.

Funktionsübergreifende, crossfunktionale Teams

In Scrum – einem populären agilen Framework – wird die gesamte Arbeit am Produkt von funktionsübergreifenden Teams erledigt. Das bedeutet die Teams sind per Definition dafür verantwortlich, die gesamten Anforderungen, in unserem Beispiel Features, jeweils vollständig selbst zu implementieren. Teams sind also 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:

  1. Zur gleichen Zeit Arbeiten alle Teammitglieder an einem oder nur sehr wenigen Features. Mit der Arbeit an neuen Features wird erst dann angefangen, wenn ein anderes Feature vollständig fertig ist.
  2. Am Ende einer Iteration sind mehrere Features vollständig fertig.
  3. Während der Arbeit stimmen sich die verschiedenen Gewerke permanent miteinander ab. Da alle den gleichen Kontext haben – das gemeinsame Feature – erzeugt die Abstimmung keine Ablenkung.
  4. Es gibt viele gemeinsame Feedbackschleifen: Vom Design zum Client Code, vom Server Code zum Design, von QA an Client Code etc.
  5. 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.
  6. Man kann hier wirklich von einem Team sprechen, da es sich um eine Gruppe mit einem gemeinsamen Ziel handelt.
  7. Das funktionsübergreifende Team braucht keinen Manager, der die Planung der Arbeitsaufgaben übernimmt, da die Abstimmung im Team stattfindet und größtenteils offensichtlich ist.

Veränderung im Prozess mit funktionsübergreifenden Teams

Szenario A

Verändert sich das Arbeitsvolumen in einem Bereich an einem Feature, so hilft das gesamte Teams aus. Das gesamte Feature braucht länger und es kann sein, dass nicht alle für die Iteration geplanten Features ausgeliefert werden. Die Prioritäten, die das Backlog vorgibt, werden aber in jedem Fall eingehalten und es werden in jedem Fall vollständige Features am Ende einer Iteration ausgeliefert. Es ergibt sich kein zusätzlicher Managementaufwand und es entstehen keine Ablenkungen im Team.

Szenario B

Internes Feedback ist in einem funktionsübergreifenden Team stets willkommen. Andere Gewerke, die das Feedback von ihrem speziellen Standpunkt aus geben, sind Teil des eigenen Teams. So kommen das Feedback und die daraus resultierende Änderungen sehr schnell ans Licht. Verglichen mit dem anderen Prozessmodell werden so Mehraufwände (Verschwendung) minimiert.

Szenario C

Die konkrete Arbeit wird am Anfang der jeweiligen Iteration geplant. Dadurch können Veränderungen des Backlogs zu Beginn jeder Iteration vollständig berücksichtigt werden. Da eine Iteration zwischen 1-4 Wochen dauert (typisch sind 2 Wochen), können die meisten Änderungen von Prioritäten berücksichtigt werden, ohne dabei das Team abzulenken.

Zusammenfassend kann man sagen, dass die Ergebnisse der Arbeit von echten crossfunktionalen Teams sehr viel vorhersagbarer sind. Und sie bleiben es, wenn es auch noch so viele Überraschungen im Entwicklungsprozess gibt.

Empirische Prozesskontrolle und kontinuierliche Verbesserung

Empirische PlanungWenn eine Organisation funktionsübergreifende Teams hat, die in Iterationen arbeiten, dann ist sie in der Lage, die Ergebnisse der einzelnen Iterationen zu messen. Vereinfacht betrachtet (für das Beispiel gehen wir zunächst von gleich großen Features aus) zählt man die Anzahl gelieferter Features je Iteration. In die Zukunft schauend lässt sich dann planen, wie viele Features das Team ungefähr im nächsten Monat, Quartal oder Jahr ausliefern wird. Bei dieser Betrachtung sind alle typischen Unsicherheiten und Änderungen automatisch eingerechnet, da man sich auf Messwerte für vergangene Iterationen bezieht, in denen es auch schon zu Änderungen kam. Das ist die Grundlage der empirischen Prozesskontrolle. Es gibt auch Strategien, durch die man dieses Prinzip auch dann anwenden kann, wenn die Größe von Features unterschiedlich ist.

Selbstverbesserung:Diese Art von Ergebnismessung ermöglicht nicht nur eine bessere Planung, sondern macht auch eine kontinuierliche Prozessverbesserung durch das Team möglich. Weil der gesamte Entwicklungsprozess im Team stattfindet kann das Team Änderungen vornehmen und dabei das große Ganze im Blick behalten. Neue Praktiken können in jeder Iteration ausprobiert werden und da das Ergebnis gemessen wird, kann man leicht feststellen, ob die Veränderung etwas genützt hat oder nicht. Durch die relativ kurze Dauer einer Iteration kann man so mit überschaubarem Risiko experimentieren.

Zusammenfassender Vergleich der Entwicklung mit Komponententeams vs. funktionsübergreifenden Teams

Mit Komponententeams versuchen Unternehmen typischerweise die Effizienz durch Auslastung ihrer Entwicklungsressourcen zu steigern. Das daraus resultierende Planungsmodell führt zu vielen Problemen, wenn Veränderungen auftreten. Für Außenstehende äußert sich dies durch:

  • fehlende Vorhersagbarkeit des Prozesses
  • steigender Managementaufwand bei Veränderungen
  • Arbeit an anderen als den wichtigsten Aufgaben

Durch Strukturierung in funktionsübergreifende Teams genießt das Unternehmen folgende Vorteile:

  • geringerer Managementaufwand
  • höhere Liefergeschwindigkeit durch weniger Ablenkung
  • zuverlässiger Lieferungrhythmus für neue Funktionalitäten
  • höhere Produktqualität durch viele schnelle Feedbackschleifen und gegenseitige Kontrolle

Diese Vorteile bleiben auch bei vermehrtem Aufkommen von Veränderungen bestehen.

Weitere Vorteile von funktionsübergreifenden Teams sind:

  • Möglichkeit empirisch die Ergebnisse der Arbeit zu messen und so sicherer zu planen
  • Möglichkeit einer kontinuierlichen Prozessverbesserung, basierend auf empirischen Ergebnissen jeder Iteration
  • höhere Produkt-Qualität durch direkte Verantwortung der Entwickler für die Feature-Qualität, statt der Verantwortung eines Managers
  • höhere Motivation der Mitarbeiter

Kommentieren

Kommentare bitte per Twitter an @Coach_Agile senden.