Système

Quels outils, logiciels ou technologies pourraient affecter la performance ou les résultats de notre équipe ?

Notre pipeline de déploiement plante souvent aux heures de pointe
L'environnement de test ne correspond pas à la configuration de production
L'intégration entre notre outil de suivi des tâches et Git n'est pas fiable
Processus

Quels flux de travail ou enchaînements d'activités ralentissent ou compliquent notre travail ?

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

Quels problèmes liés à nos modèles ou à notre documentation pourraient nuire à la clarté ou à l'exactitude ?

Le modèle de user story n'a pas de section pour les critères d'acceptation
Le formulaire de rapport d'incident ne permet pas vraiment d'identifier la cause racine
La documentation est éparpillée sur plusieurs plateformes
Personnes

Quels facteurs liés aux compétences, à la communication ou aux rôles influent sur notre réussite ?

L'équipe manque d'expertise sur la nouvelle stack technique
Des lacunes de communication entre les membres à distance et ceux au bureau
Rôles et responsabilités flous dans les projets transverses
Règles

Quelles règles ou directives pourraient être en décalage avec nos pratiques réelles ou nous poser des difficultés ?

Les politiques de sécurité compliquent le développement en local
La gestion des changements 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, pourraient nuire à notre collaboration ou à notre productivité ?

Connexion internet médiocre sur les lieux de télétravail
Manque d'espaces calmes pour le travail concentré
Les outils de collaboration virtuelle ne répondent pas bien à nos besoins

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

Foire aux questions

Quels sont les 6 M du diagramme en arêtes de poisson ?
Ce sont les catégories de causes classiques du diagramme d'Ishikawa dans l'industrie et la gestion de la qualité : Main-d'œuvre (les personnes), Méthode (le processus), Machine (l'équipement et les outils), Matière (les intrants), Mesure (les données et indicateurs) et Milieu (l'environnement). Chaque M devient une arête partant de la colonne vertébrale, et l'équipe recense les causes sous chacune d'elles. Ce modèle adapte cette idée aux équipes logicielles et aux métiers du savoir avec Système, Processus, Formulaires, Personnes, Règles et Lieu.
Quelle est la différence entre un diagramme en arêtes de poisson et un diagramme d'Ishikawa ?
Il n'y en a aucune. Diagramme en arêtes de poisson, diagramme d'Ishikawa et diagramme de causes et effets sont trois noms pour le même outil. « Arêtes de poisson » vient de sa forme, et « Ishikawa » de Kaoru Ishikawa, l'expert japonais du contrôle qualité qui l'a popularisé dans les années 1960.
Comment faire une analyse des causes racines avec un diagramme d'Ishikawa ?
Écrivez le problème à la tête du poisson et dessinez les catégories de causes comme des arêtes partant de la colonne vertébrale. Recensez les causes sous chacune d'elles, puis continuez à demander « pourquoi ? » jusqu'à atteindre une cause racine plutôt qu'un symptôme. Retenez les causes racines les plus probables et celles qui ont le plus d'impact, puis transformez-les en actions.
Qui a inventé le diagramme d'Ishikawa ?
Il porte le nom de Kaoru Ishikawa, théoricien japonais des organisations et pionnier de la gestion de la qualité, qui l'a popularisé dans les années 1960. Il reste un outil de référence pour l'analyse des causes racines et la qualité en milieu industriel.
Êtes-vous prêt à mener cette rétrospective ?Essayez ce concert rétrospectif