Blog de Bruno Orsier

Un article de Bruno Orsier    6 Commentaires

Dans Pragmatic Thinking and Learning: Refactor Your Wetware (vivement recommandé par Java In The Alps), l’auteur Andy Hunt décrit plusieurs biais cognitifs qui affectent nos processus de pensée. En gros, ces biais cognitifs sont les « bugs » dans nos manières de penser. Ces bugs ne viennent pas de notre éducation ou de notre formation, ils sont inhérents au « fonctionnement » de notre cerveau, et nous les avons tous à des degrés divers. Bien sûr éducation et formation peuvent y remédier, mais encore faut-il les connaître.

Si vous n’avez pas le livre, vous pouvez en trouver une liste impressionnante de biais cognitifs sur wikipedia pour vous faire une idée. L’étude des biais cognitifs est un sujet passionnant en soi (certains de ces « bugs » permettraient de décider plus rapidement dans des situations d’urgence – très important pour le chasseur de la préhistoire, d’autres sont liés à notre incapacité flagrante à manipuler correctement probabilités et incertitude), mais pourquoi s’y intéresser dans notre contexte d’informaticiens ?

Tout simplement parce que la connaissance des biais cognitifs permettrait aux équipes agiles (et à leurs facilitateurs et coachs) de s’améliorer plus efficacement. La capacité de pouvoir reconnaître un biais cognitif est un outil très précieux. En effet, une fois que vous avez reconnu un biais en action, vous pouvez abandonner les pensées du style « ce gars est un imbécile, il réfléchit n’importe comment, il n’y a rien à en tirer, etc. », et vous pouvez adopter une stratégie d’amélioration adaptée au biais en question.

Parmi les biais cités par Andy Hunt, j’ai souvent vu en action au travail le « Rarement ne veut pas dire Jamais« . Très souvent j’entends dire « il y a peu de chances que ce problème arrive » – avec en sous-entendu « ca ne vaut pas le coup de travailler dessus, ca n’arrivera jamais« . Evidemment le problème arrive toujours  un peu plus tard chez un client, il est bloquant pour ce client et il faut le résoudre en urgence… Je suppose que vous avez déjà rencontré de telles situations. La méthode empirique que j’ai adoptée pour contrer ce biais est de demander « combien de chances que le problème arrive ? » On me répond en général une chance sur 1,000, ou une chance sur 10,000. Alors je calcule le nombre d’utilisation par jour de l’algorithme ou du logiciel. Dans notre cas on arrive facilement à 100,000 par jour, réparties dans bon nombre de pays. Ca fait dans les 30,000,000 par an. A ce moment-là les chiffres parlent d’eux-mêmes, et le problème jugé improbable avec une chance sur 10,000 apparaît alors comme très probable. C’est donc une méthode qui consiste à informer correctement les gens sur les risques liés à leur travail. Cela a porté ses fruits car maintenant certaines équipes n’hésitent plus à faire des centaines de milliers de tests là où autrefois on se contentait de quelques centaines.

Dans le cadre des équipes Scrum, j’ai constaté également un autre biais qui s’appelle le « piège abscons« . Il est bien décrit dans le livre Petit traité de manipulation à l’usage des honnêtes gens. C’est un livre pour ceux qui veulent connaître les techniques de manipulation courantes (justement elles exploitent nos biais cognitifs) pour éviter d’en être les victimes, c’est pourquoi il est à l’intention des honnêtes gens. Le livre donne également des moyens de résister à la manipulation.

Voilà une bonne définition donnée sur un blog par une victime du piège abscons :

Le piège abscons s’observe chaque fois qu’un individu reste sur une stratégie ou une ligne de conduite dans laquelle il a préalablement investi (en argent, en temps, en énergie) et ceci au détriment d’autres stratégies ou lignes de conduites plus avantageuses. L’escalade d’engagements se caractérise plus spécifiquement par une série de décisions de plus en plus coûteuses dans un même cours d’action infructueux.

C’est bien sûr le piège dans lequel tombent les joueurs invétérés, qui espèrent toujours se refaire en misant une nouvelle fois, et qui ne peuvent pas s’arrêter. Ce piège peut même avoir des conséquences extrêmes, avec certains engagements militaires (les auteurs du petit traité mentionnent la guerre du Vietnam). Mais on l’observe aussi dans les équipes de développement, lors de la réalisation d’une histoire d’utilisateur. Les signaux d’alarmes sont du type « Il nous faut encore une demi-journée pour finir » (mais c’est la troisième fois qu’on annonce cette demi-journée, pour quelque chose qui avait été estimé à une journée). C’est légitime parfois, mais cela peut aussi être le signe d’un piège abscons : on s’est engagé dans une mauvaise direction, et l’on préfère s’obstiner plutôt que mettre à la poubelle ce qui a déjà été fait, et partir sur une autre direction. Autre signal d’alarme : le programme ne marche toujours pas comme prévu malgré de nombreux aller-retours entre développeurs et testeurs, et l’on nous annonce pour la nième fois « il manque juste un petit quelque chose« …

Heureusement Scrum contient un outil redoutable pour lutter contre le piège abscons : le « time-boxing », à savoir les activités en temps limité. Dans le cas d’une histoire utilisateur qui dérive, il suffit de se mettre d’accord avec l’équipe sur la durée maximale à partir de laquelle on repartira de zéro. J’ai pu constater plusieurs fois que cela fonctionne parfaitement. Et ce n’est pas par hasard. En effet le petit traité identifie deux facteurs qui permettent au piège abscons de se développer :

1. l’individu peut être engagé dans un processus qui se poursuivra de lui-même, jusqu’à ce qu’il décide activement de l’interrompre, si toutefois il le décide
2. l’individu peut être amené à ne pas fixer a priori de limites à ses investissements, par exemple à décider une fois pour toutes quelle somme il souhaite engager dans un jeu, ou combien de temps il attendra à l’arrêt de bus, etc.

Le time-boxing de Scrum  attaque les deux facteurs, grâce à la décision active de l’équipe, et grâce à la limite du temps maximal.

Bon, si vous ne retenez qu’une chose de ce billet : vous pouvez aller jouer au casino sans vous ruiner si vous décidez à l’avance de votre dépense maximale. Toutefois, comme notre cerveau ne comprend pas bien les probabilités, rappelez-vous tout de même que c’est toujours le casino qui gagne !

Et vous, quels biais cognitifs avez-vous constatés au travail ?

PS : ce piège abscons a bien été illustré par Emmanuel Chenu, qui nous propose ce cartoon :