Floating Team: großes Team, temporäre Subteams
Es ist möglich, große Teams aus 20-30 Personen zu bilden. Damit steigen natürlich die Kommunikationskosten an, wenn diese große Menge an Personen sich als Ganzes selbstorganisiert. Man stelle sich nur mal ein Daily Scrum mit 30 Personen vor.
Daher bilden sich temporäre Subteams aus drei bis vier Teammitglieder, die sich jeweils um die Entwicklung eines Features kümmern. Die Subteams bleiben ein bis zwei Wochen zusammen.
Dieser Ansatz nennt sich Floating Team (fließendes Team).
Floating Team-Mechanik
Der Product Owner führt zusammen mit dem ganzen Team ein Sprint Planning durch, in dem das Team abschätzt, wieviele der hochpriorisierten User Stories es im Sprint umsetzen kann. Es findet kein detaillierter Task-Breakdown im Sprint Planning statt.
Anschließend bilden sich Subteams rund um die hochpriorisierten eingeplanten Features. Sie arbeiten für eine Woche an dem Feature (bei vierwöchtigen Sprints ist es auch möglich, dass die Subteams für zwei Wochen zusammen bleiben). Während der Woche stimmen sich die Entwickler nur innerhalb ihrer Subteams ab. Das kann über Daily Scrums erfolgen. Wegen der kleinen Subteam-Größe sind aber meist gar keine Daily Scrums notwendig.
Nach der Woche kommen die Subteams zusammen, informieren sich über den Fortschritt und bilden neue Subteams für die nächsten Features. Wenn eine User Story nicht fertig geworden ist, kann dasselbe Subteam weiter an der Story arbeiten oder die Zusammensetzung des Subteams wird geändert.
Sprint Review und Sprint Retrospektive werden mit dem ganzen Team gemeinsam durchgeführt.
Voraussetzungen für Floating Teams
Floating Teams erlauben eine leichtgewichtige Skalierung mit sehr wenig Overhead bei großer Flexibilität. Sie funktionieren aber nur unter bestimmen Voraussetzungen:
- Die Teammitglieder müssen bereits erfahren haben, was es bedeutet, gemeinsam Verantwortung zu übernehmen (dafür ist es nützlich, wenn sie vorher bereits in klassischen agilen Teams gearbeitet haben).
- Im Gesamtteam herrscht psychologische Sicherheit. Nur dann können sich die Teammitglieder schnell auf die wechselnden Zusammenarbeitskonstellationen einlassen.
- Die Teammitglieder sind agiles Arbeiten gewohnt (ansonsten werden sie Schwierigkeiten haben, den Sprint-Inhalt abzuschätzen, ohne detaillierten Task-Breakdown durchzuführen).
