Dans la catégorie “outils du coach” pour la résolution de problèmes, vous connaissez peut-être les “5 pourquoi” afin d’aller détecter la cause racine d’un problème plutôt que d’en rester au symptôme.

Dans cet article je vais essayer de montrer en quoi cette technique est plus efficace que la technique des “1 pourquoi” mais moins que les diagrammes de boucles causales pour résoudre les problèmes complexes.

Je vais partir d’un exemple avec un Scrum Master qui vient me voir parce que son daily meeting est inefficace : un problème simple au premier abord et bien connu dans la communauté agile.

Le symptôme du problème, la face visible de l’iceberg que je vous propose pour la démonstration : les développeurs font du reporting au PO et c’est inintéressant pour tout le monde, même le PO.

Nous allons donc voir 3 techniques pour résoudre ce problème a priori simple : les “1 pourquoi”, les “5 pourquoi”, les diagrammes de boucles causales.

Technique des “1 pourquoi”

L’analyse du problème

Pourquoi le daily meeting est inefficace ?

Dans la vraie vie, il peut y avoir plein de raisons. Faisons l’hypothèse que le Scrum Master réponde : “parce que les développeurs font du reporting au PO donc il n’y a pas de collaboration possible entre équipiers pour prendre des décisions.”

LA solution pour le Scrum Master

Exclure le PO du daily meeting pour que les développeurs puissent parler librement et que le daily meeting soit utile pour eux.

Lunette systémique

Le daily meeting inefficace est un symptôme d’un problème de fond de manque de confiance entre le PO et les développeurs. Exclure le PO est un traitement du symptôme qui ne règle pas le problème de fond.

Pire, il l’empire : sans le daily meeting, la confiance entre le PO et les développeurs va baisser.

On retrouve un archétype systémique notamment décrit par Peter Senge dans la “5ème Discipline”, le remède anti-symptôme (ou en anglais “fixes that fail”) que nous pouvons illustrer à l’aide d’un diagramme de boucles causales.

Partons du problème central de “Daily = Reporting au PO”.

A la lecture de ce diagramme, il y a effectivement 2 solutions possibles à notre problème central :

• le remède anti-symptôme en haut, le “Daily sans PO”, est facile à mettre en oeuvre et avec un résultat immédiat : régulation du problème avec le lien de causalité négatif, le signe ‘-‘
• la solution de fond en bas, la “Confiance PO/Dev”, régule le problème de la même façon (signe ‘-‘) mais est plus difficile à mettre en oeuvre et avec un effet retard sur l’efficacité du daily meeting (symbole “pause”) : la confiance ne se gagne pas en 1 jour !

L’effet pervers de ce remède anti-symptôme, c’est qu’il diminue la transparence entre développeurs et PO (le lien de causalité négatif à droite) et sur le long terme, il détériore encore plus la confiance qui est déjà notre vrai problème de fond !

Regagner la confiance sera d’autant plus difficile et long. Et pourtant c’est tentant voire logique pour le Scrum Master de privilégier la solution court-terme et facile, car ça peut lui permettre rapidement d’animer des daily meetings intéressants pour les développeurs.

Voyons maintenant ce qu’apporte la technique des 5 pourquoi, en gardant nos lunettes systémiques.

Technique des “5 pourquoi”

L’analyse du problème

Pourquoi le daily meeting est inefficace ?

Parce que les développeurs font du reporting au PO donc il n’y a pas de collaboration possible entre équipiers pour prendre des décisions.

Pourquoi c’est du reporting ?

Parce que les développeurs n’osent pas dire les choses au PO, ils ne sont pas transparents.

Pourquoi ils ne sont pas transparents ?

Parce qu’il y a un manque de confiance entre le PO et l’équipe

LA solution pour le Scrum Master

Travailler sur la confiance entre le PO et l’équipe qui semble être la cause racine du problème de daily meeting inefficace.

Il va non seulement ne pas se faire piéger par le symptôme et la solution court-terme et continuer à inviter le PO aux daily meetings, mais en plus va prévoir des temps de collaboration réguliers entre PO et développeurs pour traiter le problème de fond de confiance.

Lunette systémique

Cette recherche de solution est plus systémique que la précédente dans le sens où elle ne s’arrête pas à la première cause du problème. Elle va chercher plus loin une cause racine qui a in fine comme impact systémique un daily meeting inefficace. La solution semble être bien plus pertinente que la première solution qui restait au symptôme et à la façade.

Mais cette analyse du problème ne prend pas en compte la complexité et le processus dynamique du système. Elle décrit des liens de causalité univoques entre des éléments du système, dans une logique de causalité linéaire chère à Descartes : une cause provoque un effet.

