Teamzuständigkeiten in Scrum – von Komponententeams zu Feature Teams

Das Team eines großen Scrum-Projekts umfasst meist so viele Mitarbeiter, dass eine Unterteilung in mehrere kleinere Teams notwendig wird, die jeweils für die Entwicklung einer Komponente zuständig sind (Komponententeams). Doch bei der Realisierung neuer Features sind oft mehrere Komponenten betroffen, was einen hohen Bedarf an teamübergreifender Koordination erfordert. Klaus-Dieter Schmatz und Ivan Kostial stellen deshalb einen alternativen Ansatz für die Teamorganisation in großen Scrum-Projekten vor: die Feature Teams. Diese Form der Projektorganisation vereinfacht die Abstimmung, da die Teams nicht mehr für einzelne Komponenten, sondern für ganze Features verantwortlich sind.

 

Teamzuständigkeiten in Scrum – von Komponententeams zu Feature Teams

Das Team eines großen Scrum-Projekts umfasst meist so viele Mitarbeiter, dass eine Unterteilung in mehrere kleinere Teams notwendig wird, die jeweils für die Entwicklung einer Komponente zuständig sind (Komponententeams). Doch bei der Realisierung neuer Features sind oft mehrere Komponenten betroffen, was einen hohen Bedarf an teamübergreifender Koordination erfordert. Klaus-Dieter Schmatz und Ivan Kostial stellen deshalb einen alternativen Ansatz für die Teamorganisation in großen Scrum-Projekten vor: die Feature Teams. Diese Form der Projektorganisation vereinfacht die Abstimmung, da die Teams nicht mehr für einzelne Komponenten, sondern für ganze Features verantwortlich sind.

 

Nach der Scrum-Philosophie besteht ein Software-Entwicklungsprojekt idealerweise aus einem einzigen Team mit sieben Personen, die alle im selben Raum arbeiten. In der Praxis sieht es häufig anders aus: Das Projektteam ist so groß, dass eine Unterteilung in mehrere (Sub-)Teams angebracht ist. Darüber hinaus sind die Projektteams nicht selten über verschiedene Standorte verteilt. Die Notwendigkeit für große und verteilte Projektteams ergibt sich aus dem Umfang und der Komplexität der Anforderungen, die in einem engen Zeitrahmen realisiert werden müssen und der Frage, wo im Unternehmensverbund Ressourcen mit passenden Qualifikationen verfügbar sind.

Um die Verantwortlichkeiten der einzelnen Teams festzulegen, existieren verschiedene Ansätze. Im vorliegenden Artikel beschreiben wir unsere Erfahrungen mit zwei Teamformen: Komponententeams und Feature Teams. Unsere Erfahrungen beziehen sich auf mehrere nach Scrum durchgeführte Softwareprojekte mit jeweils bis zu fünf Teams in drei verschiedenen Ländern und einer Projektlaufzeit von bis zu zwei Jahren. Diese Projekte hatten zum Ziel, medizintechnische Anwendungen im Bereich der Strahlentherapie zu realisieren.

Erfahrungen mit Komponententeams

In den ersten Projekten bildeten wir Komponententeams. Dieser Ansatz erscheint logisch, da sich die Teamstruktur einfach an der Struktur der zu entwickelnden Applikation orientiert. Eine Applikation besteht aus einer Menge von interagierenden Komponenten, durch deren dynamisches Zusammenspiel die Anwendung so funktioniert, wie es vorgesehen ist. Bei diesem Ansatz übernimmt jedes Team die Verantwortung für eine oder mehrere Komponenten. Nur das jeweils zuständige Team darf Änderungen in einer Komponente vornehmen.

Diesem Ansatz folgend könnte es beispielsweise ein Datenbank-Team geben, das sich um die Definition des Datenbankschemas und die Programmierung der Datenzugriffsschicht kümmert, ein Geschäftslogik-Team, das die Implementierung der Geschäftslogik übernimmt und ein Front-end-Team, welches die Bedienoberfläche der Applikation bereitstellt.

Mehrere Teams koordinieren

