Dernièrement j’ai eu l’occasion de faire jouer le jeu de Clodio sur l’agilité à grande échelle (dont il a fait une formation) à une équipe que j’accompagne depuis 15 mois maintenant.
A l’origine, la demande du manager était de faire réfléchir les équipes sur la notion d’appartenance à un programme commun et le fait que chacune d’entre elle devait contribuer au succès de l’unité.
Je me suis dit que ce jeu, que Claude va présenter au prochain ScrumDay, serait un bon support à la discussion et à l’échange.
J’avais prévu 3h pour cet atelier et finalement nous sommes restés un peu plus de 3h30 pour dérouler l’atelier et débriefer sur les apprentissages (environ 2 h de jeu … nous avons pris notre temps … et 1h30 de débriefing)
Bien entendu j’avais contacté Clodio qui m’avait donné quelques explications supplémentaires sur le jeu, en particulier les ajustements qui étaient nécessaires suite à son test grandeur nature lors du dernier Agile Games France.
Comme j’avais 9 joueurs, j’ai décidé de faire 2 équipes de 4 personnes avec un PO unique. En tant que client final, j’avais indiqué les valeurs des features (Astérix 100 points, Obélix 80 points, Cascade 15 points, Lapin 10 points …) et il y en avait une bonne vingtaine. Puis j’ai dessiné sur le tableau les colonnes représentant les bacs (Bac à Sable, Bac d’affinage, Bac Prêt, Bac En cours, Bac Fini) et j’ai lancé l’itération 0.
Le Product Owner a parfaitement joué son rôle, et les équipiers ont eu du mal à se mettre d’accord pour préparer un Backlog dans le timing prévu initialement. En l’absence de Backlog exploitable à la fin du temps prévu, j’ai proposé de refaire une nouvelle itération 0 (nouveau timebox), ce qui est pour moi la seule raison valable de ne pas démarre le 1er sprint.
Les 2 premières itération se sont déroulés normalement avec peu de valeur produite du fait de la difficulté d’atteindre le Terminé que les équipes avaient défini conjointement avec le PO. Deux story technique avaient été rajoutés lors de l’itération 1 pour faire le tri des pièces à chaque table. Il y a eu également 3 autres story technique d’ajoutées lors de l’itération 2 … et qui sont par la suite toujours restées au fond du backlog (nous en avons discuté ensuite).
Les affinages Backlog des 2 premières itérations n’ont pas été très efficaces et cela à conduit les équipes à changer le backlog dans l’urgence lors des sprint planning meeting … une très mauvaise idée 🙁
Lors de la 3ème itération, qui a finalement produit de la valeur, il est apparu que certains équipiers faisaient un travail qui ne provenait pas du backlog car ils estimaient que c’était nécessaire. Cela a créé de la confusion et la notion d’équipe a été impacté une première fois.
Lors de la 4ème itération, les 2 équipes ont volé en éclat car les participants ont décidé de faire 4 binômes pour s’occuper de terminer 4 features. Lorsque j’ai demandé qui étaient les Scrum Master, il m’a été répondu : « Il n’y en a plus, ce n’est pas nécessaire avec des binômes ». Le fonctionnement de cette itération a été particulièrement chaotique. Tout le monde était agglutiné sur une table, certains équipiers n’avaient plus rien à faire, ou sentant qu’ils n’apportaient pas de valeur, se sont reculé et n’ont plus participé à la fin du sprint. Est-il nécessaire de rappeler l’importance du Scrum Master …
Pour ne pas rester sur une frustration, peu de valeur produite et seulement quelques pièces manquantes sur les personnages, j’ai décidé de faire un 5ème sprint qui a permis de réellement terminer les features commencées.
Le débriefing a été très riche, je ne le détaillerais pas ici car il appartient à l’équipe, et j’espère qu’il a aidé à certaines prises de conscience (je vous rappelle que le jeu n’est qu’un support au débriefing, pas une fin en soi)
Un grand merci à Clodio pour avoir apporté ce jeu à la communauté 🙂