Nach den teilweise kritischen Kommentaren meines Teams (in der vorletzten Retro) und den inspirierenden Kommentaren zu meinem Artikel „Velocity einzelner Team-Mitarbeiter visualisieren“, haben wir im letzten Sprint eine verbesserte Version der Visualisierung gewählt.
Diese stellt nicht zwingend den schnellsten Entwickler über die anderen Teammitglieder, sondern bevorzugt ein gemeinsames Abarbeiten von Stories im Team.
Wir nennen es:
Storypointopoly
Die Regeln dieses Spiels sind wie folgt:
Gespielt wird auf einem magnetisierten Spielbrett von Monopoly.
Jedes Teammitglied hat eine Figur (wir verwenden hierfür Magnete) und Punkte (ähnlich der Häuser bei Monopoly) in der jeweiligen Farbe des Spielers.
Sinn des Spiels ist, möglichst viele Punkte auf leere Grundstücke zu platzieren.
Häuser/Punkte bekommt jeder Spieler dann, wenn er als Erster auf ein freies Feld fährt; Sonstige Felder (Einkommenssteuer, Ziehe eine Karte,…) können nicht „gekauft“ werden und bringen damit auch keine Punkte.
Ziehen darf man mit seiner Figur allerdings nur, wenn eine Story des Sprints abgeschlossen ist.
Wenn Entwickler an einer Story gemeinsam gearbeitet haben, werden die geschätzten Storypoints durch die Anzahl der Devs geteilt, wodurch öfter kleinere Schrittweiten ermöglicht werden.
Ihr erkennt, daß es zwar einen strategischen Vorteil bringt viele Storypoints abzuarbeiten, aber dass es in vielen Fällen dem besseren „Vorankommen“ dient, gemeinsam (zB im Pairprogramming) Stories zu lösen, um so öfter auf mehr Felder zu gelangen.
Gewonnen hat am Ende des Sprints der Entwickler, der die meisten Punkte setzen konnte.
Ich habe versucht Felix‘ und Konstantins Bedenken bezüglich der Anonymisierung nach außen in das Spiel einfließen lassen. Nur das Scrum-Team kennt die Farben der Spieler, wodurch außenstehenden Personen keine Rückschlüsse über die Leistung des Einzelnen ermöglicht werden.
Wie die Weiterentwicklung des Spiels voranschreitet werde ich nach der nächsten Retrospektive berichten.
Bis dahin freue ich mich über Eure Kommentare und Ideen für Storypointopoly.
Hi Markus,
Du schreibst:
„Diese stellt nicht zwingend den schnellsten Entwickler über die anderen Teammitglieder, sondern bevorzugt ein gemeinsames Abarbeiten von Stories im Team.“
Ich kann nicht erkennen, wie dieses Spiel das Team weiterbringen kann. Wenn es sogar einen von Dir beschriebenen strategischen Vorteil gibt, schnell viele Punkte zu machen, durch was genau wird das Team dann zu mehr gemeinsamer Verantwortung motiviert?
„Gewonnen hat am Ende des Sprints der Entwickler, der die meisten Punkte setzen konnte.“
Damit wird das Spiel zu einem reinen, persönlichen Contest – ein einzelner gewinnt und setzt sich dadurch vom Rest des Teams deutlich ab.
Ich bin gespannt, zu welchen Ergebnissen Ihr diesbezüglich in Eurer nächsten Retro kommt.
Gruß,
Marc
Hi Marc!
Danke für Deinen wohlüberlegten Kommentar.
Du hast natürlich Recht, dass meine (kurze) Beschreibung Deine Annahme stärkt, dass (starke) „Einzelgänger“ bevorteilt werden.
Lass mich deshalb mit einem kleinen Beispiel veranschaulichen, warum ich denke, dass das Spiel eher die Teamarbeit stärkt:
Gehen wir davon aus, dass der „Einzelgänger“ im Team alleine eine 13Punkte Story löst, und die drei anderen Teammitglieder gemeinsam in der gleichen Zeit eine 8Punkte Story und zwei 5Punkte Stories lösen.
In diesem Gedankenexperiment hätten sich die Teamworker die 3 Stories nach Punkten „geteilt“, wodurch sie zB für die erste Story 4+3+1 Felder fahren können, für die Zweite möglicherweise 2+2+1 Züge bekommen und für die Dritte z.B. 3+1+1 Felder weit ziehen dürfen (die Einigung, wer jeweils einen Zug weniger weit fahren darf obliegt den Spielern).
Das Ergebnis dieser einen „Runde“ wäre: Der „Einzelgänger“ hätte einen Punkt setzen können, die Teamworker hingegen jeweils mindestens einen Punkt. Obwohl sie am Spielbrett den „Einzelgänger“ nicht überholt haben, sind sie von Punkten nicht in einen Rückstand geraten, sondern haben (je nach Weite der einzelnen Züge) 3, 4 oder 5Punkte erhalten.
Aber Du hast natürlich recht, wenn Du Verbesserungspotential siehst. Deswegen haben wir ja in erster Linie das Task-Killer-Board gegen Storypointopoly ersetzt und werden auch in den nächsten Sprints dazulernen – gelebtes „Inspect and Adapt“
Möglichkeiten der Verbesserung wären:
Falls Du weitere Vorschläge hast, freue ich mich über wertvolle Inputs :-)
Hallo Markus,
ich denke das hierbei sehr schnell der Eindruck entstehen kann, dass nur die Entwickler zügig vorankommen die bei dem Spiel viele (kleine) Tasks abgearbeitet haben.
Und welche Erkenntnisse können daraus gezogen werden? Das ist mir noch nicht ganz schlüssig.
Ich bin auch auf das Ergebnis gespannt.
Gruß
Kaschef