Rétrospective Fishbone (Ishikawa)

Utilisez un diagramme fishbone (Ishikawa) pour trouver les causes profondes des défis de l'équipe grâce à la méthode éprouvée de cause à effet.

Utilisez ce modèle dans TeamRetro

Système

Quelle technologie, quels logiciels ou outils pourraient affecter nos performances ?

Notre pipeline de déploiement échoue souvent aux heures de pointe
L'environnement de test ne correspond pas aux paramètres de production
L'intégration entre nos outils de suivi des tâches et git n'est pas fiable
Processus

Quels flux de travail ou séquences d'activités causent des retards ou des inefficacités ?

Le processus de revue de code prend trop de temps avec de multiples allers-retours
Pas de définition claire de « terminé » pour les user stories
Les réunions de planification de sprint dépassent régulièrement le temps prévu
Formulaires

Quels problèmes avec nos modèles ou notre documentation pourraient affecter la clarté ?

Le modèle de user story manque d'une section de critères d'acceptation
Le formulaire de rapport d'incident ne capture pas efficacement la cause profonde
La documentation est éparpillée sur plusieurs plateformes
Personnes

Quels facteurs liés aux compétences, à la communication ou aux rôles affectent notre succès ?

L'équipe manque d'expertise dans la nouvelle pile technologique
Lacunes de communication entre les membres à distance et au bureau
Rôles et responsabilités peu clairs dans les projets transversaux
Politiques

Quelles directives ou règles pourraient être mal alignées avec nos pratiques réelles ?

Les politiques de sécurité rendent le développement local difficile
Le processus de gestion du changement est trop rigide pour les correctifs rapides
La politique de congés crée des contraintes de ressources
Lieu

Quels aspects de notre espace de travail physique ou virtuel affectent notre collaboration ?

Mauvaise connexion internet dans les lieux de travail à distance
Manque d'espaces calmes pour un travail concentré
Les outils de collaboration virtuelle ne répondent pas bien à nos besoins

Qu'est-ce que la rétrospective Fishbone (Ishikawa) ?

