Gruppenkonformität und Schnelligkeit in Scrum

Ein Team, das ich gecoacht habe, hat sich freiwillig zu einem Sprint-Backlog verpflichtet, das nicht realistisch war. Schlimmer noch, es war nicht nur im Nachhinein klar, dass es unrealistisch war, sondern sie wussten es schon zu Beginn des Sprints. Wie kommt es, dass sie sich zu einem Sprint-Backlog verpflichtet haben, obwohl sie bereits wussten, dass es unrealistisch war?

Dieses Team begann seinen ersten Sprint, während die Arbeit am Product Backlog noch in vollem Gange war. Sie nahmen ein paar User Stories auf, die bereits fertig waren. Wenn nur wenige User Stories im Product Backlog fertig sind, macht die Schätzung von Story Points nicht viel Sinn. Da es sich um ein relatives Maß handelt, braucht man mehr als nur ein paar User Stories, um mit der Schätzung von Story Points zu beginnen. In 1 oder 2 Sprints werden wir genug User Stories haben, um Story Points zu schätzen und die Geschwindigkeit zu messen.Man könnte sich dafür entscheiden, nicht mit Scrum zu beginnen, wenn nicht genügend Stories im Product Backlog stehen. In diesem Fall gab es in der Organisation und im Team den Impuls, mit Scrum zu beginnen, und wir haben uns entschieden, den Start nicht zu verschieben, sondern zu beginnen. Im zweiten Sprint verpflichtete sich das Team zu einem Sprint Backlog, obwohl es sich im Geiste nicht festlegen wollte. Natürlich war es nicht hilfreich, dass es keine Velocity gab. Alles auf das Fehlen einer Geschwindigkeitsmessung zu schieben, ist zu einfach. Es gibt noch mehr.

Geschwindigkeit

Velocity ist definiert als die Gesamtmenge an Arbeit, gemessen in Story Points, die das Team im letzten Sprint geleistet hat. Es gibt einige Feinheiten, z.B. wenn das Team unfertige User Stories hat. Die Hauptverwendung[ScrumGuide] ist zweifach. Erstens verwendet das Team die zuletzt erreichte Velocity als Maßstab für den Umfang der Arbeit, die es im nächsten Sprint in Angriff nehmen wird. Zweitens dient sie dem Product Owner als Anhaltspunkt für die Prognose, welche Funktionen zu einem bestimmten Zeitpunkt fertiggestellt sein werden. Dies hilft dem Product Owner bei der Priorisierung des Backlogs. Hinweis: Im Scrum-Leitfaden wird die Geschwindigkeit nicht ausdrücklich erwähnt. Vielmehr ist von der "bisherigen Leistung des Teams" die Rede und davon, dass der Product Owner "den Fortschritt in Richtung eines Ziels bewertet". In der Praxis verwenden viele Teams dafür den Begriff 'Velocity'.

Planungstreffen

In einem Scrum-Planungstreffen wird das Sprint Backlog erstellt. Ich helfe den Teams beim Aufbau des Sprint Backlogs, indem ich mit der wichtigsten User Story beginne und den Product Owner die Story erläutern lasse. Das Team kann Fragen stellen, um die Story zu klären. Schließlich frage ich das Team, ob es sich verpflichten kann, diese User Story in diesem Sprint fertigzustellen. Wenn 'Ja!', wird dieses Verfahren für die nächsten User Stories wiederholt, bis das Team sich nicht mehr festlegen will. Das Limit für diesen Sprint ist erreicht. Die Velocity dient zur Überprüfung, ob das aktuelle Sprint Backlog realistisch ist. Sie basiert auf den Ergebnissen des Teams in der Vergangenheit.

Gruppe Konformität

