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

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 8 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link