La rétrospective Fishbone (Ishikawa) est une approche structurée de résolution de problèmes qui aide les équipes à identifier et à comprendre les causes profondes de leurs défis ou problèmes. Développée par Kaoru Ishikawa dans les années 1960, cette technique visualise les relations de cause à effet dans un format ressemblant à un squelette de poisson. Pendant la rétrospective, les équipes explorent six dimensions clés susceptibles de contribuer à leurs défis : Systèmes, Processus, Formulaires, Personnes, Politiques et Lieu. Cette analyse complète garantit qu'aucun facteur potentiel n'est négligé, ce qui conduit à des solutions plus efficaces. Cette méthode est particulièrement précieuse pour les équipes confrontées à des problèmes complexes où plusieurs facteurs peuvent être en jeu. En organisant les causes potentielles en catégories distinctes, les équipes peuvent mieux comprendre les relations entre les différents problèmes et développer des améliorations ciblées. Un diagramme fishbone (aussi appelé diagramme d'Ishikawa ou diagramme de cause à effet — les trois noms désignent le même outil) fonctionne en écrivant le problème à la « tête » du poisson et en dessinant les principales catégories de causes sous forme d'arêtes se ramifiant à partir de la colonne vertébrale. Dans sa forme originale de fabrication et de gestion de la qualité, ces catégories sont les classiques « 6 M » : Main-d'œuvre (les personnes), Méthode (le processus), Machine (l'équipement), Matière (les intrants), Mesure (les données et les indicateurs) et Milieu (l'environnement environnant). Les équipes réfléchissent aux causes possibles sous chaque arête, puis continuent à demander « pourquoi ? » pour remonter chaque branche jusqu'à sa cause profonde plutôt que de s'arrêter au symptôme visible. Les catégories de ce modèle TeamRetro — Système, Processus, Formulaires, Personnes, Politiques et Lieu — sont une adaptation de la même méthode des 6 M pour les processus d'équipe, réajustée pour les équipes de développement logiciel et de travail intellectuel plutôt que pour une usine. La technique est identique ; seules les étiquettes de catégorie changent pour s'adapter au type de travail que vous effectuez. Par exemple, si le problème à la tête du poisson est « les mises en production sont sans cesse retardées », une cause liée aux Personnes pourrait être « le relecteur clé est un goulot d'étranglement », une cause liée au Processus pourrait être « pas de définition de terminé », et une cause liée au Système pourrait être « pipeline CI instable ». Cartographier les causes de cette manière empêche une équipe de corriger les symptômes tout en passant à côté du facteur sous-jacent.

Format de la rétrospective Fishbone

Système

Quelle technologie, quels logiciels ou outils pourraient affecter nos performances ?

Guidez l'équipe dans l'examen de l'infrastructure technique, des outils logiciels et des points d'intégration des systèmes. Encouragez les participants à réfléchir à la fois aux problèmes techniques évidents et aux interactions subtiles des systèmes qui pourraient avoir un impact sur leur travail.

Processus

Quels flux de travail ou séquences d'activités causent des retards ou des inefficacités ?

Concentrez-vous sur l'identification des goulots d'étranglement, des redondances ou des lacunes dans les flux de travail. Aidez l'équipe à distinguer les problèmes de processus des autres facteurs en posant des questions sur les étapes spécifiques de leurs procédures de travail.

Formulaires

Quels problèmes avec nos modèles ou notre documentation pourraient affecter la clarté ?

Examinez la qualité, l'accessibilité et l'exhaustivité de la documentation. Considérez à la fois la documentation formelle et informelle, et dans quelle mesure elle remplit son objectif.

Personnes

Quels facteurs liés aux compétences, à la communication ou aux rôles affectent notre succès ?

Abordez la dynamique d'équipe et les contributions individuelles tout en maintenant un environnement sans blâme. Concentrez-vous sur les problèmes systémiques plutôt que sur la critique personnelle.

Politiques

Quelles directives ou règles pourraient être mal alignées avec nos pratiques réelles ?

Explorez les politiques formelles et informelles qui ont un impact sur le travail. Déterminez si les politiques soutiennent ou entravent les besoins et pratiques actuels de l'équipe.

Lieu

Quels aspects de notre espace de travail physique ou virtuel affectent notre collaboration ?

Considérez à la fois les environnements de travail physiques et virtuels. Incluez des facteurs comme les outils, l'agencement de l'espace de travail et les capacités de collaboration à distance.

Dans quels cas recourir à cette étude rétrospective ?

  • Face à des problèmes complexes pouvant avoir plusieurs causes profondes ou facteurs contributifs
  • Après avoir identifié un problème ou un défi important nécessitant une analyse systématique
  • Lorsque l'équipe doit dépasser les symptômes pour comprendre les causes sous-jacentes
  • Lors des post-mortems de projet ou des revues d'incidents pour prévenir les problèmes futurs

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 découverte pour un problème récurrent ?

Idées et conseils pour votre réunion de rétrospective

  • Commencez par définir clairement l'effet ou l'énoncé du problème à la « tête » du poisson
  • Encouragez une participation équitable de tous les membres de l'équipe dans toutes les catégories
  • Concentrez-vous sur l'identification des causes plutôt que de sauter trop rapidement aux solutions
  • Utilisez la technique des « Cinq Pourquoi » dans chaque catégorie pour approfondir les causes profondes
  • Documentez toutes les observations, même si elles ne semblent pas significatives au premier abord
  • Prévoyez suffisamment de temps (90 à 120 minutes) pour explorer toutes les catégories en profondeur

Foire aux questions

Quels sont les 6 M d'un diagramme fishbone ?
Les 6 M sont les catégories de causes classiques utilisées dans un diagramme fishbone (Ishikawa) en gestion de la qualité et en fabrication : Main-d'œuvre (les personnes impliquées), Méthode (le processus ou flux de travail), Machine (équipement et outils), Matière (intrants et fournitures), Mesure (les données et indicateurs utilisés) et Milieu (l'environnement environnant). Chaque « M » devient une arête se ramifiant à partir de la colonne vertébrale du poisson, et l'équipe réfléchit aux causes possibles sous chacune d'elles. Ce modèle TeamRetro adapte cette même idée des six catégories pour les équipes de développement logiciel et de travail intellectuel en utilisant les étiquettes Système, Processus, Formulaires, Personnes, Politiques et Lieu.
Quelle est la différence entre un diagramme fishbone et un diagramme d'Ishikawa ?
Il n'y a aucune différence — ce sont deux noms pour le même outil, avec un troisième nom, le « diagramme de cause à effet ». On l'appelle diagramme fishbone (arête de poisson) parce que le dessin fini ressemble à un squelette de poisson, et diagramme d'Ishikawa d'après Kaoru Ishikawa, l'expert japonais en contrôle qualité qui l'a popularisé dans les années 1960.
Comment réalise-t-on une analyse des causes profondes avec un diagramme fishbone ?
Écrivez le problème à la tête du poisson, puis dessinez les principales catégories de causes (comme les 6 M, ou les catégories de ce modèle : Système, Processus, Formulaires, Personnes, Politiques et Lieu) sous forme d'arêtes à partir de la colonne vertébrale. Réfléchissez aux causes possibles sous chaque catégorie, puis pour chacune continuez à demander « pourquoi ? » jusqu'à atteindre une cause profonde plutôt qu'un symptôme. Enfin, identifiez les causes profondes les plus probables et les plus impactantes, et transformez-les en actions. La valeur du diagramme réside dans le fait qu'il oblige l'équipe à examiner chaque catégorie au lieu de se fixer sur la première cause qui vient à l'esprit.
Qui a inventé le diagramme d'Ishikawa ?
Le diagramme porte le nom de Kaoru Ishikawa, un théoricien organisationnel japonais et pionnier de la gestion de la qualité, qui l'a développé et popularisé dans les années 1960 dans le cadre du mouvement de contrôle qualité. Il reste aujourd'hui un outil standard dans l'analyse des causes profondes, la fabrication et le travail d'amélioration continue.

Modèles associés

Rétrospective Doit Devrait Pourrait Ne Fera Pas

Priorisez les initiatives avec des critères de décision clairs pour de meilleurs résultats

Rétrospective de la Directive Première de Norm Kerth - Les Quatre Originales

Réfléchir sur la performance d'équipe avec empathie et perspicacité

Rétrospective du Taux d'Amélioration

Évaluez les progrès de l'équipe et identifiez les domaines de croissance accélérée.

Rétrospective Quoi ? Et alors ? Et maintenant ?

Un cadre de réflexion structuré pour l'analyse systématique des problèmes et la planification des actions