Je continue avec mes retours d'expérience sur l'atelier Puzzle grand Scrum que j'ai animé une quinzaine de fois.

Après des discussions sur par quoi commencer et sur la synchronisation des sprints, revenons sur l'organisation des équipes.

Pour réaliser le puzzle avec 3 équipes, on a besoin de définir sur quoi chacune va travailler.

Nous sommes dans le cas où il n'y a qu'un seul produit et je fournis au participant au jeu un seul backlog, sous la forme de 20 features (ou stories peu importe). Nous avons vu dans un épisode précédent comment ça se passait pour définir l'ordre dans ce backlog.

Les participants disposent également d'un tableau préparé, avec un colonne (ou une ligne) pour y mettre les features prêtes. Je leur dis simplement que pour y mettre un élément, il conviendrait de lui associer l'équipe ou les équipes qui vont le développer.

Le tableau de features est un outil de management visuel qui reste unique même quand le produit est gros et que plusieurs équipes y travaillent.

Dans le Scrum multi-équipes mono-produit, il y a donc une activité supplémentaire d'affinage, qui est de définir cette association entre une équipe ou plusieurs et une feature.

Dans le jeu, la plupart du temps, on a associé une feature à une seule équipe. C'est pour former ce qu'on appelle les "feature teams". À noter que je ne dis rien, quand j'anime le jeu, qui pousse les joueurs dans ce sens, ce qui laisse à penser que la notion est familière aux participants.

Il y a eu cependant quelques exceptions, en général au début et à la fin du jeu. Parfois, au début, comme lors du dernier Raid, il est d'abord prévu de mettre 2 équipes sur une feature. En général, cela ne dure pas et quand le sprint démarre, la feature est faite par une seule équipe.

Pourtant, en ayant suivi tous ces puzzles, je pense que le tri des pièces pose des problèmes aux équipes features. Sans un tri grossier, c'est difficile de savoir si on pourra assembler et intégrer un personnage dans un sprint. C'est un peu l'équivalent de l'infrastructure dans les gros projets, qui pousse parfois les organisations à choisir des structures hybrides, avec une component (ou infra) team à côté des features teams.

Ce ne serait pas une bonne idée d'avoir une équipe tri pour toute la durée du puzzle. En tout cas, personne ne l'a fait dans les ateliers que j'ai animés. Mais on peut ajouter des features de tri au backlog, qui seront prises par les features teams, en plus de leurs features à valeur client. C'est arrivé, mais seulement 2 fois sur les 15.

Feature tri ajoutée

À la fin du jeu par contre, dans le 4e sprint, il y a une volonté collective de faire participer toutes les équipes à la réalisation d'une seule feature. Il faut dire que les circonstances ont changé (héhé).

Sur quoi se base le choix de mettre telle ou telle équipe sur une feature ?

Dans le jeu, il arrive qu'une équipe soit associée à une zone du puzzle et ensuite s'occupe de tous les personnages de cette zone. Ce critère de choix se retrouve sur les projets, quand on donne à une équipe un domaine fonctionnel (dans LeSS, on retrouve cette idée avec les requirements areas). Sinon la plupart du temps, le choix se fait de façon opportuniste, sans réelle stratégie.

Qui décide du choix d'une équipe pour une feature ? Nous le verrons dans un prochain épisode sur le volet PO et Cie.