NewCrafts Paris 2023 ~ Laurent Bossavit
Les 25 et 26 mai, j'ai assisté à la conférence NewCrafts Paris 2023. C'était chouette de revoir plein de monde au même endroit ! Il y avait aussi des interventions de qualité, voilà une partie de mes notes sur ce que j'ai appris ou révisé.
Ce sont des notes très partielles, à mon usage personnel. Je vous invite à voir les vidéos des conférences qui vous intéressent quand elles seront publiées (le mois prochain normalement).
Dans ce deuxième article, mes notes sur la présentation de Laurent Bossavit.
Dans les articles suivants, j'ai prévu de partager mes notes sur les interventions de :
Laurent Bossavit
Laurent Bossavit est l'auteur du livre The Leprechauns of Software Engineering (How folklore turns into fact and what to do about it), et expert des démarches agiles de conduite de projets numériques et de développement logiciel. Ancien coach à Beta.gouv, il a contribué aux premières heures des start-up d'État.
L'intervention de Laurent interrogeait la notion de "feedback", un mot beaucoup employé dans ce que j'observe autour de moi en entreprise.
Il a rappelé qu'on trouvera beaucoup d'éléments sur ce sujet dans le livre What did you Say?, The Art of Giving and Receiving Feedback de Jerry Weinberg.
Laurent a aussi fait parler des marionnettes qui représentaient la peur, le morse, le chacal et la girafe. C'était intéressant je trouve, car ça nous permet de les identifier comme des personnages et d'incarner leur discours.
Voilà quelques points dont j'ai eu envie de me souvenir.
Le retour du (mauvais) feedback
Tout d'abord, le fait que quand quelqu'un s'investit de la charge de nous transmettre le feedback de quelqu'un d'autre, il y a des chances que ce soit une très mauvaise idée. C'est un bel antipattern, à éviter.
Aussi, quand je donne un feedback, je parle de moi. C'est aussi vrai quand une personne me donne un feedback : elle me parle d'elle-même.
Feedback is always information about the person giving it. Feedback is an I
sentence.
Pour qu'une relation constitue un feedback, elle doit former une boucle. On ne peut pas se contenter d'une communication unidirectionnelle.
Il est donc important qu'un feedback constitue une conversation au cours de laquelle les deux parties puissent poser des questions, comme :
What do you mean when you say ‘…’ ?
Si je ne suis pas prêt à ce que comme résultat de mon feedback, la personne me réponde : "Merci pour ton feedback, je le prends comme un cadeau et je ne vais pas en tenir compte", alors c'est que je ne suis pas en train de donner un feedback. Je suis en train de formuler une demande. Il est important de ne pas déguiser une demande en un feedback, ce serait une forme de manipulation.
Dans ce cas, au lieu de dire "J'ai un feedback pour toi", préférer faire un effort : est-ce que j'ai une suggestion, est-ce que j'ai une demande ?
Le (mauvais) feedback est-il indispensable pour manager ?
“feedback is indispensable for management” makes me cringe.
Un feedback n'est pas non plus une note, ni des étoiles sur cinq. On n'est plus à l'école.
À nouveau : le feedback est une phrase en "Je".
Laurent observe aussi que les outils de feedback de la CNV, comme "OSCAR", "DESC", "OSBD" sont de bons outils. Mais quand ils sont appliqués sans l'intention initiale, ils perdent toute leur utilité. Comme par exemple le format possible de rédaction d'une User Story : "As a... I want ... So that..." 👉️ "En tant que PO, Je veux que tu réalise ce ticket, Afin d'effectuer les Story Points" 🤦
Comme on l'a vu, de drôles de formes de "feedback" sont un problème. Ces formes ne sont pas un bon outil de management. Autre exemple qui pose problème : le retour du shit sandwich (idée étrange selon laquelle on fait un "feedback positif", suivi d'un "feedback négatif", puis d'un nouveau "feedback positif" = meilleure façon de ne pas être clair du tout).
The shit sandwich comes back in style. Yuck.
De qui est-ce que je prends soin ?
Extreme Programming était un changement social, les mouvements agiles étaient une libération. Ce n'étaient pas des outils d'oppression.
Quand je fais un feedback, je peux mettre mes oreilles de girafe et me poser la question : quel est l'intention de mon feedback ? De qui est-ce que je prends soin ? De moi ? De l'autre personne ? De la relation entre moi et l'autre personne ?
Feedback changes the relationship more that the other person’s behavior.
Très souvent on commence par se concentrer sur le problème trop tôt et ça dégrade la relation. On ferait mieux de se concentrer sur la relation en premier.
Feedback et systèmes
On peut voir la relation elle-même comme la boucle de feedback. Ce qui importe ce n'est pas les choses mais les relations entre les choses.
Dans la pensée systémique, le feedback est une boucle. Avec un seul élement il n'y a pas de feedback. Avec deux élements, il n'y a pas de feedback. Avec deux élément et une flèche unidirectionnelle il n'y a pas de feedback. Il commence à y avoir une boucle de feedback seulement quand il y a deux éléments et une flèche entre eux dans chaque sens.
On peut représenter ces boucles de feedback et y réfléchir avec des Causal loop Diagrams.
Quand on étudie un système, se poser la question de savoir si c'est un système stable est intéressant.
Ajouter un effet retard dans un système le rend d'autant plus difficile à contrôler. La peur introduit du retard. La peur fait aussi que le système reste coincé dans ma tête, avec des conversations imaginaires (qui ont souvent lieu pendant la nuit).
Conclusion
Votre peur du (mauvais) feedback est une bonne chose.
Préférez les feedback loops aux "feedbacks".
Quand une fleur ne pousse pas, on regarde son environnement, pas la fleur.