Lors d’un sprint l’équipe s’est retrouvée face a un problème dont nous étions tous conscient mais dont les réelles causes continuaient à nous échapper.
Lors de la rétrospective, nous avons alors utilisé la technique des ‘‘5 pourquoi’’ pour aller aux racines du mal et éviter de se contenter d’effleurer la surface.
La technique des 5 pourquoi est une méthode simple qui consiste à cascader 5 fois la question ‘‘pourquoi’’ avec, à chaque fois, le pourquoi se posant sur la réponse précédente. Bon j’ai pas l’impression d’être bien clair là. Faites donc un détour par chez Pablo et son billet Mammuth et les 5 pourquoi et tout deviendra limpide.
##déroulement Notre séance de rétrospective s’est donc déroulée ainsi :
- rappel et présentation du problème.
- explication de la technique des ‘‘5 pourquoi’’
- nous étions 7, trop nombreux pour pouvoir faire les 5 pourquoi de façon collective. Nous avons donc divisé l’équipe en deux groupes de 3, et je passais d’un groupe à l’autre pour les aider à formaliser leur questionnement et éviter de tourner en rond (si elle parait simple, la technique des 5 pourquoi n’est pas aussi évidente que ça).
- chaque groupe a ensuite présenté à l’autre les conclusions auxquelles il était parvenu.
- pour finir nous avons fait un débriefing collectif et décider ensemble de deux actions à mettre en place pour l’itération suivante.
##conclusion Au final, le résultat a été concluant. Il a permis à l’équipe de se rendre compte d’une faiblesse masquée par d’autres éléments et de mettre en place une action pour y remédier1.
C’est une méthode pratique pour mettre le doigt sur les causes cachées des problèmes, mais la technique des 5 pourquoi n’est pas évidente à pratiquer quand on ne la maîtrise pas. Il est important de suivre de ce qui se passe dans le groupe pour éviter un enlisement.
-
dans ce cas l’action est une formation sur les tests unitaires et le TDD ↩
Poursuivre la discussion
Envie de réagir à l'article ? Il suffit de me laisser un message via la page de contact, sur mastodon @avernois@piaille.fr ou un billet chez vous.
Vous pouvez aussi proposer des modifications via le source de cet article sur gitlab.