Auteur : Sandrine Mathon, WEMBLA Conseil

Lego4Scrum est un jeu Agile utilisé pour simuler la construction d'une ville en mode SCRUM. Cf. www.lego4scrum.com.

Depuis 2 ans, j'anime ce jeu sur une après-midi entière à l'Université de Montpellier pour mes étudiants de Master 1.

Comme il s'agit de la conclusion d'un cours qui porte à la fois sur l'Agile et sur la gestion des exigences, j'ai apporté quelques variantes.

1- Chaque équipe s'occupe de sa ville

Oui, je sais, normalement, les équipes travaillent sur la même ville, ce qui les oblige à collaborer. Mais avec 70 étudiants, je préfère qu'ils se consacrent à la collaboration au sein de leur équipe de 5 ou 6, et qu'ils cherchent à améliorer leur organisation. Au final, ils sont obligés de collaborer, car ils se retrouvent en rupture de stock de certains matériaux.

Le cahier des charges est le même pour tous... mais ils peuvent rajouter des éléments s'ils le souhaitent. Rajouter, pas remplacer!

2- Chaque équipe est vraiment autonome en termes de projet et d'organisation

Le PO de chaque équipe est un des étudiants, c'est vraiment lui ou elle qui rêve sa ville.

Moi, je joue le rôle de la Direction de l'Aménagement du Territoire, qui vient imposer de temps en temps des nouvelles règles d'urbanisme.

J'insiste pour que chaque équipe travaille sur la compréhension globale du projet, la Vision. 

Le Scrum Master est aussi dans l'équipe. Ils peuvent le choisir tournant.

Chaque équipe s'organise à sa façon, pour estimer ou pour assurer le suivi du projet. En général, ça commence dans un b... absolu, mais l'amélioration est exponentielle. J'exige simplement de pouvoir voir l'avancée du projet d'un seul coup d'oeil (management visuel).

3- J'utilise aussi des Kapla

Bon, c'est surtout parce que je n'ai pas assez de Lego, alors que mes enfants étaient fans de Kapla. L'esthétique est assez spéciale, plus "Grande-Motte" que New-York, mais ça marche aussi.

Et comme ils ont le droit d'utiliser d'autres matériaux de leur environnement, le résultat est souvent très créatif.

Utiliser des Kapla rajoute également une contrainte technique : comment transporter les bâtiments? Du coup, le premier sprint se termine quasiment toujours par une absence de livraison.

4- J'ai rajouté des sprints de validation à la fin

C'est surtout pour qu'ils se mettent dans la peau d'un usager de leur ville. Et qu'ils expriment vraiment cet usage du point de vue de l'usager.

C'est comme ça qu'on se retrouve avec des tests du style : "mes enfants peuvent rentrer de l'école à pied sans risquer d'être renversés par une voiture".

Oups! Et si on avait commencé par exprimer le backlog comme ça, au lieu de se retrouver avec des "modules"  comme "un immeuble à 2 étages" ou "une épicerie bio"!?

Eh oui, on peut aussi faire des User Stories en Lego4Scrum!

5- Il m'arrive de couper le jeu après un sprint

Je pars de 6 sprints planifiés. Mais j'arrête (ou je menace d'arrêter) à la fin du 4ème sprint. Ceux qui ont mal compris la notion de priorisation, et ont commencé par développer le cinéma et la piscine avant les habitations et l'école s'en mordent les doigts.

J'ai même eu le cas d'une équipe qui avait passé 2 sprints à développer un parc d'attraction... et la station d'épuration.

Nouvel essai demain. Hum! Je crois que je vais demander une ville autonome en énergie et qui recycle ses déchets...

Mise à jour du 15/04/2016 : hier, j'ai essayé de faire bâtir 2 villes seulement, avec 2 équipes chacune. Je ne vois décidément pas l'intérêt de l'approche multi-équipe dans le cadre de ma formation agile, sauf si l'animateur joue le rôle du PO. Auquel cas, en effet, ce n'est pas gérable avec 4 villes différentes. Cette approche nécessite également moins de matériel.

Hier, mes PO étaient au top : interférences, changements d'avis en cours de sprint, besoin flou énoncé de manière péremptoire, ils ont joué le jeu de manière magistrale. Je n'aurais pas fait mieux.