Raconte-moi une histoire

Quand j’accompagnais des transformations agiles, je me retrouvais souvent à raconter des histoires, des petites ou des grandes, sans faire particulièrement attention, naturellement. Puis je me suis rendu compte que je piochais de plus en plus dans une espèce de corpus, plus ou moins mythique, souvent partagé, et adaptant le discours à la personne en face de moi. J’ai commencé à faire très attention : mythes et mensonges sont bien proches parfois, à l’équilibre entre la vérité et le réconfort de la culture. La claque a été encore plus forte quand j’ai rencontré d’autres coachs agiles, ou lu des livres promouvant l’agilité, qui racontaient des histoires pour le coup complètement différentes. Comme un missionnaire jésuite tombant sur un prédicateur taoïste qui porterait la même parole que lui. A partir de là, j’ai eu envie d’éclaircir la relation entre le coach et le conteur en moi. Avec cette conclusion : un retour d’expérience est une réécriture de l’histoire, qui va alors participer à la construction de l’identité de l’organisation.

Raconter des histoires est le propre de l’humain

Je ne pense pas être le dernier à rappeler comment les humains aiment raconter des histoires. Que ce soit l’histoire officielle, avec souvent un grand H : celle des ancêtres, qu’on raconte en veillées, à la télévision, sur les réseaux sociaux mais aussi dans les églises voire dans nos temples modernes que sont les mairies, les écoles ou les parlements ; il y a l’histoire qui nous détend, dans notre société de consommation et de loisirs : romans, films, séries, jeux vidéo ; il y l’histoire que les enfants nous demandent de raconter avant de se coucher, contes ou fables, dans cette espèce de dépendance gagnant-gagnant. Et puis, Il y a l’histoire qu’on construit quand on raconte un rêve, comme, finalement, les histoires qu’on se raconte à soi, puis aux autres, pour mettre en scène ses propres expériences. Le monde professionnel n’échappe pas à cet attrait pour la narration. Personnellement, en dehors des temps où je résous des problèmes (écriture de code, réunion de conception...), j’alterne souvent entre des moments où je raconte des histoires à moi-même et d’autres moments où je raconte des histoires aux autres. Je pense notamment à quand je présente des faits, des résultats, des comptes (à mes chef·fes ou à mes client·es), où quand je coache (en tant que manager, avec mes pairs, avec mon chef, avec ma cliente). C’est d’autant plus vrai quand on est consultant·e en organisation ou coach agile, et qu’on parle à des managers et à leur manager. Il faut  raconter une histoire à ces personnes, car on est finalement rarement à leur poste, en train de faire avec elles. Plus précisément, à travers ma grille de lecture personnelle très XXIè siècle occidental, je vois deux fonctions aux récits. La première fonction des récits serait sociale, car cela permet de partager des références communes, et, mieux, des valeurs communes. Cela permet aussi de les transmettre en bloc, parfois sans avoir à les déconstruire, et donc sans risquer de dévoiler des mécanismes pas forcément très justes. La seconde fonction, individuelle, psychologique, qui a aussi trait à la mémoire, permet (dans l’ordre) de classer, réordonner, hiérarchiser, pour finalement filtrer les expériences personnelles, afin que mes actions coïncident avec ma propre identité : faire en sorte que le moi qui suis soit bien le moi qui ai fait. Je me raconte ce que je suis, et ça me permet de me lever le matin. (Il paraît que la moitié de notre cerveau cherche à transformer en récits nos expériences vécue par l’autre moitié. Et j’ai l’intuition qu’il aime que ce récit soit comme un bon roman initiatique, découpé en plusieurs scènes, claires, faisant sens.) Mais avant de voir plus ce qu’on va pouvoir faire de toutes ces histoires, je voudrais vous en raconter quelques unes justement. Voici donc pour quelques fables sur l’agilité :

La fable du middle manager et de l’agilité

(texte original : La fable du middle manager et de l’agilité)

