En 2014, j'avais essayé un jeu de simulation de Scrum, avec un puzzle ; il mettait l'accent sur l'affinage et la présentation du backlog en bacs[1], c'était donc le jeu des bacs.

Début 2015, j'avais expérimenté une variante pour simuler du Scrum à plusieurs équipes.

Cette variante a reçu un très bon accueil, ce qui fait que je l'ai animée de nombreuses fois. J'ai eu du mal à lui trouver un nom. Cela a d'abord été "Astérix et la grande échelle de Scrum" parce que j'utilisais le puzzle "Le village gaulois".

Finalement c'est "Puzzle grand Scrum".

Un atelier que j'ai animé une quinzaine de fois :

  • au cours des jeux agiles de l'IPI à Blagnac,
  • à Agile Games France 2015 à Bazas,
  • au ScrumDay 2015,
  • à Agile tour Montpellier,
  • à Agile tour Toulouse,
  • au cours des 4 derniers Raids Agiles (animation avec Pablo aux manettes pour les rétros),
  • dans 5-6 autres formations Scrum.

À raison de plus de 2 heures par session, cela m'a permis de collecter plein de comportements intéressants sur, par exemple, la notion d'équipe feature, le rôle de Product Owner, l'auto-organisation et le ScrumMaster, l'affinage multi-équipes, les démos et les rétrospectives, la définition de fini. Je vais en restituer quelques-uns, en commençant par la façon de prioriser.

Mais avant, et en rappelant que l'objectif de l'atelier est de simuler la réalisation d'un seul produit avec 3 équipes, une réaction émerge parfois, et c'était en particulier le cas lors du dernier Raid, qui est : "ce serait plus facile avec une seule équipe". C'est probablement vrai pour le puzzle, mais c'est aussi une question légitime pour du développement de logiciel. Le passage à l'échelle complique les choses et il vaut mieux l'éviter chaque fois que c'est possible.

Ceci étant dit, voyons ce que donne le jeu avec 3 équipes, sur la question : par quoi commencer le puzzle ?

Par le cadre

L'envie de commencer le puzzle par le cadre arrive fréquemment, c'est comme cela que cela se fait d'habitude pour un puzzle. L'exercice pousse à changer cette habitude (le cadre n'a pas de valeur métier, on ne fera pas tout le puzzle et j'insiste sur cela) et certains ont du mal. Cela provoque des discussions avec le PO sur la priorité à donner. Parfois les partisans du cadre l'emportent (pas bien loin, car le cadre ne survit pas à la première démo).

Je rappelle que je fournis au début du jeu une liste de 20 stories (ou features, peu importe ici) et pour chacune la valeur métier que je lui donne. Dans cette liste, il n'y a pas de cadre, qui nécessiterait pour être réalisé plusieurs stories, toutes de faible valeur.

Par le tri

Il est arrivé que le backlog soit enrichi de nouvelles cartes genre tri des pièces. C'est assez rare ; en général, cela vient dans la conversation mais n'est pas accepté par les partisans de la valeur métier.

Une story "tri" n'apporte pas de valeur métier, mais on peut considérer qu'elle apporte de la valeur à l'équipe. Cela correspond à une story technique.

Il est probable que si je ne fournissais pas une liste prédéfinie, il y aurait plusieurs stories techniques de ce genre dans le premier sprint.

Par un personnage

La logique utilitariste voudrait que ce soit Astérix qui soit fait en premier, puisque c'est le personnage qui a le plus de valeur. Dans l'atelier, on ne fait pas d'estimation de la taille des personnages (ni de l'effort pour les réaliser), mais c'est assez facile à imaginer avec la surface que prend ce personnage dans l'image du puzzle. Même en utilisant le ratio valeur / taille, c'est toujours Astérix qui semble prioritaire. La différence avec Obélix est flagrante, qui rapporte moins de valeur et qui est plus gros enveloppé.

Pourtant, ce n'est pas toujours Astérix qui est choisi en premier. Par exemple, lors du Raid Agile #5, Richard, qui était le PO, a demandé Bonnemine en premier. Pour lui, c'était mieux de commencer comme ça. Richard n'est pas utilitariste, il a fait parler son cœur (à la démo du premier sprint, il a un feedback rude des parties prenantes).

tableau du puzzle au début

Pendant le jeu, tout cela provoque des conversations et c'est le but. La façon dont est prise la décision sur la priorité, dépend finalement du ou des PO (j'ai essayé le jeu avec différentes configurations), c'est un sujet sur lequel je reviendrai.

Dans un prochain article, je parlerai aussi de la définition de fini. Astérix fini, est-ce bien clair pour tout le monde ce que cela signifie ?

Note

[1] notion qui est présentée en détail dans mon livre, chapitres 7 et 8