• Bien définir les termes
  • Tour de Babel organisationnelle
  • Sortir du mirage de la performance pure
  • Le mandat de coaching pour s’aligner
• Coachs sur le terrain
• Ressources

Au cours de mes études en école d’ingénieur, je me suis formé sur les méthodes de gestion de projet. Lorsque je suis arrivé dans le milieu professionnel, la première chose à laquelle j’ai été confronté, c’étaient les méthodes agiles, laissant l’impression d’une formation quelque peu inutile…

Il y a près de 3 ans maintenant, j’ai eu une « vraie » formation agile : j’ai pu étudier Scrum et Kanban, et l’approche Produit, sur la base de l’expérience de praticiens.

Depuis, je me suis rendu compte, qu’il reste encore du chemin, de la coupe aux lèvres… Je vous propose ici une petite revue de la théorie, pour ensuite vous partager comment j’ai vécu l’agilité sur le terrain.

§Bien définir les termes

Les formateurs l’ont pointé du doigt, et j’ai pu le voir sur le terrain : le mot « agile » est devenu une sorte de récipient vide, où chacun projette ses propres aspirations ou craintes. Pour certains, c’est synonyme de rapidité absolue (faire vite) ; pour d’autres, c’est une philosophie centrée sur l’humain et la bienveillance, au risque d’en oublier les impératifs commerciaux, d’autres au contraire, n’y voient que la productivité… Cette absence d’alignement est le premier danger qui guette une équipe avant même qu’elle ne commence à produire le moindre incrément de valeur.

§Tour de Babel organisationnelle

Dans le monde du produit, nous observons souvent trois points de vue qui s’entrechoquent sans se rencontrer.

1. L’équipe technique y voit parfois une contrainte bureaucratique supplémentaire, un « flicage » déguisé sous forme de réunions quotidiennes. Et la tentation du contrôle est parfois bien réelle.
2. La direction, elle, l’imagine souvent comme une potion magique capable de transformer n’importe quel projet complexe en une ligne droite vers le succès, oubliant que l’agilité est d’abord une question d’adaptabilité et non de simple productivité. D’autres fois, l’agilité est perçue comme un moyen pour « tirer au flanc » : sous l’excuse de se focaliser sur ce qui apporte le plus de valeur, certains responsables se focalisent sur le nombre de fonctionnalités produites (que l’ont appelle l’output), sans prêter attention à la valeur créée (ou outcome).
3. Enfin, le leader agile a parfois tendance à se réfugier dans une vision idéalisée, supposant que le Manifeste Agile est une vérité universellement comprise et acceptée. De ma propre expérience, la littérature fait rêver, avec des promesses d’alignement, de gain de productivité et d’épanouissement, sans forcément insister sur les frictions qui rendent le passage à l’agile bien compliqué.

Le problème fondamental réside dans l’interprétation même du Manifeste. Il est à la fois trop simple et trop complexe, ce qui permet à des consultants formés à la va-vite ou à des blogs peu rigoureux de raconter tout et son contraire. On se retrouve alors avec des organisations qui « font » de l’agile (en changeant les titres des postes) sans jamais « être » agiles dans leur état d’esprit. J’ai ainsi vu des Product Owner qui soumettaient des listes de fonctionnalités à implémenter, et des sprints de 4 semaines structurées en mini cycles en V : une phase d’implémentation des fonctionnalités, suivi d’une phase de recette, où l’équipe Q.A. – surtout pas le client ! Pas même le PO… – assurait la revue des fonctionnalités.

§Sortir du mirage de la performance pure

Nous citons souvent l’idée de « faire deux fois plus de travail en deux fois moins de temps », mais cette promesse peut être un piège dangereux. Si nous nous concentrons uniquement sur la vitesse, nous risquons de construire très efficacement… un produit dont personne ne veut. Si vous avez jeté un œil à mes précédents articles, vous verrez que c’est un sujet récurrent chez moi, et c’est aussi un principe de l’Agilité : nous devons accepter de naviguer dans l’incertitude et de privilégier la résilience face à l’imprévisibilité du marché.

Comme nous l’avions vu pour le PRD, tout commence par la genèse du besoin. Si nous ne sommes pas aligné sur ce qui constituera le succès, nous échouerons à produire quelque chose qui permette aux utilisateurs d’améliorer leur situation future. Mais avant même de nous lancer dans la compréhension des besoins utilisateurs, nous devons nous aligner sur la compréhension même de l’Agilité…

Et pour cela, nous devons passer par un exercice d’humilité : laisser chaque partie prenante donner sa propre définition du terme avant de chercher un compromis fidèle aux valeurs agiles.

§Le mandat de coaching pour s’aligner

Pour contribuer efficacement à la mise en œuvre des principes agiles, nous avons vu en formation un outil simple et efficace : le mandat de coaching. C’est un contrat moral et stratégique sur lequel le Scrum Master, ou Product Owner, va s’engager avec l’équipe et la direction, où nous posons des objectifs clairs pour les 3 à 6 mois à venir.

Ce mandat permet de :

• Vérifier régulièrement la direction prise (sommes-nous toujours sur le bon chemin ?).
• Ajuster les objectifs si la réalité du terrain montre que la valeur attendue n’est pas au rendez-vous.
• Officialiser le changement par l’usage de termes nouveaux qui marquent une rupture avec le passé.

Ainsi, dans le cas du Product Owner, ce sera des termes et pratiques de la culture produit, comme l’engagement sur des objectifs produit, la résolution de problèmes utilisateurs plutôt que la création de fonctionnalités à tout prix, etc. (je vous renvoie à ma série sur le PRD à ce sujet). Dans le cas du Scrum Master, ces engagements porteront sur la mise en place des pratiques agiles, l’efficacité des rituels de Scrum, etc.

§Coachs sur le terrain

En tant que Product Owner ou Scrum Master, nous ne pouvons pas nous contenter de déverser des tâches. Nous devons être les gardiens d’un cadre souple qui permet l’adaptation, faute de quoi nous ne ferons que reproduire les erreurs du cycle en V sous un nouveau nom.

Je n’ai jamais eu l’occasion de poser moi-même un cadre aussi net qu’un mandat de coaching, mais j’ai déjà vu des coachs à l’œuvre, et poser le périmètre en arrivant reste l’approche la plus efficace. Lorsque nous faisons partie d’une équipe déjà sur le terrain, nous introduisons plutôt les bonnes pratiques de l’Agilité au fur et à mesure, en nous assurant de montrer les bénéfices des changements.

Et pour cela, nous devons à minima maîtriser la théorie, et savoir rester pragmatique face aux résultats obtenus. Car au bout du compte, ce qui importe n’est pas d’appliquer Scrum à la lettre, mais de livrer un incrément de valeur qui répond réellement aux frictions rencontrées par vos utilisateurs.

Vous vous en doutez certainement, cet article forme une introduction à une nouvelle série, qui s’adresse également à des Product Owner (ou Scrum Masters) juniors. J’espère également apporter quelques billes à des entrepreneurs cherchant à monter une équipe pour un projet innovant, car l’innovation passe par la prise de risque, et les méthodes agiles sont taillées pour exploiter l’incertitude au bénéfice des utilisateurs.

§Ressources

• Team of Teams - New Rules of Engagement for a Complex World, du Général Stanley McChrystal
• Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams, de Richard Banfield, Martin Eriksson, Nate Walkingshaw (2017, O’Reilly Media).
• Formation à la Gestion de projet par les Méthodes Agiles, de Scrumlife