C’est extra !

Article publié à l'origine sur Oddes Pyxis.

Une des valeurs fondamentales de la philosophie agile est la transparence. C’est cependant souvent une arme à double tranchant. Mal utilisée, elle peut créer l’inverse de l’effet escompté.

Lorsque j’accompagne des équipes utilisant une méthode agile comme par exemple scrum, la vélocité est souvent utilisée comme information transparente et diffusée aux parties prenantes. Un rappel que la vélocité en tant qu’indicateur a pour but d’aider l’équipe et le product owner à planifier sa prochaine itération en fonction des mesures des derniers 3 ou 4 sprints, peu importe son échelle utilisée, par exemple la taille de t-shirt ou les story points suivant la suite de Fibonacci. Et par réflexe et habitude, les parties prenantes de l’organisation peuvent commencer à mettre la pression sur les équipes en utilisant cette valeur.

L’effet boomerang de la transparence survient à ce moment-là. On revient à une non-confiance dans les moments difficiles, on utilise la vulnérabilité de l’équipe pour demander des comptes. En stress, l’organisation va vouloir mettre la pression et aura un résultat à très court terme peut-être efficace, mais très rapidement la productivité de l’équipe va chuter. Par expérience, ça ne dure pas plus de 4 semaines.

Pourquoi ? Les lectrices et lecteurs qui connaissent la pyramide des 5 dysfonctionnements d’une équipe de Patrick Lencioni anticiperont ma réponse.

Les équipes vont commencer à gonfler les estimations comme à l’époque des abaques du projet cycle en V. A court terme, les parties prenantes voient la vélocité montée, mais rapidement on se rend compte qu’on joue à un jeu de dupes. La valeur métier pour nos clients et utilisateurs n’augmente pas ! Pire, on a l’impression que les logiciels produits deviennent instables. Une dette technique monte en flèche, et la motivation des équipes de réalisation dégringole.

C’est que sans confiance, sans curiosité plus profonde de ce que vivent les équipes, sans support des parties prenantes, on perd l’engagement des adultes, pour qu’ils redeviennent des enfants. L’infantilisation du monde du travail est à la porte de notre entreprise. On a l’impression de toujours avoir à se justifier dans les équipes. Le risque suivant, pour la direction, est un taux de turnover qui augmente, et alors on doit remplacer les différents acteurs du terrain, et cela a un coût très élevé : temps perdu en entretien de candidats, perte de connaissance métier et technique, etc.

Je caricature à peine, je l’ai vu sur le terrain à tellement d’endroits chez mes clients et en écoutant les histoires de mes ami(e)s dans leurs différents contextes.

D’où l’idée d’améliorer la communication des équipes de réalisation. Il est important de savoir commencer par soi lorsqu’on veut qu’une situation change. L’équipe devra avoir l’intention et la motivation pour défaire l’effet boîte noire, la perception extérieure. Ayant été informaticien pendant 15 ans de ma vie professionnelle, mon premier combat il y a plus de 7 ans, en tant que ScrumMaster, était de défaire cette image négative de manque de rigueur qu’ont les ingénieurs « BAC+5 ». On était souvent traité comme des gamins, au fond du couloir, et il ne fallait surtout pas nous faire interagir avec des clients et des utilisateurs.

Un des premiers petits trucs à mettre en place à mon sens est un tableau que j’intitule « les extras ». C’est-à-dire qu’en début d’itération, on planifie un certain nombre d’éléments en fonction de notre capacité et vélocité moyenne des dernières itérations (ou sprints). J’en parle plus dans un autre article. Dès qu’on sort des rituels du matin de planification, au jour 1 de l’itération, et qu’on a envoyé notre message au reste de l’entreprise résumant ce qu’on pense accomplir dans l’itération, on peut enrichir ce tableau.

Qu’est-ce qu’on y met ou pas dans ce fameux tableau ?

Voici une liste non exhaustive d’exemples de ce qu’on peut y retrouver :

• Des corrections urgentes et intempestives de code en production.
• Un événement de l’entreprise non prévu avant la planification, par exemple un discours d’urgence du patron.
• Une demande de créer une présentation pour un client potentiel ou un investisseur.
• Une avant-vente chez un client potentiel.
• Une étude de faisabilité d’une fonctionnalité pour un client prêt à signer si celle-ci est implémentée rapidement.
• Une formation ou un séminaire. Cela a de la valeur pour la boîte, mais on ne code pas de fonctionnalités pendant ce temps-là.

Des exemples de ce qu’on ne met pas dans ce tableau :

• Les rituels habituels et rythmés de l’équipe, comme par exemple en Scrum, le daily, la revue de sprint, la rétrospective…
• Tout travail technique évoqué lors de la planification.
• Une fête d’entreprise, un congé, un férié dont on savait l’existence lors de la planification.
• « J’ai aidé un copain sur un problème », euh, c’est la vie normale d’une équipe solidaire et agile !

Ce tableau permet de détecter, pour l’ensemble de la direction et des managers, le travail invisible dans leur « usine ». Ce terme, je l’ai pris de ma lecture du livre The Phoenix Project que je recommande à tous. Ce n’est pas parce qu’on n’est pas conscient d’une chose qu’elle n’existe pas. Donc, en tant qu’équipe de réalisation, soyons professionnels et montrons de façon transparente tout ce qui se passe dans notre équipe. C’est une belle façon de vulgariser le travail qu’on fait, et dans un sens enseigner aux parties prenantes la complexité dans laquelle on vit.

La première de mes victoires de la mise en place d’un tel tableau chez un client était une prise de conscience du niveau d’interruptions dans lequel vivait l’équipe technique. Des mesures ont été prises pour améliorer le focus et le flot mental des ingénieurs. La productivité de l’éditeur logiciel a grimpé en flèche. Aujourd’hui, ils lèvent fréquemment des millions et sont toujours en croissance.

Bref, chantez c’est extra, et communiquez un max, la transparence bien utilisée, ça détend l’atmosphère ! Enjoy!

‍