Floating Teams: das 7+/-2-Dogma sprengen

Wenn klassische Teamgrößen schwierig werden

Landläufig geht man häufig von Teamgrößen von sieben Teammitgliedern plus/minus zwei aus. Dafür gibt es gute Gründe. Es ist aber nicht immer der Weisheit letzter Schluss. In Kontexten, in denen bis zu 30 Personen in Teams arbeiten sollen, fällt es nicht immer leicht, stabile Teams der o.g. Größe zu bilden.

Gründe für diese Schwierigkeiten können sein:

  • Bestimmte Fähigkeiten sind nur bei wenigen Personen vorhanden, werden aber in jedem Team gebraucht.
  • Die Fähigkeiten, die für Ende-Zu-Ende-Umsetzung von Features notwendig sind, verteilen sich auf mehr als neun Personen. Das kommt insbesondere dann häufiger vor, wenn (auch) Hardwareentwicklung betrieben wird.

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ütrzlich, 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).

  • Kontakt

    Sabrina Spiegel

    Sabrina Spiegel, geboren 1989 in Gifhorn, studierte Game Design in Berlin. Der agile Gedanke wurde bei ihr im Studium gesät. Sie suchte dort eine Möglichkeit in einem selbstorganisierten und motivierten Team zu arbeiten. Dabei lernte sie, dass das agile Mindset zum Grundpfeiler für gute Zusammenarbeit und hervorragender Produktentwicklung gehört. Heute sät sie selber den agilen Samen in Organisationen. Seit Mitte 2016 macht sie das als Teil von it-agile.

    Ihre Freizeit verbringt sie am liebsten in der Boulderhalle oder spielt mit ihren Freunden Spiele aller Art.

  • E-Mail

    Sabrina Spiegel ist unsere Expertin für Floating Teams und berät sie gerne. Schreiben Sie ihr gerne eine E-Mail an sabrina.spiegel@it-agile.de.