Scrum und XP im harten Projektalltag

15
Wie wir mit mehreren Scrum-Teams
umgehen
Vieles wird komplizierter, wenn Sie mehrere Scrum-Teams haben, die am
gleichen Produkt arbeiten. Das Problem "je mehr Entwickler, desto mehr
Komplikationen" gilt generell und ist keine Besonderheit von Scrum.
Wie so oft haben wir auch hier herumexperimentiert. Unser größtes Team
bestand aus 40 Mitarbeitern, die alle am gleichen Produkt arbeiteten.
Es ergeben sich die Kernfragen:
• Wie viele Teams soll man schaffen?
• Wie verteilt man die Mitarbeiter auf diese Teams?
Wie viele Teams soll man aufstellen?
Wenn die Verwaltung mehrere Scrum-Teams so schwierig ist, warum
befassen wir uns dann überhaupt damit und stecken nicht einfach alle in
ein Team?
Das größte Scrum-Team, das wir einmal hatten, bestand aus elf Leuten.
Es funktionierte, aber nicht besonders gut. Das tägliche Scrum-Meeting
(Daily Scrum) überschritt oft die 15 Minuten-Grenze. Es entstand
Verwirrung, weil Teammitglieder nicht wussten, woran andere gerade
arbeiteten. Der ScrumMaster hatte seine Schwierigkeiten damit, alle auf
ein gemeinsames Ziel einzuschwören und sich um jedes an ihn
herangetragenes Problem zu kümmern.
Eine Alternative ist, sich in zwei Teams aufzuteilen. Aber ist das besser?
Nicht zwangsläufig.
Es ist in jedem Fall eine gute Idee, wenn ihr Team eingespielt und Scrumerfahren
ist, Sie eine sinnvolle Möglichkeit finden, das Gesamtprojekt in
zwei Teilprojekte zu zerlegen und sich der Quellcode der Teilprojekte
auch noch gut separieren lässt. Gilt das nicht, belassen Sie es trotz der
Nachteile lieber bei nur einem großen Team. Meiner Erfahrung nach sind