LEGO for extended SCRUM simulation-FR

www.scrumguides.com
LEGO pour une simulation Scrum
Alexey Krivitsky, Février 2009
[email protected]
Traduit par Fabrice AIMETTI le 4 juillet 2011
1/9
Simuler Scrum : la recherche de meilleurs jeux
Au cours des deux dernières années, j'ai participé et facilité plusieurs formations CSM
animés par différents formateurs. Toutes ces formations disposaient de différents ateliers
de simulation mais j'ai toujours eu le sentiment que l’on pouvait en trouver de meilleurs.
Les problèmes que j’ai pu constatés avec certains des jeux bien connus sont :
1. Backlogs préparés à l’avance ?
Selon moi, le backlog est un excellent outil de collecte et de discussion des idées
qui favorisent la créativité. Les backlogs sont habituellement préparés par le
formateur, imprimés et remis aux équipes. Où est la créativité dans tout ça ? Faites
ceci, puis cela. C'est comme un commandant. Un message qui semble bien
contradictoire pour les néophytes Scrum qui viennent (peut-être) de commencer à
comprendre pourquoi le mode commande & contrôle n’est pas toujours bon ?
2. Qu'est-ce qu'on essaie de construire ?
Dans le backlog, je vois quelquefois des tâches à accomplir, et non pas les parties
qui composent un produit. A quoi aboutiront ces tâches (quand elles seront
terminées) ? Habituellement, une grande pagaille dans la salle de formation
(sourire). Un message contradictoire pour l'équipe de développement d’un
produit ?
3. La concurrence des équipes ?
Habituellement, il y a une vingtaine de personnes dans la classe. Donc nous
division cette foule en petites équipes afin qu’elles tirent plus de plaisir à jouer le
jeu. Et bien sûr, chaque équipe est finalement en compétition pour obtenir un
meilleur score que les autres. Mais ne parlons-nous pas surtout de construire un
environnement coopératif. Un message contradictoire?
4. Les métriques ?
Au cours des cycles de planification du jeu, les équipes sont invitées à estimer les
items du backlog. Alors elles le font. Nous leur demandons de garder une trace de
leur vélocité prévisionnelle et constatée. Alors elles le font. Mais il
me semble que la seule chose dont elles se soucient soit le score. Elles n’utilisent
apparemment pas la vélocité pour planifier les releases, ni pour vérifier la
planification de leur sprint. En fait, elles le font simplement parce que nous
leur demandons de tracer la vélocité. Et non parce qu'elles en ressentent le besoin.
Cela ressemble plutôt à du reporting inutile vers le management (le formateur
dans ce cas). Un message contradictoire ?
On peut sûrement relever plus de choses. Et bien sûr, ces jeux apportent beaucoup ! Je
pense juste qu'il devrait y avoir d'autres jeux qui illustrent mieux les choses que nous
Traduit par Fabrice AIMETTI le 4 juillet 2011
2/9
essayons d'enseigner. J'ai donc commencé à réfléchir à de meilleures simulations et j’ai
alors eu l'idée d'utiliser des briques de LEGO (merci à William Wake, Jurgen De Smet, Yves
Hanoulle, Mykola Gourov et encore d'autres personnes de m’avoir ouvert les yeux !).
Simulation Scrum LEGO
Après avoir essayé à plusieurs reprises la simulation Scrum LEGO avec des personnes et
des cultures différentes, je peux dire que cela me semble être plus cohérent avec ce que
j'ai effectivement envie d'enseigner. S’interroger et faire le bilan ensemble (vous jouez à
des jeux pour vous interrogez, non ?) ouvre un énorme (je veux dire vraiment énorme)
champ de bonnes discussions et apporte d’incroyables perspectives de progression aux
personnes.
Comment jouer
Le Backlog
J'ai essayé avec le backlog suivant et il a bien fonctionné, même s’il dépend de vos
thèmes LEGO et de votre imagination. Donnez tous les détails de vos items uniquement si
on vous le demande, sinon n’acceptez pas l’item tant qu’il n’a pas été correctement (re-)
fait.
Un bâtiment à un étage
Vous pouvez en avoir autant que
vous voulez dans le backlog.
Un bâtiment à deux étages
Une église
Un bâtiment en briques d’une
seule couleur qui est un peu plus
élevé qu'un bâtiment d'un étage
et avec une croix blanche sur le
dessus.
Un kiosque
Un petit bâtiment avec un petit
magasin à l'intérieur où vous
pouvez acheter des petits trucs,
comme du chewing gum.
Une maternelle
Un bâtiment avec une barrière
pour que les enfants ne sortent
pas.
Un camion
Vous trouverez des instructions
sur la façon de le construire, ainsi
que d'autres machines, dans vos
manuels LEGO.
Un camion poids-lourd
Traduit par Fabrice AIMETTI le 4 juillet 2011
3/9
Une grue
Un tracteur
Un garage à camion
Un garage simple, où un camion peut rentrer (critère d'acceptation). J'ai
l'habitude de prioriser les garages par rapport aux machines qui doivent y être
abritées et j’ai l’habitude d’amener progressivement les personnes à convaincre
leur PO que, pour faire la démonstration de cet item, ils ont d’abord besoin de
construire une machine, donc finalement qu’ils peuvent aider leur PO à ajuster les
priorités pour obtenir un meilleur produit.
Un garage à tracteur
Un simple garage où un tracteur peut rentrer (critère d’acceptation).
Un arrêt de bus
« En tant que passager du bus, Je peux attendre mon bus pendant une assez
longue durée et par mauvais temps ». Ce qui implique de disposer d’un un banc et
d’un toit.
On peut trouver certains des items détaillés dans les guides LEGO, et certains non. Je
pense que c’est tout à fait normal. Pour certaines features, on peut vous fournir des
exigences détaillées, et pour certaines autres on ne vous donne rien. Les personnes ont
donc juste à poser des questions au PO (n'est-ce pas ce que nous voulons leur apprendre
finalement ?). S'ils ne posent pas de questions, ils ne seront jamais capable de se faire
valider qu’un simple arrêt d'autobus est fini.
Le jeu est structuré, à l’image d’un projet Scrum normal, selon le cycle suivant :
1. discuter sur la vision du projet et sur le contenu initial du backlog
2. estimer le backlog
3. (re-)Prioriser le backlog
4. Planifier la release
5. Planifier le sprint
6. Exécuter le sprint (en fait, 3 sprints à chaque fois que nous jouons)
7. Faire la démo
8. Faire la rétrospective
9. (le cycle se répète jusqu'à ce que vous manquiez de briques, de temps ou que le
backlog soit vide)
Vision
Pendant cette discussion, j’apporte (en tant que PO) du contexte : les membres de
l’équipe travaillent tous pour une grande entreprise avec plusieurs équipes impliquées et
ils doivent construire une ville (un seul produit !). C'est à eux de décider comment se
répartir en équipes.
Traduit par Fabrice AIMETTI le 4 juillet 2011
4/9
Estimations
Ils agissent tous comme une seule équipe (20 personnes réussissent à le faire) et ils
doivent évaluer le backlog. Ils ont leurs paquets de cartes de planning poker et ils ont déjà
pratiqué l'estimation de stories auparavant.
Ce que nous voulons leur faire faire c’est d'estimer
aussi vite qu'ils le peuvent, mais tous les éléments
du backlog doivent être estimés dans la même
unité de sorte que nous obtenions un planning de
release intégré.
Après quelques discussions, ils choisissent une
unité (un bâtiment de 1 étage semble être une
bonne unité, disons 2 points) et commencent par
estimer les 3 à 5 premiers items ensemble. Après
qu’ils aient tous développé ensemble une bonne
idée de l’estimation de la taille d’un item
(également pour des besoins de triangulation à
venir), nous leur demandons de se scinder en plus
petites équipes et d’estimer le reste en parallèle.
Une fois qu'une équipe a estimé un nouvel item, elle le colle au mur dans la colonne
correspondante (une colonne par points) de sorte que les autres équipes disposent de
plus de données pour trianguler les estimations. Jusqu'à présent cela a toujours très bien
fonctionné.
Les membres de l’équipe peuvent également prototyper autant qu'ils veulent (dans le
respect des délais), mais tous les prototypes doivent être démontés avant que le sprint
commence (nous discutons donc ici de la valeur des prototypes jetables).
(re-)Priorisation
Après que les estimations aient été réalisées, en tant que PO, j'ai l'habitude de faire de
petits changements dans les priorités (les estimations peuvent impacter les décisions
métier, sinon pourquoi estimer ?).
Planification de la release
Le but est d'obtenir un burndown de la release bien visible de sorte que toutes les
personnes comprennent où ils se situent dans la release et quel est leur état
d’avancement global. Après la séance d'estimation, nous traçons un premier point sur le
graphique et nous lançons une réunion de planification de sprint.
Traduit par Fabrice AIMETTI le 4 juillet 2011
5/9
Planification du sprint
Nous souhaitons coacher des personnes –
qui travaillent dans des environnements
multi-équipes – sur la façon de planifier les
sprints. Nous plaçons donc un unique
backlog produit sur le mur (un post-it par
item) et des feuilles de paperboard pour
les backlogs de sprint (un par sous-équipe).
Un chronomètre démarre (configuré sur 5
minutes), les sous-équipes parcourent le
backlog produit et déplacent les items sur
leur backlog de sprint respectif… jusqu’à
ce que les équipes ne puissent plus
s'engager sur des items supplémentaires
(ici nous apprenons la planification basée
sur l'engagement).
Une astuce à mentionner ici est que nous avons deux jeux de LEGO et que chacun permet
de fabriquer des machines différentes (camions, tracteurs, grues, etc.). Ce qui signifie
simplement qu’aucune équipe ne peut tout construire. Cela affecte fondamentalement la
planification de leur sprint : disons qu’un camion est affiché sur le backlog de sprint d'une
équipe et qu’un tracteur est affiché sur celui de l'autre équipe, leurs membres ne sont
pas autorisés à s’échanger des briques de LEGO pendant le jeu, ils ont donc besoin
d’identifier ces contraintes et ces dépendances dès la planification (ce qui je crois est une
compétence intéressante à apprendre).
La réunion de planification d’un sprint est le bon moment pour discuter des critères
d'acceptation. Donc lorsque les membres de l’équipe choisissent de construire un garage,
nous leur demandons comment ils comptent en faire la démonstration. Ils vont
probablement devoir d’abord construire une machine (ceci pourrait entraîner le PO à
remonter la priorité de la machine dans le backlog).
Lors du premier sprint, les membres de l’équipe ne discuteront probablement pas des
critères d’acceptation de l'incrément produit entier (qui devrait en fait ressembler à une
ville avec des rues et contenir les items construits par toute l'équipe !). Nous les laissons
tomber dans le piège en n'acceptant pas les éléments construits (je crois qu’échouer et
apprendre à résoudre le problème est un exercice extrêmement intéressant).
Traduit par Fabrice AIMETTI le 4 juillet 2011
6/9
Les livrables de la réunion de planification du
sprint sont les suivants :
1. la vélocité prévue (nous l’inscrivons
sur un post-it que nous mettons sur le
backlog de sprint de chaque équipe)
2. l'engagement de l'équipe (je demande
aux équipes si elles peuvent s'engager
sur les stories sélectionnées, elles le
peuvent généralement parce que la
planification a été un effort d'équipe)
3. la décomposition en tâches (si les
équipes veulent le faire, en général
elles n'ont pas le temps pour ça).
Exécution du sprint
Les membres de l’équipe exécutent un sprint
sur 5 minutes (j'ai l'habitude de projeter une
application chronomètre sur le mur ou de la
lancer sur mon ordinateur portable).
Un peu de rock en musique de fond dans la
salle de formation peut ajouter à l’ambiance.
Démonstration & Rétrospective
Nous avons 5 minutes pour ces deux activités
si bien qu’elles se mélangent l’une à l’autre.
Lorsque le chronomètre du sprint s'arrête, je
demande avec vigueur : "Alors, où est ma
ville ?", et là ils commencent tous à intégrer
leurs résultats... il faut généralement du
temps (à discuter et résoudre lors des
prochaines versions).
Finalement, ils parviennent à faire la
démonstration de l'incrément de la ville, avec
bien sûr quelques bugs car ils s’engagent
généralement beaucoup trop sur le premier
sprint. Je joue habituellement le méchant ici
et je n'accepte pas beaucoup de features.
Les membres de l’équipe sont invités à calculer leur vélocité prévisionnelle. Et bien sûr, ils
vont essayer de me convaincre que quelque chose à moitié fait leur donne la moitié des
points pour la vélocité. Je n'accepte pas à moins que l'item présente une réelle valeur
même s’il lui manque certains détails sans importance (le camion a une remorque, des
Traduit par Fabrice AIMETTI le 4 juillet 2011
7/9
roues et une cabine, mais n'a pas de phares et autres petits détails). Cela ouvre des
discussions passionnantes sur le calcul de la vélocité réelle.
Une équipe essayait de me prouver que leur bâtiment à moitié construit était
presque prêt (2 points sur 3) et, au cours de la discussion, il s’est tout simplement
écroulé. Quelle belle illustration ! Durant le sprint suivant, l’équipe l’a reconstruit à
partir de zéro et a gagné ses 3 points (si j'avais accepté de leur donner 2 points sur 3,
ils n'auraient pas eu le temps de le reconstruire à partir de zéro et la qualité en aurait
souffert).
Les équipes inscrivent leur vélocité constatée sur les backlogs de sprints. Nous dessinons
également un histogramme de vélocité pour chaque équipe.
Les items qui non pas été finis repassent des backlogs de sprint vers le backlog produit,
nous calculons le nombre total de points restants dans le backlog et nous mettons à jour
notre burndown de release. Ici, je commence à prédire la bonne fin de la release (« Les
gars, il semble que vous pourrez livrer toute la ville en 3 sprints… nous en saurons plus
une fois que vous aurez fini votre prochain sprint »). Nous discutons de la valeur d’être
prédictif plutôt que d'essayer d'en faire trop.
Et le cycle des sprints continue ...
Autres discussions
Refactoring
Au cours d'un atelier LEGO, une équipe a construit des bâtiments très grands au cours du
premier sprint, si bien qu'ils ont commencé à se rendre compte qu'ils n'auraient pas assez
de briques pour terminer d'autres items. Ils ont dû refactorer (simplifier !) les bâtiments
construits jusque là pour être capable de construire plus de choses. Je n’ai pas accepté de
carte de refactoring dans le backlog produit, donc le refactoring a affecté leur vélocité. Si
j’avais accepté de mettre la carte de refactoring dans le backlog, il l’aurait estimé et leur
vélocité serait restée la même (!) alors même qu’ils construisaient moins de choses. Vous
construisez moins -> votre vélocité baisse. Ce fut une prise de conscience intéressante
pour tout le monde.
Dépendances inter-équipes
Durant un autre atelier, une équipe n’a pas pu réaliser la grue, car certaines de ses pièces
étaient sur la table de l'autre équipe (oh ! des dépendances techniques). L'autre équipe a
refusé de consacrer un peu de temps pour la grue, et l'équipe n'a pas pu la livrer dans le
sprint courant. Plus tard, nous avons détaillé ce point et il est apparu que l'autre équipe
avait refusé parce qu’elle ne voulait pas dégrader sa vélocité à cause de choses imprévues
provenant d'une autre équipe.
Mais alors, que serait-il arrivé si nous avions eu des vélocités individuelles pour chaque
membre de l'équipe ?
Traduit par Fabrice AIMETTI le 4 juillet 2011
8/9
Pour conclure (à ce stade)
Je recommande vivement aux personnes qui enseignent Scrum d’aller à la boutique LEGO
la plus proche et d’acheter certaines des boîtes.
Et oui, ça reste assez cher. Mais plus tôt vous le faites, plus vous rentabilisez votre ROI
vous et vos stagiaires. Bonne chance !
Et s'il vous plaît, envoyez-moi vos feedbacks ([email protected]) : tous vos
commentaires, critiques, idées et bilans d’ateliers seront appréciés et bienvenus. Nous
sommes tous là pour apprendre, non ?
Liens
Radiateurs d’informations LEGO
http://www.infoq.com/news/2008/09/lego-information-radiators
Jeux LEGO en paircoaching
http://www.paircoaching.net/games_en.php
Discussion sur LEGO en tant que simulation Scrum sur le groupe
scrumdevelopment
http://groups.yahoo.com/group/scrumdevelopment/message/36367
Album web des photos de ‘SCRUM guides’ avec les photos d’ateliers LEGO
http://picasaweb.google.com/scrumguides/ScrumSimulationWithLEGO#
Amusez-vous !
Traduit par Fabrice AIMETTI le 4 juillet 2011
9/9