Die meisten Features einer Applikation betreffen allerdings mehrere Komponenten, wobei es häufig vorkommt, dass diese Komponenten unterschiedlichen Teams zugeordnet sind. In diesen Fällen ist eine teamübergreifende Koordination erforderlich: Zunächst müssen sich die beteiligten Teams auf eine gemeinsame technische Lösung verständigen. Dies geschieht häufig durch die Mitwirkung eines übergeordneten Architekten. Als nächstes vereinbaren sie die Realisierungsreihenfolge und Bereitstellungstermine für die Komponenten. Und schließlich müssen geeignete Maßnahmen gefunden und abgestimmt werden, wenn sich die Zulieferung einzelner Komponenten verspätet. Da es sich um teamübergreifende Aktivitäten handelt, ist der Projektleiter (oder ein Mitglied des Kernteams) bei der Planung und Steuerung involviert. Bild 1 veranschaulicht diesen Ansatz.

Bild 1: Teamaufteilung nach Komponententeams.

Beispiel

Ein einfaches Feature könnte sein, die Anwendung um ein zusätzliches Informationsfeld zu erweitern. Dafür muss das Datenbank-Team ein Attribut in einer Datenbanktabelle ergänzen und die Datenzugriffsschicht entsprechend erweitern. Das Front-end-Team implementiert den Code, um diese neue Funktionalität der Datenzugriffsschicht aufzurufen und die Daten im User Interface zu repräsentieren. Auch wenn diese Änderung trivial erscheinen mag, so müssen die dafür nötigen Arbeitspakete teamübergreifend geplant werden. Abweichungen vom abgestimmten Vorgehen, etwa durch eine verspätete Bereitstellung einer Schnittstelle, können mitunter drastische Auswirkungen haben: Wenn das Datenbank-Team die Erweiterung der Datenzugriffsschicht nicht fristgerecht abschließen kann, ist das Front-end-Team blockiert und die Fertigstellung des gesamten Features verzögert sich.

Die Projektstruktur überdenken

Generell folgen alle unsere Projekte einem agilen Vorgehensmodell. Die Projektlaufzeit ist in einzelne Iterationen unterteilt, die jeweils das Ziel haben, eine bestimmte Menge an Features in vollem Umfang – Design, Implementierung, Unit Test, Integrationstest und Dokumentation – zu realisieren. Die Iterationen der einzelnen Teams verlaufen synchron, d.h. der Beginn und die Dauer jeder Iteration sind für alle Teams einheitlich. Innerhalb dieses Rahmens machten wir bei den Projekten, die wir mit Komponententeams realisierten, die folgenden Beobachtungen, die uns im Lauf der Zeit zum Nachdenken brachten, ob es nicht einen besseren Ansatz gibt, das Projekt zu strukturieren:

  • Wir arbeiteten mit einer relativ langen Iterationsdauer, die je nach Projekt zwischen vier und sechs Wochen lag. Wir hätten uns kürzere Iterationen gewünscht, da der Product Owner dann die Möglichkeit gehabt hätte, schneller und häufiger Feedback zu geben. Eine Verkürzung der Iterationsdauer scheiterte jedoch einerseits daran, dass wir uns im Umfeld der Medizinprodukte bewegen, in dem es strenge Dokumentationsanforderungen gibt. Weiterhin konnten wir die Iterationsdauer nicht verringern, da sich sowohl die technischen Abstimmungen zwischen den Teams am Iterationsbeginn sowie die Integration der einzelnen Komponenten zum Iterationsende als zeitaufwändig erwiesen.
  • Um dem hohen Koordinationsbedarf zwischen den Teams gerecht zu werden, richteten wir regelmäßig stattfindende Scrum-of-Scrum-Meetings mit Vertretern aus allen Teams ein. Ein häufiger Diskussionspunkt war dabei, dass fehlende Zulieferungen von anderen Teams die Weiterarbeit blockierten.
  • Ein großer Anteil an teamübergreifenden Features konnte nicht innerhalb der ursprünglich geplanten Iteration fertiggestellt…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 1
Kommentare 0