Cela fait plusieurs années que je suis intéressé par la zététique. Cette pratique, qui littéralement veut dire l' »Art du doute », vise à comprendre notre environnement en se basant principalement sur la méthode scientifique. Le corolaire de cela est qu’elle s’intéresse également à la façon avec laquelle des choses rentre dans notre cerveau.

Il en aura fallu du temps pour que je fasse un lien entre la méthode scientifique et le développement des personnes promu par la pratique du Lean Management. Et pourtant, à force d’accompagnement, de mesures et d’apprentissage, le lien entre les deux m’apparait aujourd’hui comme une évidence. C’est la raison pour laquelle j’ai décidé d’en parler lors d’une conférence à l’Agile Tour Bordeaux. Ce billet de blog est le résumé de la conférence que vous pouvez trouver ici :

Le bon sens

L’un des premier point que nous apprend la zététique, c’est à se méfier du bon sens. Le bon sens veut faire apparaître des évidences qui cachent le plus souvent des complexités insoupçonnées derrière chaque problème et chaque décision. Le bon sens est un raccourci qui nous empêche d’apprendre vraiment d’une situation. Et il est dangereux du fait qu’on n’a souvent pas idée de l’ampleur de ce qu’on ignore (Voir l’effet Dunning Kruger).

Dans mon travail, je suis souvent confronté à ce bon sens. Les phrases comme « ça ira plus vite si on lance plusieurs développements en même temps plutôt que les uns après les autres », « si chaque personne est spécialisée dans un domaine, on gagnera du temps », « le pair-programing c’est bien, mais ça coute deux fois plus cher », « les tests unitaires aussi c’est bien, mais pendant ce temps, ils ne développent pas de features », « les standup ok, mais deux par semaine devraient suffire, c’est développer qui fait gagner de l’argent, pas discuter pendant 15 minutes… ».

Toutes ces phrases sont chargées de bon sens, mais la réalité n’est-elle pas plus complexe ? Oui, le pair-programing, c’est payer deux personnes sur un seul développement. Mais quel quid de la propriété collective du code ? De la qualité ? Du gain de temps à long terme ? Oui, parce qu’un développeur passe plus de temps à réfléchir avec son cerveau qu’à taper sur le clavier. Deux cerveaux accélèreront donc plus un développement que le fait d’accélérer la frappe sur le clavier. Je n’ai d’ailleurs encore jamais vu d’entreprise offrir à leurs ingénieurs des formations dactylo pour développer plus vite.

Quand on souhaite apprendre, être humble face à ses croyances est un prérequis. Il est nécessaire d’être convaincu qu’on ne sait rien et qu’il nous faut explorer et expérimenter pour apprendre.

Le méthode scientifique

C’est très exactement pour faire face à ce genre de préjugés et de croyances que la méthode scientifique a été imaginée. Pour faire voler en éclat toutes ces idées préconçues de « bon sens ».

Pour résumer la méthode scientifique en quelques ligne, on peut dire que celle-ci commence par la formulation d’une théorie. Grâce à cette théorie, nous allons imaginer une prédiction en imaginant ce qui devrait se passer dans des conditions définies si la théorie est vraie. Ensuite, nous imaginerons une expérience à réaliser dans le but de tester cette prédiction. Il nous suffira alors d’observer le résultat de l’expérience afin d’accepter de modifier ou de rejeter la théorie.

Je ne sais pas si vous voyez venir la chose, mais faisons le parallèle avec le PDCA. Le PDCA est l’outil utilisé par les équipes pour résoudre leurs problèmes au quotidien. Il débute par l’observation d’un problème. en Lean, un problème est définit comme une mesure (un chiffre) représentant un écart de performance du point de vue du client (cf. cet article) :

Le PDCA se déroule donc en 4 phases (Plan, Do Check, Act) :

• Plan (Théorie et prédiction) : Le plan est le moment ou l’équipe va élaborer sa théorie autour du problème qu’elle vient de rencontrer. Pour se faire, elle va essayer de le comprendre et d’en déterminer la (ou les) cause(s) racine(s), dans le but de trouver une expérimentation pouvant corriger ce problème. Cette expérimentation sera accompagnée d’une prédiction. Ces étapes peuvent paraître un peu lourdes et sont souvent négligées par les équipes. Mais pourtant, ce sont elles qui permettent aux équipes d’approfondir réellement leurs connaissances de leurs processus de production. L’expérimentation et la prédiction sont les seuls à pouvoir mener à un apprentissage fiable. C’est d’ailleurs le principe que la science utilise depuis plusieurs siècles.
• Do : C’est la pratique. L’expérimentation en question va être mise en place par l’équipe.
• Check : Le moment de la mesure est arrivé. Après avoir expérimenté, on va observer le résultat. On prend la mesure et on la compare à la prédiction. C’est qu’a partir de là que l’équipe va pouvoir valider ou non sa théorie.
• Act : C’est le moment ou on apprend. Que le check soit positif ou négatif, l’équipe a quoi qu’il en soit appris des choses sur sa théorie. Si la prédiction est vérifiée, la théorie sera acceptée et les pratiques de l’équipe seront mise à jour en conséquence. Si la prédiction n’est pas du tout vérifiée, elle aura appris à l’équipe que ce qu’elle a expérimenté n’est pas une bonne façon de faire (elle a donc appris quelque chose). Un autre PDCA pourra être lancé avec une autre théorie. Si le check n’atteint pas la prédiction imaginée, un autre PDCA peut-être lancé afin de continuer à apprendre de ce problème en ajustant la théorie.

