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