Dans notre cas : le manque de confiance provoque un manque de transparence qui provoque du reporting pendant le daily meeting.

Cela fonctionne très bien pour des problèmes simples, pas vraiment pour des problèmes complexes avec beaucoup de variables et d’interactions entre elles.

Vous noterez qu’il n’y a que 3 pourquoi dans mon exemple, mais conviendrez peut-être par la suite qu’il pourrait y en avoir 10 que ça ne changerait pas le problème, au contraire comme dirait Paul Watzlawick : “Toujours plus de la même chose provoque toujours plus du même résultat” 🙂

La lunette systémique nous propose de voir les choses différemment, et notamment en utilisant un outil plus systémique : le diagramme de boucles causales.

Diagramme de boucles causales

Voir des boucles : la pensée circulaire

Dans l’approche systémique, les liens de causalité ne sont plus univoques, une chose est cause et effet en même temps, et réciproquement 🙂

L’idée même de cause “racine” est un non-sens : il existerait un bout aux problèmes, une racine et puis en-dessous plus rien.

Les éléments d’un système interagissent dynamiquement.

L’efficacité du daily meeting est une conséquence de la confiance entre PO et développeurs, mais également une cause : si le daily est efficace, les choses se disent et la confiance grandit. Inversement, si le daily est inefficace et que les développeurs font du reporting au PO, les problèmes sont cachés et la confiance diminue.

Le problème est la solution

Dans l’approche systémique, problèmes et solutions se confondent : les problèmes locaux sont les solutions pour l’ensemble du système et lui permettent de rester en vie. En effet, tout système vivant comme une organisation ou un individu a pour but de maintenir un état d’équilibre qui lui permet de rester en vie. Quand le corps humain monte en température pour se débarrasser d’un virus, le problème de la fièvre est une solution pour rester en vie. Quand un problème dans une organisation ne la détruit pas dans la seconde, il peut également être vu comme une solution pour maintenir le système global dans son état d’équilibre.

Dans notre cas, la lunette systémique nous propose donc de voir le manque de confiance entre le PO et les développeurs comme une solution pour l’ensemble du système, et nous amène à nous poser les questions suivantes :

• En quoi le manque de confiance entre le PO et les développeurs est une solution pour quelqu’un, quelque part dans le système ?
• Quels avantages à ne pas se faire confiance et ne pas collaborer ?

Par exemple, si ça se passe mal, on peut dire que c’est de la faute de l’autre : “le PO n’a pas bien expliqué ce qu’il fallait faire, les spécifications sont de mauvaise qualité, les critères d’acceptation n’étaient pas disponibles à temps” ou bien de l’autre côté, “les développeurs sont encore en retard, l’IT est mal organisé, les machines de test sont trop lentes”.

Si ça se passe mal, on peut aussi identifier un tiers comme responsable du problème : “on n’a pas les données de telle équipe à temps” ou “l’infra ne nous donne pas assez de machines de test”, etc…

Dans ces deux cas, le manque de confiance permet de trouver un coupable en cas de problème et a une vertu énorme : ne pas avoir à assumer ses erreurs, se déresponsabiliser.

Essayons de modéliser ce système et sa dynamique avec un diagramme de boucles causales un peu plus complet.

Boucle amplificatrice du problème

Il est important de noter ici comment se lisent les signes d’un diagramme.

Un signe “+” signifie que les 2 variables évoluent dans le même sens (un “-” dans le sens inverse) :

• si la confiance augmente, la transparence augmente et le daily est plus efficace… et la confiance augmente
• si la confiance diminue, la transparence diminue et le daily est moins efficace… et la confiance diminue

Travailler sur la cause racine

Le problème est la solution

Avec la lunette systémique, le manque de collaboration peut être vu comme une solution pour chacune des parties qui peut trouver des moyens de ne pas assumer ses erreurs en cherchant un coupable.

La solution est le problème

Avec la lunette systémique, l’amélioration de la collaboration est aussi un problème car chacun doit assumer ses erreurs, et ça fait peur.

La solution peut même devenir un gros problème…

Dans un certain nombre d’organisations, il y a un système de primes individuelles liées aux résultats sur des projets. S’il y a des problèmes sur ces projets et pas de moyen de se déresponsabiliser, les primes disparaissent et notre solution d’amélioration de la collaboration devient un problème encore plus gros…

Risque d’homéostasie du système

L’homéostasie correspond à la capacité d’un système à maintenir l’équilibre de son milieu intérieur, quelles que soient les contraintes externes.

Dans le cas présenté, la solution imaginée par le Scrum Master avec la technique des 5 pourquoi risque de provoquer des réactions homéostatiques du système.

