Animer un atelier de Définition de prêt / Définition de fini

Supposons que vous soyez sur un projet de développement logiciel en mode agile (SCRUM par exemple). L’une des premières règles mise en place au sein de l’équipe a été la « Définition de fini », n’est-ce pas ? Vous ne disposez pas d’une définition claire des critères permettant de considérer qu’une User Story est terminée ? Pour cela, il vous faudra dresser une liste d’attributs de l’état « fini » pour une User Story. Une première façon de faire serait de demander à Google en utilisant les mots-clés : Definition of done, DoD ou Définition de fini. Vous pourrez alors vous inspirer ou directement reprendre la « Définition de fini » d’une autre équipe.

Mais cela ne s’apparenterait-il pas à de la triche ? Ou une solution de facilité ? Le risque serait de disposer d’une définition de fini « gadget », qui ne soit pas appropriée par l’équipe. Il est important que la liste des critères soit le reflet de ce qui est important pour l’équipe. Partager sa compréhension de l’état fini d’une User Story favorise les débats sur les éventuelles zones d’ombre, de sorte à construire un document de travail authentique. Si certains membres de l’équipe considèrent qu’une User Story ne sera considérée comme terminée que lorsque plus aucun bug ne sera trouvé dans le code, alors que d’autres accepteront quelques anomalies mineures, il est grand temps d’avoir une discussion d’équipe. De préférence en début de projet plutôt qu’une fois que le Product Owner dit : « On livre en prod ». Au-delà d’une simple discussion, c’est réellement un dialogue qui s’établit, dans lequel chacun propose ses hypothèses et explique les valeurs qui sous-tendent son point de vue. Cet atelier prend toute sa place dans la deuxième étape du modèle de dynamique de groupe de Tuckman (Formation, Construction/Confrontation, Structuration/Normalisation, Performance – Forming, Storming, Norming, Performing).

Donc, plutôt que d’utiliser tel quel la Définition de fini d’une autre équipe, créez votre propre liste de critères. Bien sûr, vous pourriez avoir besoin d’amorcer la pompe avec un peu d’eau. Ou bien réalisez cet atelier devant un tableau blanc en supprimant toutes les chaises afin de privilégier la position debout (la station debout augmente de 20% le flux sanguin vers le cerveau) et favoriser les interactions entre les participants.

Je vous recommande de tracer sur un tableau, une cible (de grande taille) composée de 3 cercles (ou rectangles) concentriques. Inscrivez « Maintenant » dans le cercle intérieur, « Plus tard » dans le cercle extérieur, « Suivant » dans le cercle intermédiaire. C’est une manière de hiérarchiser les choses (maintenant -> prochaine étape -> plus tard) et de familiariser l’équipe avec la notion de priorisation (que nous utilisons aussi pour ordonner le Product Backlog – Non ?). Placez ensuite des post-its ou des fiches cartonnées sur la table en demandant à chacun de venir y inscrire un aspect de la Définition de fini par carton. A tour de rôle chaque participant peut soit déplacer une carte existante vers un emplacement qui lui semble plus approprié (parmi « maintenant », « suivant » ou « plus tard »), soit créer une nouvelle carte et la positionner. Le jeu continue jusqu’à ce que les participants en ont assez ou lorsque vous obtenez une liste de critères suffisamment aboutie. Vous pouvez alors échanger sur le jalonnement dans le temps de la mise en place de votre « définition de fini« . A quelle échéance met-on en place les critères dans la zone « Suivant » ? dans la zone « Plus tard » ? Il est tout à fait imaginable que « fini » signifie quelque chose de totalement différent entre le sprint courant et le sprint 25, après 4 releases et un certains nombre de retours des utilisateurs ou du client.

Si vous le souhaitez, vous pouvez télécharger et imprimer le jeu de cartes que j’utilise (à venir) pour animer ce type d’atelier. Son utilisation n’est pas obligatoire, notamment si vous souhaitez que l’équipe définisse sa propre « définition de fini », mais cela permet de favoriser les interactions entre participants dubitatifs ou réticents.

Dans l’exemple ci-contre (photo à venir), les cartes ont été regroupées par catégories au sein de la rubrique « Suivant ». Ce comportement spontané de l’un des membres de l’équipe leur a permis d’organiser les informations de façon visibles. Ils ont ensuite réalisé un dot-voting pour choisir les critères à intégrer dans la rubrique « Maintenant » de la « Définition de fini« . Les cartes ont alors été déplacées dans le cercle (ou rectangle) central. De la même manière, le groupe s’est ensuite penché sur leur compréhension de la « Définition de prêt » permettant de considérer qu’une User Story est prête pour la planification de sprint.

Vous voilà prêt à animer vos ateliers de « Définition de fini » et de « Définition de prêt ». Besoin d’aide ? N’hésitez pas à me contacter.