Il était une fois un manager qui encadrait des développeurs et des développeuses. Dans son entreprise, c’était un peu la chaos suite à une croissance rapide. Des chef·fes de projets fonctionnel·les écrivaient des spécifications fonctionnelles en fonction de ce que leur racontaient les équipes métier ; les managers des dev se distribuaient entre eux ces spécifications, puis chacun et chacune essayait d’assigner les tâches à ses développeurs et à ses développeuses en fonction de ses propres estimations. Après, chaque mois, on essayait de packager ces projets ensembles, pour sortir une nouvelle version du site, et toujours avec quinze jours de retard, parce que ce n’est pas simple à synchroniser tout ça. Dans ce contexte, les équipes métiers et les équipes techniques ne se voyaient jamais, bien que travaillant les unes juste au dessus des autres. Un jour, ce manager a rencontré une autre manager d’une autre entreprise, qui lui raconta comment cette entreprise essayait de mettre en place Scrum. Ce fut une révélation. Un an après, toutes les équipes avaient été réorganisées en feature teams, chacune avec leur PO, leur PO adjoint, leur scrum master (éventuellement tournant). Les développeurs et les développeuses s’appropriaient leur feature, et ceux ou celles qui ne voulaient pas travailler en équipe, refusaient le management visuel ou la relecture de code avaient même donné leur démission ! Chaque équipe avait sa propre Definition of Done. Chaque équipe connaissait sa valeur, ses KPI. Des démos étaient faites tous les quinze jours à l’ensemble des équipes métier concernées par les évolutions. On récoltait du feed back. On pouvait répondre sereinement aux chef·fes qu’il n’y avait aucun problème pour changer les priorités à deux semaines. L’histoire qu’il raconte alors, c’est comment les principes agiles permettent avant tout de réorganiser l’équipe de dev, en la responsabilisant, et font en sorte que les changements de priorités soient gérés dans un comité ad-hoc, et non plus subis par le management ou par l’équipe. Bref, c’est faire en sorte que les équipes de dev soient heureuses.

La fable de l’économiste et de l’agilité

(texte original : La fable de l’économiste et de l’agilité)

Il était une fois un économiste qui essayait de comprendre pourquoi les projets de développement logiciel qui marchaient bien étaient en fait ceux qui utilisaient des principes qui étaient censés ne pas fonctionner. En l’occurrence, il avait remarqué que dans les projets qui marchaient bien, ses membres ne cherchaient pas à être efficaces. Ils n’essayaient pas non plus d’éviter que les imprévus surviennent. Et lorsqu’ils étaient alors en retard, ils ne cherchaient pas à tout prix à refaire rentrer les choses dans le planning. D’ailleurs, ils évitaient de trop planifier d’une façon générale. Autre chose : au lieu de gagner du temps en regroupant les tâches similaires pour les traiter d’un coup, ces personnes essayait d’aller jusqu’au bout de chaque petit développement. L’économiste remarqua aussi qu’elles évitaient de trop se spécialiser. Et, finalement, il semblait que les projets n’avait pas de point central de contrôle. Pour résoudre ce paradoxe, l’économiste postula alors qu’il fallait mesurer l’ensemble des coûts/bénéfices d’un processus de développement en les rapportant à la Valeur Actuelle Nette du produit logiciel (c’est à dire au résultat financier du produit cumulé sur l’ensemble de son cycle de vie), directement, et ne plus passer par des objectifs intermédiaires. Cela lui permit de démontrer qu’il fallait bien réduire les cycles, introduire des rythmes régulier de traitement par petits lots, abaisser les capacités de production de l’ensemble de la chaîne et ainsi diminuer la la longueur des files d’attente, pondérer financièrement les décalages par rapport aux gains attendus, et alors traiter les imprévus avec un surcoût minimal. L’histoire que raconte alors notre économiste c’est que les méthodes agiles promeuvent des processus qui ont tendance à augmenter la VAN du produit, ce qui permet à l’entreprise d’améliorer ses bénéfices (qui reste, pour notre économiste, le seul objectif d’une entreprise).

Voilà pour les fables, vous pouvez en trouver d’autres : La fable du directeur marketing et l’agilité, La fable du développeur crafts et l’agilité, La fable de l’éthique du care et l’agilité. Et il m’en reste sous le coude : le startuper et l’agilité, le président du conseil d'administration et l’agilité, le directeur de programme et l’agilité at scale...

Raconter une histoire c’est la réécrire