Le système est fait de déresponsabilisation, de recherche du coupable et de primes individuelles. Il est dans un certain état d’équilibre et va tout faire pour y rester.

Le Scrum Master amène une contrainte externe en proposant plus de temps de collaboration dans l’équipe et met en danger l’équilibre du système.

Ce dernier va tout faire pour ne pas changer :

• par exemple certains vont tout faire pour ne pas collaborer en ayant toujours une réunion plus prioritaire que ces temps de collaboration en équipe,
• par exemple certains seront systématiquement en retard aux réunions.

Inconsciemment les personnes vont tout faire pour ne pas améliorer la confiance car ça leur permet de taper sur quelqu’un quand ça se passe mal ou parce que ça leur permet d’avoir une bonne prime en fin d’année.

Alors c’est quoi la solution ?

Comme il n’y a pas de cause racine, il n’y a pas non plus de solution, en tout cas pas LA solution.

Il n’y a que des tentatives pour faire bouger le système et sa dynamique, en essayant de trouver le levier qui va permettre au système de se transformer, de changer d’équilibre.

Avec une représentation systémique et un diagramme de boucles causales, on visualise une partie de la complexité du système et on perçoit les effets négatifs des solutions comme les effets positifs des problèmes.

On reconnaît la valeur d’une confiance au plus bas dans l’équipe, comme le problème de la bonne collaboration.

Travailler sur le droit à l’erreur

Dans notre cas, voir ce système peut permettre au Scrum Master de travailler non plus sur le daily meeting ou la confiance entre PO et développeurs, mais sur le droit à l’erreur.

Si commettre des erreurs ou se tromper ne fait plus peur, ne plus avoir personne sur qui taper en cas de problème ne pose plus de problème.

Changer le système de primes

Autre option : faire évoluer le système de primes individuelles pour qu’il n’incite plus les gens à se déresponsabiliser. Si les erreurs ne diminuent pas les primes, faire des erreurs ne pose plus de problème financier.

Pourquoi ne pas tenter de lier les primes à la collaboration ?

Bien sûr cette option est une montagne à gravir pour quiconque accompagne cette équipe : le Scrum Master ou le coach n’ont probablement ni le mandat ni la légitimité pour aller voir les RH et réfléchir à un autre système de primes. Ça peut être décourageant et frustrant si on est toujours à la recherche de LA solution.

Mais la valeur de l’exercice est pour moi avant tout dans la prise de conscience du problème et son objectivation pour être capable de le partager aux autres.

Le premier petit pas pourrait alors être de partager cette représentation du système ou mieux encore de le co-construire avec les parties prenantes.

Objectiver le problème et le communiquer, il est peut-être tout simplement là l’effet levier.

Conclusion

Ce cas montre qu’un problème simple au premier abord peut s’avérer très complexe à régler.

Un problème de daily meeting inefficace, dans certains cas, peut être résolu par un coaching de Scrum Master pour “bien faire le daily meeting Scrum” et éviter le reporting classique.

Dans d’autres cas, l’utilisation de la technique des 5 pourquoi permet de mieux comprendre les problèmes pour agir sur une cause plus profonde plutôt que réagir à un symptôme. Dans beaucoup de cas, c’est suffisant et la technique fonctionne très bien.

Pour autant, parfois ça ne sera pas suffisant. Si le problème perdure ou empire malgré les tentatives de solutions, comme ici la difficulté du Scrum Master à installer des daily meetings efficaces et appréciés, c’est sans doute qu’on est face à un problème complexe et circulaire, avec des phénomènes homéostatiques qui empêchent le changement.

C’est le signe qu’il faut chausser ses lunettes systémiques et utiliser un diagramme de boucles causales pour voir la complexité et agir ailleurs, ici par exemple sur la culture du droit à l’erreur ou le système de primes.

C’est un outil plus puissant que les 5 pourquoi mais pas magique. Il nous invite à voir complexe et à penser complexe : procéder par petits pas en expérimentant des choses pour voir comment le système réagit et mieux comprendre où agir. Il n’y aura pas de solution facile et rapide qui marche du premier coup mais une multitude de possibilités d’expérimentations pour agir sur le système.

Qui a parlé d’agilité ? 🙂

Pour en savoir plus et pratiquer, venez le 9 avril chez Goood! à 19h30 pour le meetup “Entreprise et managers agiles #24 Systémie – Utiliser le diagramme de boucles causales”

Et n’oubliez pas le groupe “Kata de représentations systémiques” qui est fait pour s’exercer à voir et penser complexe : il y aura de nouvelles rencontres très bientôt !