J'utilise ce serious game, en fin de formation Scrum. Une fois que les formées possèdent les fondamentaux de Scrum, et qu'ils ont fait des exercices élémentaires pour chaque étape, il st vraiment intéressant to gérer un projet Scrum dans son ensemble.
Scrum concerne la production d'un produit, de manière itérative, et incrémentale.
Je pense que de bâtir une ville, est conforme à cette approche. Vous pouvez livrer bâtiment par bâtiment, ou vous pouvez livrer des améliorations de bâtiment. Ce qui permet d'avoir un sprint goal, et d'avoir plusieurs features par sprint.
Le propos de cet exercice est de vraiment comprendre pourquoi chaque "cérémonie" est importante, et qu'en est le but.
Généralement, je prépare avant l'exercice, un jeu de post it, avec l'ensemble des bâtiments possibles, et des choses qu'on peut trouver dans une ville agréable. J'essaye d'avoir de gros bâtiments (école, supermarché, maison, piscine, mairie,...), des choses moyennes (square, routes,....), et des petites constructions (lampadaire, bus, arrêt de bus, cabine téléphonique...).
Avant l'exercice je choisis 2 personnes, et nous faisons la priorisation du backlog. Généralement, nous faisons cela à l'aide d'un moscow (must have, should have, could have, wish to have).
Je prends une demi heure pour cela. C'est le bon moment pour le reste de l'équipe de faire une pause.
L'exercice prend environ 2h. Généralement, je choisis un PO et je fais des équipes de 3 ou 4 personnes (pas moins). On déroule 6 sprints, et tous les 2 sprint je fais tourner le PO. Les personnes qui veulent découvrir le rôle de PO le peuvent, et tout le monde peut jouer aux legos. Gardons le fun.
Je conserve quant à moi le rôle de Scrum Master, à moins que quelqu'un insiste pour me prendre le rôle. Dans cet exercice, le Scrum Master est gardien du temps, et vérifie que les cérémonies soient correctement menées. Il facilite également, en réamenageant la salle, fournissant les matériels nécessaires....
Un sprint contient 4 étapes:
- Sprint planning : 4 min
- Sprint : 7 min
- Sprint review : 4 min
- Sprint retrospective : 4 min
Sprint planning
Product owner choisit pour chaque équipe, un grand bâtiment et 2 autres features. C'est vraiment intéressant quand le PO prend un peu de temps pour broder une histoire, expliquer les raisons de ces choix (sécurité des enfants, ville propre, ville écolo, élections...).
L'équipe doit obtenir tous les détails nécessaires à l'élaboration. J'ai choisi de faire un poker planning malré tout, même si le temps est court. Cela leur permet par expérience d'évaluer leur capacité à prendre telle ou telle feature.
Sprint
Peu de choses à dire sur le sprint. L'équipe essaye de trouver sa manière de travailler. Généralement, le premier sprint est difficile. Il y a beaucoup de legos, ils ne voient pas comment s'organiser, ça patauge. C'est assez représentatif du premier sprint.
Je demande à l'équipe de ne construire que des façades, car le temps est trop court.
Dans le cas où l'équipe fini avant la fin du sprint, ils peuvent réclamer des features au PO. Pour ma part, je conseille à l'équipe d'améliorer la feature en cours, et surtout de bien préparer la démo. Il est important que l'équipe soit sensibilisé à la qualité.
Sprint Review
Généralement, l'équipe n'a pas en tête la démo, ni en quoi cela consiste. Les bâtiments sont prêts, mais pas forcément intégrés à la ville. L'histoire utilisateur n'existe pas, l'aspect "vendre" son travail n'existe pas.
Le PO doit jouer le jeu, et avoir une orientation utilisateur. Généralement, à la 1ere démo, le bâtiment est refusé, car l'équipe s'est concentrée sur des éléments structurels, alors que le PO avait fait des recommandations qui étaient importantes pour l'utilisation du bâtiment.
Cela rejoint la mentalité technique versus le besoin métier.
Il faut que l'équipe change d'état d'esprit, et comprenne qu'ils doivent construire quelque chose qui a de la valeur pour le PO, pas juste quelque chose qui soit techniquement chouette.
Exemple: l'équipe présente son square, avec des supers jeux, mais ils ont oublié les barrières autour. La préoccupation du PO était sur la sécurité du square. La feature est invalidée.
Sprint retrospective
La plupart des équipes, me disent que ce n'est pas utile, les temps sont trop courts, et de toute façon que se dire en 4min.
La rétro est obligatoire mais surtout très utile.
La plupart des erreurs faites dans le sprint, peuvent être évitées, certaines choses peuvent être améliorées. Vous pouvez aider l'équipe à leur faire comprendre ce qui pourrait être meilleur
- Posez la question de savoir quelle était la préoccupation du PO sur le sprint
- Prendre des notes pendant le sprint planning
- faire des maquettes, et les faire valider
- améliorer l'organisation de l'équipe (recherche de briques, construction, intégration,...)
- trier les briques pour être plus efficace
- Faire un inventaire pour savoir si ce que le PO demande est possible ou non, ou pouvoir lui faire des constructions
- Plus de qualité
Suivi
Généralement, je produis un graphique, présentant la vélocité de l'équipe par sprint. Cela leur permet de connaître leur vélocité, comparer de sprint en sprint, se challenger...
Cela permet également de voir si l'équipe arrive à trouver son rythme, ou au contraire, s'ils sont trop "fous" et désorganisés.
Debrieffing
Généralement, je fais un tour de table.
Ensuite j'effectue un retour sur ces sujets:
- Un grand succès, généralement on a une ville, et l'équipe au début ne se pensait pas capable d'aller aussi loin, et de créer un projet de zéro.
- Le graphique permet de voir rapidement quand l'équipe s'est stabilisé.
- Retrospective : partage sur les points d'améliorations trouvés par les équipes et conséquences réelles
- Démo : son importance, les discussions générées, la compréhension du besoin, les difficultés, la motivation qui en ressort, lié à la fierté d'avoir produit de nouvelles features.
- Planning : souligner l'importance de ce moment pour travailler sereinement, et avoir la certitude de bien partir.
- Sprint : souligner l'importance de l'auto organisation, sans un chef de projet, la capacité à résoudre les problèmes par eux même.
Ce serious game est intense, mais permet de bien appliquer la méthodo. Cela met bien en évidence l'importance de chaque "cérémonie" et l'importance de la communication.
Rappeler l'importance du daily meeting, malgré le fait que dans le jeu il n'était pas possible de le faire, rappeler les concepts principaux, et le pourquoi.
Ne minimaliser pas votre rôle, le travail de facilitation, de coaching, pour que le jeu maintienne un rythme soutenu n'est pas chose aisée.
Aucun commentaire:
Enregistrer un commentaire