Il faut que la feature team commence à dépiler le backlog des user stories et des technical user stories pour s’assurer d’avoir le MVP prêt pour le prochain release train, il faudra d’ailleurs mettre à jour le kanban. Après on pourra prendre les stories en should tout en essayant de maintenir la vélocité de la squad.

Nous, les agents de la transformation agile, les acteurs de cette agilité, sommes cernés par une novlangue agile mêlée à la novlangue d’entreprise. Nous en sommes les ambassadeurs, nous avons le devoir de la juguler.

“La guerre, c’est la paix, la liberté c’est l’esclavage, l’ignorance c’est la force.”

George Orwell

Dans une moindre mesure par rapport au chef d’oeuvre d’Orwell, je pense que ce jargon que nous utilisons a bien un effet sur la capacité de critiquer de la part des gens “qui ne comprennent pas”.
A partir de là ceux qui utilisent la langue ont un pouvoir supérieur à ceux qui la découvrent. Nous avons donc ceux qui parlent la langue agile et ceux qui l’écoutent, sans oser demander des explications de peur d’avoir l’air bête tellement cela semble évident (et potentiellement aucun des deux ne sait exactement ce que le terme signifie).

J’ai rencontré des personnes qui commençaient leur phrase en utilisant un terme de tous les jours et, sous prétexte d’être dans une démarche agile, se corrigeaient d’un seul coup et se mettaient à utiliser un mot du lexique de l’agilité. Car il est connu, dans le monde agile, que l’utilisation de termes de l’ancien monde sont interdits (ironie).

Ces derniers temps, j’ai entendu : “Il faudrait qu’on fasse la liste des fonct… heu un backlog”, “Ne me faites pas une propale, faites moi un backlog”, “- C’est quelle équipe ? – C’est la squad front”, “Nos features teams”, “- Il est pas mal votre tableau de suivi – Vous parlez de notre kanban ?”…

• Alors NON, une liste de fonctionnalités n’est pas un backlog autant qu’un backlog n’est pas une liste de fonctionnalités.
• Une propale (ou proposition d’intervention) n’est pas un backlog de propositions, ce n’est même pas une liste de propositions.
• Si une squad est avant tout une équipe, une équipe n’est pas avant tout une squad
• Une feature team n’existe pas, ça reste une équipe
• Un tableau de suivi de tâche n’est pas un kanban, c’est un tableau de suivi de tâches !!

Et c’est très bien comme ça. Cette manière de vouloir absolument utiliser la “terminologie agile” ou lean comme si c’était ça qui rendait agile 

On peut d’ailleurs faire référence à ce qu’on appelle le Cargo Cult Agile. Je ne m’attarderai pas sur le concept car Emilie Esposito l’a déjà très bien fait en conférence.

https://player.vimeo.com/video/215516793

Pour faire court, l’idée du Cargo Cult agile est de copier des “choses” sans les comprendre en pensant que ça aura le même effet. Dans notre cas, donner à penser qu’on est agile car on parle agile.

Mais initialement, qu’on parle d’agilité d’entreprise ou du manifeste agile, aucun ne porte de nouveau terme barbare. Ce n’est qu’une fois qu’on entre dans les méthodes, les outils ou les pratiques que le vocabulaire apparaît.

Et à partir de là, lorsque tout provient de méthodes, d’outils, de pratiques, si plus personne ne comprend ce qui se cache derrière des mots, sommes nous réellement dans “L’interaction et les individus plus que les processus et les outils” ?

Un premier traitement

De plus en plus, à chaque usage de novlangue, je m’assure que les personnes en face de moi connaissent le mot et même lorsqu’elles connaissent le terme, j’en fait un rappel en une phrase.

• Le backlog ? La liste des trucs à faire
• La User Story ? Une spécification très courte orientée besoin utilisateur
• Le MVP ? Plutôt une V1 épurée c’est ça dont vous parlez
• Le Product Owner ? La personne qui arbitre les fonctionnalités du produit, qui gère l’utilisation du budget au mieux et traite avec les clients et l’équipe
  …

Et encore, ma définition est approximative, elle est probablement interprétée et surtout interprétable. De plus, les personnes à qui je donne cette définition ne donneront probablement pas cette définition à d’autres et ainsi de suite jusqu’à ce que plus personne n’ait la même définition et surtout personne ne cherchera à la clarifier.

Je ne sais pas, aujourd’hui comment endiguer ce risque. Oui, faire des formations facilite, oui, rappeler régulièrement de quoi on parle, aide. Dois-je rester à moins d’un mètre de chaque personne pour être sûr de les corriger au bon moment ?

Je pense qu’en tant que représentants de l’agilité, il est de notre devoir de dire qu’on se fout royalement de ces termes, que le plus important est de savoir de quoi on parle même si, à la fin, l’entreprise parle de Glubox et non de backlog… si tout le monde se comprend.

Dans mes formations d’initiation, lorsque j’ai des participants qui me disent “ah ok, je comprends mieux, je croyais qu’on faisait du Scrum mais en fait non”, je leur répond qu’on s’en fout, qu’ils font alors du Tapioca et que maintenant, la question est de savoir comment bien faire fonctionner leur Tapioca. 

Et que s’ils souhaitent que leur Tapioca se rapproche du Scrum alors il faut commencer par comprendre les tenants et aboutissants, la valeur, l’effort nécessaire et les risques liés à la mise en place de chaque élément de Scrum dans leur contexte Tapioca.

Pour finir et pour vous aider, voici un lexique non exhaustif de terme que vous devez démystifier et aussi clarifier avant de les réutiliser demain

PS : Ma réflexion est aussi inspiré par cet extrait du film “The Big Short” :

En anglais ici : https://youtu.be/Ux43E2LiziE?si=y1c9ruB7e7gguESO

En français ici  : https://www.youtube.com/watch?v=kVMm9oATKwc

Image de couverture : Photo by Raphael Schaller on Unsplash