Artikel versenden

Scrum mit mehreren Teams




 

// / / /

Ideal funktioniert Scrum mit einem Team von fünf bis sieben Leuten. Damit lassen sich schon viele Projekte effizient angehen, aber es gibt immer auch Aufgaben, die eine größere Mannschaft erfordern. Hierzu empfiehlt es sich, mit einem Team zu starten und die Mitglieder dieses ersten Teams dann als Keimzellen für weitere Teams zu verwenden. Neben großen Projekten findet man auch bei der Weiterentwicklung von Produkten häufig mehrere Teams, die parallel an verschiedenen Aspekten und Modulen arbeiten. Und obwohl der typische Skalierungsmechanismus eines „Scrum of Scrum“ hinreichend bekannt ist, kommt es bei der Zusammenarbeit mehrerer Teams immer wieder zu Problemen, die sich meist auch nur indirekt äußern:

  • Funktionalitäten werden in verschiedenen Modulen mehrfach entwickelt.
  • Verschiedene Erweiterungen an Klassenhierarchien sind inkonsistent und verletzten damit z.B. das Liskov Substitution Principle.
  • Insgesamt nimmt die Codequalität ab und dadurch
  • sinkt die Velocity der Teams.

Die Ursache dieser Probleme ist dabei aber nicht eine möglicherweise nicht gegebene Skalierbarkeit von Scrum, sondern schlicht eine unzureichende Abstimmung der Beteiligten untereinander. Diese wiederum ist für viele Facetten der Softwareentwicklung notwendig. In der Praxis haben sich daher eine ganze Reihe unterschiedlicher Methoden bzw. Gremien bewährt, um das klassische Scrum of Scrum, also die tägliche Abstimmung der Teams untereinander, zu ergänzen. Einige seien hier stellvertretend genannt:

  • Architectual Board
    Die Teams sollten sich nicht nur über die konkreten Userstories, sondern auch über die jeweils notwendigen Anpassungen an der Gesamtstruktur, also der Architektur austauschen. Nur so kann gewährleistet werden, dass die verschiedenen Änderungen auch noch ein insgesamt konsistentes Ganzes ergeben. In der Regel trifft sich das Board mit je einem Vertreter der Teams direkt im Kontext des Sprint Planning. Ob darüber hinaus regelmäßige Treffen, z.B. im Wochenrhythmus sinnvoll sind, muss jeweils in der Situation entschieden werden.
  • Scrum of Product Owner
    Nicht nur die Teams, auch die Product Owner müssen sich abstimmen. Zunächst natürlich um zu vermeiden, sich widersprechende Userstories umsetzen zu wollen. Insbesondere aber auch, wenn sich thematische Schwerpunkte einzelner Teams herausgebildet haben, damit Zuarbeiten der Teams untereinander koordiniert werden können. Außerdem gilt es sicherzustellen, dass die jeweils über Alles am wichtigsten Stories umgesetzt werden und nicht die für den jeweiligen PO am wichtigsten erscheinenden. Konkret: Wenn PO A ein wichtiges Thema auf dem Backlog hat, kann es sein, dass alle zugehörigen Stories wichtiger sind, als die im Backlog von PO B und daher sinnvollerweise beide Teams an Stories von PO A arbeiten. Für solcherlei Abstimmungen bietet es sich an, ein Scrum of PO jeweils zwischen den Sprint Plannings durchzuführen.
  • Scrum of Scrum Master
    Wenn mehrere Teams parallel arbeiten, insbesondere wenn sich im einem ähnlichen Kontext bewegen, ist zu erwarten, dass sie auf ähnliche Probleme stoßen. Es bietet sich daher an, einen täglichen Austausch auf Ebene der Scrum Master zu etablieren, um gemeinsame Probleme zu identifizieren und diese entsprechend angehen zu können.

Doch welche Form der Abstimmung auch gewählt wird, jedes zusätzliche Meeting ist immer auch ein Impediment, da es mindestens ein Team-Mitglied an der konkreten Arbeit hindert. Zusätzliche Gremien sollten also zurückhaltend und mit einem konkreten Ziel eingeführt werden.

 

 

Quelle Bild: © fotovika – Fotolia.com

| Keine Kommentare

 
Top | Impressum