Wie terminiert man am Besten die SCRUM-Events bei zwei oder mehreren Teams?

Question

Es kommt immer wieder mal vor, dass man nicht nur ein SCRUM-Team hat sondern evtl. mehrere. Wenn es dann noch der Fall ist, dass die Sprints der Teams parallel laufen, kommt man unweigerlich in die Situation, dass es Probleme mit den Terminen gibt.
Die einfachste Möglichkeit, die Situation aufzulösen, wäre es die Sprint nicht mehr parallel zu halten.
Was aber macht man, wenn dies nicht möglich ist? Würdet ihr dann mit jeweils einem Team, aller Termine an einem Tag machen oder würdet ihr die Tage nach Events aufteilen und dann entsprechend mit den Teams terminieren. Bsp. Retrospektive findet Dienstag statt, Planning am Mittwoch.

Answer 1

Wenn es nicht möglich ist, finde ich es am angenehmsten, wenn man den Sprintwechsel auf zwei Tage aufteilen kann. Wie du schon sagtest z.B. Dienstags die Retrospektiven und dann am Mittwoch das Planning. Das hat auch den Vorteil, dass alle mit frischem Kopf an das Planning gehen können. Auch wird so der Sprintwechsel an sich deutlicher und greifbarer. Alternativ, könnte man auch Vormittags den Sprint Wechsel von Team A und Nachmittags den Sprintwechsel von Team B machen. Dass sind dann für den Scrum Master allerdings sehr anstrengende und lange Tage. Auch ist das mit drei Teams schon nicht mehr zu schaffen.

Sollten beide Teams am gleichen Produkt arbeiten, dann kann man auch überlegen, ob man die Review und das Planning I nicht ohnehin lieber zusammen machen möchte.

Eine weitere Alternative, welche ich sehr charmant finde, wäre die Events parallel in allen Teams zu machen. D.h. ich als Scrum Master wechsle von Sprint zu Sprint, bei welchem Team ich die Events aktiv begleite/moderiere und das andere Team macht die Termine eigenständig. Denkbar wäre hier eine Rollierende Moderation der Events im Team. Dies erfordert allerdings schon einen gewissen Reifegrad der Teams. Auch bei längeren Sprintzyklen würde ich eher davon abraten.

Answer 2

Ich glaube die ultimative Antwort darauf gibt es leider nicht. Beide Varianten haben ihre Vor- und Nachteile. So ist es schon richtig, dass bei einer Aufsplittung nach Events alle wieder am nächsten Tag frisch ins Planning gehen können, weil der Kopf dann frei ist und nicht mehr in Gedanken so sehr in der Retrospektive verankert, aber genau das kann auch nachteilig sein, wenn in der Retrospektive Erkenntnisse gewonnen werden oder Thematiken angesprochen werden, die für das Planning wichtig und miteinzubeziehen sind. Diese können bis zum nächsten Tag womöglich in den Hintergrund rutschen. Der Vorteil nach Teams aufzuteilen ist also, dass es unwahrscheinlicher ist, dass etwas in den beiden Tagen verloren geht. Ich würde diese Entscheidung stark von meiner Teamkonstellation und deren Stärken und Schwächen abhängig machen sowie natürlich davon, dass es vom organisatorischen Ablauf auch sinnvoll für alle in der Umsetzung ist.

Answer 3

Erstmal finde ich es gut, dass eine Organisation die mehrere Teams hat die Sprints alle Synchron durchführt. Damit ist gegenseitige Unterstützung und Kommunikation wirklich möglich. Wenn die Iterationen an unterschiedlichen Tagen starten und enden dann ist Mobilität von Aufgaben oder Mitarbeiter schwierig => nicht agil.

Natürlich ist es für den Scrum Master schwieriger wenn alle Events an einem Tag konzentriert sind. Ich würde es, solange es machbar ist, versuchen trotzdem die Termine alle an einem Tag zu machen. Wenn man morgens ein gemeinsames Review macht der 2 Stunden dauert und direkt danach eine gemeinsame Retrospektive (ggf. in kleinen Gruppen/Teams aufteilen und dann wieder zusammenkommen) stattfindet, dann hat man noch den Nachmittag. Die Zeit wäre dann für Plannings blockiert. Alle Teams könnten zusammenkommen zu ein gemeinsames Planning (welches Team macht was?) machen, dann trennen sich wieder die Teams mit dem Ziel, dass alle bis vor Feierabend wissen was sie in den nächsten Wochen machen werden und wie sie den Erfolg messen werden. Das funktioniert. Es ist sehr anstrengend (also nicht komfortabel) aber sehr effektiv.