BT

Rocket to Mars : Un jeu de planification de sprint

par Ben Linders , traduit par Nicolas André le 13 déc. 2013 |

D'après Damien Thouvenin et Pierrick Revol “Beaucoup d'équipes et leurs product owner pensent que l'unique travail de l'équipe consiste à délivrer de plus en plus de points de story, nous considérons que c'est une totale incompréhension de la relation entre l'équipe et son product owner". A la conférence 2013 des XP Days Benelux, Damien et Pierrick ont animé un jeu de planification de sprint à destination des équipes et des product owners pour leur apprendre comment investir leur temps à produire des stories, traiter les problèmes, réduire la dette technique ou faire de la formation.

Rocket to Mars (v2) est un jeu de rôle collaboratif à destination des Scrum product owners, leurs managers et les équipes avec lesquelles ils travaillent pour apprendre les pratiques de planification agiles et lean. C'est un jeu de société joué par des équipes qui peuvent choisir et adapter leur stratégie afin de construire une fusée pour la prochaine mission vers Mars. Dans le jeu, ils prennent la décision de partir dans une analyse en profondeur ou de commencer à coder, de développer une expertise ou des compétences généralistes, de refactoriser ou de terminer les user stories pour accumuler le plus de points de story. Le but du jeu est de marquer le plus de points en 8 itérations. Les points sont marqués en terminant les user stories mais les points sont déduits lorsque l'on accumule de la dette technique. Ce jeu est le successeur du jeu Objectif Mars.

Au départ, les membres de l'équipe ne sont qualifiés que pour faire une activité, en se formant ils peuvent développer de nouvelles compétences. Lorsque les membres de l'équipe acquièrent ces compétences, ils sont capables de réaliser différentes activités et l'équipe va devenir ainsi multidisciplinaire et capable de produire plus de travail lors d'une itération.

Ce jeu est inspiré d'une conférence donnée par le professeur Philippe Kruchten couverte par InfoQ dans what color is your backlog, où il parle des décisions clés qui doivent être prises tôt pour préparer le terrain des travaux en cours. Cette présentation explique que pour chaque sprint, l'équipe doit décider, si elle va délivrer des nouvelles fonctionnalités, corriger des bugs, ou investir du temps en formation. Damien et Pierrick ont montré comment ces décisions se divisent en 4 quadrants qui représentent les effets à court terme vs les effets à long terme (ou effets visibles et effets invisibles) et l'aspect production vs prévention des risques : 

Damien et Pierrick ont demandé aux équipes ce qu'elles avaient appris en jouant au jeu. Une équipe a expliqué comment elle a été ralentie par la maladie, ce qui a causé une baisse de leur vélocité. Il n'y en a pas beaucoup qui ont estimé pouvoir faire face à cela. Une autre équipe a expliqué comment le fait d'investir tôt dans la formation les a aidés à devenir plus rapides dans les sprints suivants. Les autres retours exprimés étaient que jouer au jeu "montrait la vraie valeur de l'investissement dans la formation et l'analyse", "le jeu montre les problèmes de la vie réelle pendant les sprints", "donne une bonne vision de la différence entre un backlog de sprint et un backlog de produit pendant la planification des sprints", et "le jeu est très amusant, on apprend beaucoup".

Pendant le débriefing Damien a expliqué comment une stratégie peut gérer une fonctionnalité, une dette technique et une formation dans le jeu de planification.

Ce que les participants apprennent à travers le jeu, c'est que la planification de sprint ne doit pas seulement considérer le nombre de user stories que nous pouvons empiler dans le backlog de sprint. La préoccupation de l'équipe et du PO devrait être de permettre la viabilité à long terme. Comme il n'y a pas d'espace entre les sprints, cela signifie que toutes les activités doivent prendre place pendant le sprint : réduction de la dette technique avant qu'elle n'explose et vous bloque, investigation sur les futures stories et epics, nettoyage du backlog, exploration des options techniques pour les prochains sprints, formation des personnes sur les sujets techniques et métiers.

En conclusion sur le jeu, Damien a déclaré que "l'équipe et leurs product owners devraient discuter de la manière dont ils veulent que l'équipe investisse son temps dans le sprint : par la production de points de story, le traitement des problèmes, en tuant la dette ou en faisant de la formation".

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2013 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT