Une des valeurs fondamentales de la philosophie Agile est la transparence. Cependant, elle s’avère 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. Rappelons que la vélocité en tant qu’indicateur a pour but d’aider l’équipe et le Product Owner à planifier la prochaine itération en fonction des mesures des derniers trois ou quatre sprints; et ce, peu importe l’échelle utilisée, comme par exemple la taille de t-shirt ou les story points suivant la suite de Fibonacci. Par réflexe et par habitude, les parties prenantes de l’organisation peuvent commencer à mettre de la pression sur les équipes en utilisant cette valeur.

L’effet boomerang de la transparence survient à ce moment-là. Dans les moments difficiles, on revient à une non-confiance, on utilise la vulnérabilité de l’équipe pour demander des comptes. En situation de stress, l’organisation va vouloir mettre de la pression et aura peut-être un résultat efficace à très court terme, mais très rapidement par la suite la productivité de l’équipe va chuter. Par expérience, cela ne dure pas plus de quatre 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. À court terme, les parties prenantes voient la vélocité augmenter, mais rapidement on se rend compte qu’il s’agit d’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. La dette technique monte en flèche et la motivation des équipes de réalisation dégringole.

Lencioni

C’est parce que sans confiance, sans curiosité plus profonde de ce que vivent les équipes, sans soutien des parties prenantes, on perd l’engagement des adultes, qui redeviennent donc des enfants.

L’infantilisation du monde du travail est alors à la porte de notre organisation. Dans les équipes, on a l’impression de toujours avoir à se justifier. Pour la direction, le risque suivant, est l’augmentation du taux de roulement, et on doit alors remplacer les différents acteurs du terrain. Cela a un coût très élevé : temps perdu en entrevues de candidats, perte de connaissances métier et technique, etc.

Je caricature à peine, je l’ai constaté 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. Mais lorsqu’on veut qu’une situation change, il est important de savoir commencer par soi-même. L’équipe devra avoir l’intention et la motivation nécessaire pour défaire l’effet boîte noire, la perception extérieure.

J’ai été informaticien pendant quinze années de ma vie professionnelle. Mon premier combat en tant que Scrum Master, il y a plus de 7 ans, a été de déconstruire cette image négative de manque de rigueur qu’ont parfois les ingénieurs. Nous étions souvent traités comme des gamins, au fond du couloir, et il ne fallait surtout pas nous faire interagir avec des clients et des utilisateurs.

À mon sens, un des premiers petits trucs à mettre en place est un tableau que j’appelle « 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 de la vélocité moyenne des derniers sprints.

J’en parle plus dans cet article paru sur Enjoy Agile. Dès que nous sortons des rituels de planification (jour 1 de l’itération), et que nous avons envoyé notre message au reste de l’entreprise résumant ce que nous pensons accomplir durant l’itération, nous pouvons enrichir ce tableau.

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

Voici une liste non exhaustive 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 (exemple : un discours d’urgence du patron.)
  • Une demande de créer une présentation pour un client ou un investisseur potentiel.
  • Une pré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 l’entreprise, 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, etc.
  • Tout travail technique évoqué lors de la planification.
  • Une fête d’entreprise, un congé, un jour férié dont on savait l’existence lors de la planification.
  • « J’ai aidé un copain à régler un problème », euh, c’est la vie normale d’une équipe solidaire et Agile!

Pour l’ensemble de la direction et des managers, ce tableau permet de détecter 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 que nous ne sommes pas conscients 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 que nous faisons, et dans un sens, de dépeindre aux parties prenantes la complexité dans laquelle nous vivons.

La première de mes victoires de 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 de logiciels est grimpée 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 !

Billet précédent

Cultiver l'art d'être soi pour mieux accompagner les autres — Cinquième partie

Billet suivant

Cycle de vie des éléments du carnet de produit

Alexandre Thibault

After more than fifteen years in software development, Alexandre has been an Agile Coach for several years. Originally from Quebec, he has been living in Paris for many years and he leads the Enjoy Agile and We Open Space communities thanks to Slack collaborative tools and Meetup events.

He loves practising Agility in service of his clients by balancing between a presence allowing speech, transformation and awareness and the presence of a guide who advises, suggests and invites. He likes to use Host Leadership: a stance that makes each participant the star of a co-constructed moment lived together. In other words, he loves to help others unveil the beauty of their talent and make it shine, in the collective space. His cup of tea is organizing Opens Spaces for communities or businesses (Open Space Agility).

Pas de commentaire

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.