This article is also available in English

Rawr !

D-Rex explique à ses collègues ...
Si D-Rex, le dino agile, avait vécu il y a 60 millions d’années, les autres dino ne seraient pas devenus des poules

Imaginez que vous puissiez transmettre votre expérience à toute votre équipe. Vos échecs, vos réussites, vos découvertes, immédiatement et que vous puissiez avoir une discussion constructive avec eux dans la foulée; cela ne serait-il pas formidable ? Découvrons le D-Rex.

Définition du D-Rex

Le Retour d’Expérience (abrégé : Rex) est un événement de partage des connaissances.

Le Daily-Rex (abrégé : D-Rex) est un REX d’au maximum 10 minutes qui est fait “dès que nécessaire et que chacun est disponible, mais pas plus tard que la fin de la journée”.

Le D-Rex, un évènement qui s’inscrit dans Scrum

Dans Scrum, le Sprint est un moment d’apprentissage de l’équipe, d’expérimentation et d’amélioration, autant que de production.

Parce que nous travaillons sur des problèmes complexes dans un monde complexe, l’équipe apprend constamment et se retrouve régulièrement confrontée à des problèmes nouveaux et plus complexes que prévus.

Devant un tel problème, le développeur va chercher, étudier et ‒normalement‒ trouver des solutions (si besoin il ou elle sera aidé(e) par d’autres membres de l’équipe). Le développeur gagne alors de l’expérience à deux niveaux :

  1. l’expérience du problème
  2. l’expérience de la solution

En tant que Scrum Master, vous devriez être attentif à ce gain d’expérience et l’équipe devrait prévoir immédiatement après la correction un temps pour le D-Rex : “dès que nécessaire et que chacun est disponible, mais pas plus tard que la fin de la journée”.

Il est important d’exécuter le D-Rex au plus tôt afin de limiter l’effet de contagion et de profiter que ce soit frais dans l’esprit du ou des développeurs.

Au pire, le D-Rex commencera donc 10 minutes avant la fin de la journée et se déroule de la façon suivante (il peut être important, comme dans d’autres évènements, d’afficher clairement le déroulé de la séance) :

  1. La personne à l’initiative du D-Rex commence par décrire le problème rencontré et l’impact de celui-ci sur le produit ou sur le processus de développement avant sa correction.
  2. Il ou elle décrit ensuite brièvement les pistes de recherches qui n’ont pas abouti, pour ensuite expliquer la solution adoptée.
  3. Une étape importante est alors de décrire les conséquences connues de l’application de la correction et de son impact sur le produit et le travail d’autres membres de l’équipe ou d’autres équipes.
  4. Les personnes présentes peuvent alors poser des questions et remettre en question la solution appliquée. Il est préférable d’établir un autre moment pour argumenter et creuser si nécessaire les autres solutions.
  5. Si les items du backlog sont estimés en effort, il convient de revoir l’effort initialement estimé afin de refléter cette découverte dans la vélocité de l’équipe.

10 minutes, ce n’est pas forcément suffisant

La timebox de 10 minutes du D-Rex est essentielle pour permettre sa tenue dans la journée et sans trop impacter l’agenda des différents membres de l’équipe.

Si la découverte demande plus d’explications ou d’introspections, il est alors préférable de garder le format court de 10 minutes maximum dans la journée, puis de proposer d’approfondir le sujet à un autre moment.

Qui doit être présent ?

La personne à l’initiative du D-Rex, et l’équipe de développement au minimum.

Le Product Owner peut être invité si la découverte a un impact sur d’autres éléments du backlog du sprint ou du backlog produit.

D’autres équipes (ou leurs représentants) peuvent être invitées si le problème ou sa correction ont un impact sur leur domaine.

Pourquoi ne pas utiliser les évènements Scrum ?

La rétrospective, qui est un moment privilégié pour inspecter l’équipe, peut-être un bon moment pour faire un retour d’expérience sur la résolution d’un problème, mais cela ne doit pas être le seul.

Il arrive souvent qu’une équipe attende la fin du sprint pour évoquer les problèmes. Cela peut avoir un impact limité sur un Sprint d’une semaine, mais cela peut être désastreux pour des Sprints plus long.

Le Daily Scrum n’est pas le moment d’expliquer les problèmes rencontrés, c’est le moment de les signaler, surtout s’ils impactent un autre dev ou l’objectif de Sprint, mais ce n’est pas le moment d’en parler pendant le Daily Scrum.

Le D-Rex ne remplace pas le daily scrum mais vient en complément lorsque nécessaire.

Et vous ?

Que pensez-vous de ce format ? Avez-vous déjà une solution pour un retour d’expérience rapide et cadré ?

🦖