Quand on m’a raconté la seconde fable, ne connaissant que la première, je pensais que cela venait du fait que l’agilité venait du bas, de ceux qui font, puis qu’elle avait remonté les hiérarchies, notamment grâce au succès de Scrum, jusqu’au plus haut niveau (cabinet de conseil prestigieux, boards des multinationales et programme présidentiel). Alors, à chaque niveau il fallait raconter une histoire différente, et cette hypothèse confortait autant qu’elle alimentait mon mal-être devant ces réappropriations de l’agilité, qui la dénaturait de plus en plus, l’éloignant de sa vocation logicielle principale. Mais je sentais que ce mal-être, bien réel, m’empêchait d’imaginer une autre hypothèse, plus ontologique, et que j’ai rappelée en introduction : que les communautés d’humains aiment construire des mythes fondateurs, autant que chaque individu se raconte des histoires pour consolider sa propre identité. Ce qui m’a donné envie d’écrire ces pages. Avec ces cinq contes, j’ai voulu mettre en avant comment un projet ou une transformation alimente et s’alimente dans un fond historique. Commençons par l’histoire qu’on construit à la fin d’un projet, pour raconter ce qui s’est passé. Ce récit peut être construit à plusieurs, par exemple dans un retour d’expérience, une rétrospective ou un post-mortem d’un projet, ou, au contraire, seul·e, dans sa tête, sur un blog, dans un livre, à une conférence, voire simplement dans ses notes. C’est qu’il y a souvent eu des révélations pendant le projet, avec le problème des révélations : on les sent, on n’a pas besoin de les justifier, on sait juste que ça va résoudre ses problèmes. Les histoires vont permettre d’ancrer celles qui ont fonctionné. L’histoire qu’on raconte au début d’un projet, ça peut être le brief du ou de la cliente pour un nouveau projet, le story-telling d’une start-up. Et, quand je rencontre une ou un client pour un projet de transformation d’organisation agile, j’ai souvent l’impression que cette personne elle-même s’attend à que je lui raconte une histoire. Pour cela, je vais piocher dans les histoires réécrites à la fin d’une précédente réorganisation. Mais laquelle raconter, laquelle est la sienne ? Parfois je me demande quelle princesse ou prince veut-elle être ou rencontrer… Dans tous les cas, je me rends compte de deux limites à ces histoires. La première est que l’histoire sera ce qui va rester du projet, de la transformation : le reste sera archivé. On risque même de s’y accrocher un peu trop, et par conséquent elle risque d’envahir son identité. Voire, on va chercher à travers elle à s’inscrire dans l’Histoire. La seconde est que, bien que l’histoire soit peut-être juste dans ses motivations comme on le verra juste après, les faits rapportés sont faux : on a réécrit l’histoire, on en a fait un mythe. Parce qu’elle va passer par le filtre de nos émotions, de nos perceptions. Parce que nous en faisons une synthèse (un peu comme la seule carte vraiment exacte serait un carte au 1:1, la seul histoire réelle sera celle qu’on pourrait rejouer au mot près). Parce que nous orientons cette synthèse dans un objectif démonstratif. Et, même de bonne foi, parce que la mémoire est une chose formidablement plastique (il paraîtrait qu’on transforme un souvenir chaque fois qu’on se le rappelle).

Et finalement, la dernière réécriture de l’histoire, c’est celle qui se passe sur l’autre scène, celle de l’inconscient. C’est celle que l’on peut découvrir avec un autre coach, au fond de soi-même, plus tard. Me concernant, le passage à l’agilité m’a apporté autre chose que je n’ai pas raconté sur le coup, mais qui a sûrement été une motivation à changer l’organisation globale des quarante personnes qui m’entouraient à l’époque : ma haine farouche de l’imprévu, dans une relation presque autiste à la réalité (et quitte à faire cliché, je pourrais même vous raconter comment cela à avoir avec les injonctions paternelles entendues dans mon enfance). Du coup, rien de mieux qu’une cadence parfaite de rituels, rassurante, avec des espaces explicites pour rendre visible l’imprévu. L’agilité, c’est ce qui m’a permis d’assumer mes propres dissensions internes, voire de modeler le monde extérieur à partir de ces dissensions. Et pourtant, c’est une histoire bien différente que je racontais autour de moi…

Le plus important dans ces histoires n’est pas de savoir si elles sont vraies ou fausses. Les mythes, les fables ou les contes, sont vrais et faux : non, les corbeaux ne parlent pas aux renards, les princesse ne dorment pas 100 ans dans des châteaux, les dieux n’habitent pas en haut de l’Olympe. En revanche, les méta-structures politiques et psychologiques qu’ils traduisent sont bien réels, que ce soient la différenciation entre le rôle des femmes et des hommes, l’organisation des relations entre les puissances, la morale sociale qu’ils portent, voire les étapes de construction psychologique des enfants. De même les histoires qu’un ou une coach va raconter à des managers pour démontrer les bienfaits d’une transformation agile ne sont ni vraies ni fausses. Ce qui est important, c’est qu’elle permettent d’abord à ces manager de se fixer un horizon dans la tourmente qui arrive. Ensuite, que l’entreprise l’intègre dans sa culture. Enfin, et ce n’est peut être pas suffisamment dit, ces histoires permettront à chacun et à chacune de reconstruire autrement ce que la réorganisation aura déconstruit en elle  et en lui. Mon point est juste de vous proposer d’assumer complètement cela : chaque fois que l’on raconte une expérience, en fait on raconte une histoire, et par là on réécrit l’histoire. Et malgré cela, c’est elle qui va construire nos relations, nos valeurs, notre identité individuelle et celle de la communauté.