Lego4Scrum Adapté

Ce matin, j’ai fait jouer une version adaptée du célèbre Lego4Scrum, le résultat est plutôt sympa (la ville idéale est vraiment chouette) vous trouverez ci-dessous les 4 variantes que j’y ai apporté.

Variante 1

Mon objectif pour cette variante était de donner des raisons d’utiliser une méthode agile sur un projet car la plupart des joueurs ne connaissaient que les méthodes traditionnelles.

J’avais préparé un Cahier des Charges de ma Ville Idéale qui tenait sur 1 page et qui décrivait mes attentes en termes de  maison, d’immeuble, de bâtiments divers, de routes …

Nous avons lu ensemble ce document puis je leur ai demandé s’ils se sentaient capable de réaliser cette ville idéale en 35 minutes avec le matériel dont ils disposaient ?

J’ai plutôt eu des questions que des réponses, et certaines questions concernaient le niveau de détail du CdC qui leur semblait insuffisant. J’ai alors ajouté que je n’étais pas vraiment certain de tout ce que voulait et qu’il me serait difficile de détailler le CdC. Par contre, j’avais les idées claires sur quelques éléments qui me paraissaient importants et que je leur proposait d’utiliser une méthode agile pour réaliser le projet … et c’était parti !!

Variante 2

Mon objectif pour cette variante était de montrer l’utilité d’avoir un Product Owner un un Scrum Master proche de l’équipe.

J’avais donc fabriqué des Badges spécifiques que chaque joueur devait porter pour identifier son rôle.

En tant que Sponsor de la ville idéale, j’ai commencé à m’adresser uniquement aux Product Owner, et au fil du temps et des rétrospectives,  les équipiers se sont directement adressés à moi, tout d’abord lors des démo, puis pour valider les livraisons au fur et à mesure.

En tant que Sponsor j’ai également apporté directement des exigences aux équipiers … et j’avoue que les Scrum Master n’ont pas été suffisamment vigilants pour gérer cela correctement.

Variante 3

Mon objectif pour cette variante était de montrer que les développeurs et les opérations peuvent travailler ensemble.

J’avais donc identifié des « Equipiers 1 » qui pouvaient manipuler les lego sans accéder au plateau de la ville idéale (la prod) et des « Equipiers 2 » qui pouvaient accéder au plateau et reprendre des réalisations existantes (suite à des remarques du sponsor en cours de sprint sur les éléments du plateau) mais ne pouvaient pas créer un nouveau bâtiment à partir d’une exigence.

Au delà de la frustration des Equipiers 2 lors de la première itération, car ils n’avaient pas grand chose à faire, l’exercice à bien montré qu’il est indispensable de travailler ensemble (Dev & Ops).

Variante 4

Mon objectif pour cette variante était d’obliger les équipes à collaborer compte tenu de leurs spécialités, et au delà du fait qu’elles travaillent toutes sur la même ville idéale.

Il y avait dans chaque boîte de lego certains éléments que les autres équipes n’avaient pas à leur disposition. Certaines exigences n’étaient réalisables qu’avec ces éléments spécifiques et bien entendu ce sont ces exigences spécifiques que j’ai (en tant que sponsor) communiqué directement aux équipes qui n’étaient pas en mesure de les réaliser 🙂

Conclusion

Le débriefing a été très riche d’enseignements pour les participants et il m’a permis de souligner l’efficacité de certaines pratiques des méthodes agiles et des concepts qui vont avec.

Voilà pour aujourd’hui, si vous utilisez une de ces variantes, dites moi ce que vous en pensez ?