Comme je le disais, la science et le PDCA semblent très complexe. Mais il est extrêmement important de respecter chacune des étapes car ce sont elles qui nous garantissent de ne pas nous faire avoir par notre « bon sens » dont j’ai parlé au dessus. Sans cela, nos pratiques seront composées d’un ensemble de théories non vérifiées. Et vous savez le problème avec les théories ? C’est que tout le monde en a une. Si on ne prend pas la peine de les vérifier, elles seront considérées comme vraie sans preuve. Et croyez moi, tout le monde a une théorie sur tout, à l’image de cette étude parue en mars 2020, à une époque ou aucun étude n’avaient été menées sur un traitement, 79% des français avaient une théorie sur la question de son efficacité :

No coment !

Pour illustrer ce point, j’aborde un sujet épineux. Etant en période de pandémie, beaucoup de questions sur les masques ont fleuries sur les réseaux sociaux. Parmi elles, une affirmation comme quoi les masques ne peuvent pas bloquer le virus car leurs mailles sont trop grandes pour le virus. En vérifiant, il est vrai que le virus est estimé à 100nm et les mailles du masque à 3000nm, on peut légitimement se dire qu’en effet, c’est du « bon sens » de penser cela. Sauf que, sachant qu’une molécule d’eau mesure 0.34nm (300 fois plus petite que le virus), la prédiction pourrait être que mettre un masque sous un filet d’eau ne dévirait pas du tout le filé d’eau. L’expérimentation montre que non. La prédiction n’est pas vérifiée, la théorie n’est pas bonne. La chose à apprendre semble plus complexe et nécessite de creuser. Rester bloquer sur sa première opinion basée sur le « bon sens » n’apprend rien et nous maintient dans une idée fausse. Challenger sa croyance avec une expérimentation simple et rapide permet de la bousculer et de révéler les éléments réels à apprendre.

C’est donc bien pour cette raison qu’il faut se protéger des avis sans fondement, des théories fumeuses et du « bon sens ». La méthode scientifique est l’arme ultime pour cela (qui est valable également dans la vie de tous les jours). La mesure est ce qui doit guider nos actions d’amélioration. C’est pour cela que les KPI doivent être mis en place. Ils se doivent d’ailleurs impérativement d’avoir du sens pour le client, car c’est cela que nous cherchons à améliorer (cf. les bons et les mauvais KPI). C’est grâce à cette démarche partant d’un problème chiffré ayant du sens pour le client que nous arriverons à générer de vraies améliorations (cf. rétrospectives vs amélioration continue).

Nos sens

Si notre intuition, nos avis et notre « bon sens » sont si dangereux dans notre démarche d’amélioration, ils ne sont malheureusement pas les seul. Nos sens nous trompent également. Je ne parlerais pas ici de biais cognitifs, j’ai prévu d’aborder le sujet dans un futur article. Cependant, je souhaiterais en aborder deux ici : le biais d’ancrage et le biais de confirmation. Ces deux biais sont, pour moi, ceux qui nous empêchent le plus d’avoir un avis éclairé nous permettant les meilleures prises de décision.

Le biais d’ancrage est un biais de jugement qui pousse chacun de nous à se fier à la première information reçue, ou a son premier avis lors d’une prise de décision. Le biais de confirmation, est lui aussi un biais cognitif qui consiste à privilégier les informations confirmant ses idées et ses opinions déjà établies et donc à accorder moins de poids informations jouant en défaveur de ses conceptions, ce qui se traduit par une réticence à changer d’avis.

Ce qui est rassurant, c’est que des études ont été menées et ont expliqué que cela était physiologiquement mesurée. Assez rassurant pour nous dire qu’on est finalement normal. Mais pas rassurant pour mener à bien notre démarche d’amélioration continue, qui n’est au fond, rien d’autre qu’une démarche favorisant les changements d’avis sur nos pratiques de production.