Qu'est-ce que la rétrospective en arêtes de poisson (Ishikawa) ?
La rétrospective en arêtes de poisson (Ishikawa) aide votre équipe à trouver les causes profondes d'un problème au lieu d'en traiter les symptômes. Elle repose sur le diagramme de causes et effets popularisé par Kaoru Ishikawa dans les années 1960, qui organise les causes possibles selon une forme rappelant le squelette d'un poisson. Dans ce modèle, votre équipe passe en revue six catégories de causes : Système, Processus, Formulaires, Personnes, Règles et Lieu. Avancer catégorie par catégorie pousse chacun à dépasser la première explication qui lui vient à l'esprit, si bien que les causes qui sortent du domaine de chacun sont elles aussi soulevées. Elle est particulièrement utile pour les problèmes aux multiples facteurs, quand une solution évidente n'a pas suffi. Classer les causes par catégorie montre comment elles sont liées, ce qui vous oriente vers le changement qui aura le plus d'impact. Un diagramme en arêtes de poisson (aussi appelé diagramme d'Ishikawa ou diagramme de causes et effets ; ces trois noms désignent le même outil) place le problème à la « tête » du poisson et représente les grandes catégories de causes comme des arêtes partant de la colonne vertébrale. Dans sa forme d'origine, issue de l'industrie et de la gestion de la qualité, ces catégories sont les « 6 M » : Main-d'œuvre (les personnes), Méthode (le processus), Machine (l'équipement), Matière (les intrants), Mesure (les données et indicateurs) et Milieu (l'environnement). L'équipe recense les causes possibles sous chaque arête, puis continue de demander « pourquoi ? » pour remonter chaque branche jusqu'à sa cause racine. Les catégories de ce modèle adaptent les 6 M aux équipes logicielles et aux métiers du savoir. La technique reste la même ; seuls les intitulés changent pour coller à votre travail. Si le problème placé à la tête du poisson est « les mises en production prennent sans cesse du retard », une cause Personnes pourrait être « un relecteur clé fait goulot d'étranglement », une cause Processus « pas de définition de terminé » et une cause Système « un pipeline CI instable ». Cartographier les causes ainsi évite à votre équipe de corriger un symptôme en passant à côté de ce qui provoque réellement le problème.
Format de rétrospective en arêtes de poisson
Système
Quels outils, logiciels ou technologies pourraient affecter la performance ou les résultats de notre équipe ?
Examinez votre infrastructure technique, vos outils logiciels et les points de connexion entre les systèmes. Interrogez l'équipe sur les pannes techniques évidentes, mais aussi sur les interactions plus discrètes entre systèmes qui ralentissent le travail.
Processus
Quels flux de travail ou enchaînements d'activités ralentissent ou compliquent notre travail ?
Repérez les goulots d'étranglement, les étapes en double et les manques dans vos flux de travail. Poser des questions sur des étapes précises de la réalisation du travail aide l'équipe à distinguer les problèmes de processus des autres causes.
Formulaires
Quels problèmes liés à nos modèles ou à notre documentation pourraient nuire à la clarté ou à l'exactitude ?
Passez en revue vos modèles et votre documentation. Les gens trouvent-ils ce dont ils ont besoin, les documents sont-ils complets et remplissent-ils leur rôle ? Incluez les documents informels autant que les documents officiels.
Personnes
Quels facteurs liés aux compétences, à la communication ou aux rôles influent sur notre réussite ?
Parlez des compétences, de la communication et des rôles en gardant une discussion sans recherche de coupable. Concentrez-vous sur le contexte qui entoure les personnes, comme des rôles flous ou des silos de connaissances, et non sur la critique des individus.
Règles
Quelles règles ou directives pourraient être en décalage avec nos pratiques réelles ou nous poser des difficultés ?
Examinez les règles écrites et non écrites qui influent sur le travail. Demandez-vous si chaque règle soutient encore la façon dont l'équipe travaille aujourd'hui ou si elle la freine.
Lieu
Quels aspects de notre espace de travail, physique ou virtuel, pourraient nuire à notre collaboration ou à notre productivité ?
Pensez à l'espace de travail physique et virtuel, y compris vos outils, l'agencement des bureaux et la qualité de la collaboration à distance.
Dans quels cas recourir à cette étude rétrospective ?
- Quand un problème a probablement plusieurs causes
- Après un incident important qui mérite une analyse structurée avant que quiconque ne propose une solution
- Quand l'équipe corrige sans cesse les symptômes et que le problème revient toujours
- Lors de post-mortems de projet ou de revues d'incident, pour éviter que le même échec ne se reproduise
Exemples de questions pour brise-glace
- Si notre équipe était une machine, quelle pièce aurait le plus besoin d'entretien en ce moment ?
- Quelle est la solution la plus surprenante que vous ayez trouvée à un problème récurrent ?
Vous souhaitez un exercice d'échauffement que votre équipe puisse pratiquer, et pas seulement répondre à voix haute ? Découvrez des brise-glaces gratuits →
Idées et conseils pour votre réunion de rétrospective
- Rédigez un énoncé clair du problème à la tête du poisson avant que quiconque n'ajoute une cause
- Veillez à ce que chacun ajoute des causes dans toutes les catégories, y compris celles qui sortent de son propre rôle
- Attendez que les causes soient cartographiées avant de parler de solutions
- Utilisez les 5 pourquoi dans chaque catégorie pour aller au-delà de la première réponse
- Notez toutes les causes, même celles qui semblent mineures au départ
- Prévoyez 90 à 120 minutes pour couvrir correctement les six catégories