Es gibt noch einen weiteren wichtigen Nutzen für die Velocity des Teams. Sie hilft dem Team nicht nur dabei, zu bestimmen, wie viel Arbeit es im nächsten Sprint fertigstellen kann, sondern verhindert auch, dass sich die Gruppe auf einen Sprint-Backlog festlegt, obwohl einige oder alle Teammitglieder "Nein!" denken. Dieses Phänomen ist als "Gruppenkonformität" bekannt und wurde in den 50er Jahren in einer Reihe von Experimenten nachgewiesen, die als "Asch-Experimente"[BlogChe] bekannt sind. Diese Experimente zeigten, dass die Mitglieder einer Gruppe dazu neigen, sich der Meinung/dem Glauben der Gruppe anzuschließen, auch wenn sie selbst anders denken. Anstatt sich gegen die Gruppe zu stellen, halten sich die Mitglieder an die Antwort der Gruppe. Zum Beispiel, um nicht lächerlich gemacht zu werden.

Planungstreffen...wieder

Zurück zum Team. Was geschah in der Planungsbesprechung? Bei der Planung stelle ich als Coach die Commitment-Frage nach dem Hinzufügen jeder User Story. Die Fragen werden dem Team von einem Teammitglied nach dem anderen gestellt. Die ersten sagen 'Ja!'. Schließlich sagten alle Teammitglieder 'Ja!'. Aber haben sie auch 'Ja!' gedacht? Wahrscheinlich nicht. Was könnte der Grund dafür sein, dass sie 'Nein!' denken und 'Ja!' sagen? Inspiriert von einem Kollegen[Gro13] fällt mir da etwas ein:

• nachdem Sie 10 Minuten lang mit dem Product Owner über die User Story diskutiert haben, kann es schwierig sein, "Nein!" zu sagen, denn das bedeutet, dass nur 10 Minuten Gruppenzeit verschwendet wurden; es ist einfacher, sich der Gruppe anzupassen und "Ja!
• nachdem einige wenige 'Ja!' gesagt haben, wird es immer weniger einfach, 'Ja!' zu sagen, und es fällt wieder leichter, sich der Gruppe anzupassen,
• für die letzten Mitglieder, die gefragt werden, klingt ein 'Nein!' wie ein 'Veto', was sich nicht gut anfühlt und (wieder) ist es einfacher, sich der Gruppe anzupassen.

Die Verwendung der Velocity als Werkzeug, um zu entscheiden, dass das Sprint Backlog voll ist und keine weiteren User Stories mehr aufgenommen werden sollten, verhindert die oben dargestellte Denkweise. Die Teammitglieder müssen nicht 'Nein!' sagen, sondern ihre bewährte Leistung in der Vergangenheit tut es.

Die Rolle des Scrum Masters

Wie können Sie als Scrum Master helfen? Halten Sie sich an den Prozess und verwenden Sie die Velocity, um sich vor gruppenkonformen Effekten zu schützen. Die Velocity teilt der Gruppe mit, dass die Grenze dessen, was im nächsten Sprint realistisch ist, erreicht ist, und verhindert so, dass das Team "Nein!" denkt, aber "Ja! Dies wird dem Team nur kurzfristig helfen.

Die Rolle des Coaches

Was ist die Rolle des Coaches? Der Team-Coach sollte den Austausch von Ideen und vor allem die Meinungsverschiedenheiten zwischen den Teammitgliedern anregen. Dies wird den Teammitgliedern helfen, sich nicht an die Gruppe anzupassen. Die Anpassung an die Gruppe ist vor allem bei Gruppen zu beobachten, die sich gerade erst gebildet haben. Hier sind die Mitglieder der Gruppe zurückhaltend, wenn es darum geht, Ideen und Meinungen zu äußern, die sich vom Rest der Gruppe unterscheiden. Die Rolle des Teamcoaches wäre es, dem Team in dieser Phase der Gruppenentwicklung zu helfen. Dieser Ansatz wird dem Team langfristig helfen.

Fazit

Der Einsatz von Velocity hilft dem Team nicht nur, den Umfang des Sprint Backlogs zu bestimmen und dem Product Owner bei der Priorisierung zu helfen, sondern auch zu verhindern, dass das Team sich auf ein Sprint Backlog festlegt, obwohl es das eigentlich gar nicht will.

Referenzen