February 10, 2010

Suis-je un mauvais coach agile ?

C'est la question que je me suis posé en lisant un n-ième article de blog américain sur le coaching agile avec, en vrac, 4 citations de bouquins faisant "autorité", 3 références à des modèles comportementaux, 9 utilisations de termes japonais, 2 métaphores sur les arts martiaux, et 1 signature prétentieuse. Je me suis senti quelque peu "nanifié" de ne pas connaître la moitié des références exposées.

Car oui, je clame haut et fort mon ignorance:
  • je ne connais pas le modèle de Tuckman
  • j'ai fait du judo quand j'étais jeune et je ne vois aucune similitude avec le développement informatique
  • shu ha ri est un concept vague dont j'essaye de percer le sens lorsque je propose des sujets à des conférences agiles
  • Kano est le nom du restaurant en bas de chez moi
  • je n'ai jamais réussi à lire un livre sur l'agilité jusqu'au bout; le seul que j'ai terminé concerne le Lean (The Machine That Changed theWorld) et ne parle pas du tout d'informatique
Une telle étendue d'ignorance et de mauvaise volonté devrait me conduire droit à l'échec sur mes missions de coaching agile.

Et pourtant ...
... mes différentes missions de coaching agiles se passent bien et atteignent leur objectif (jusqu'à preuve du contraire). Je vous propose donc mon top 5 de ce que je mets en oeuvre dans mon coaching d'équipe agile (garantie sans termes japonais):
  1. pas trop de changement d'un seul coup: ce qui compte c'est l'application des 4 principes agiles, le reste c'est de l'enrobage à distiller au compte-goutte et dont une grande partie relève de l'initiative de l'équipe. Si certaines techniques ne sont pas bien appliquées dès le départ ce n'est pas grave, il faut se concentrer sur les quelques éléments clés qui caractérise une équipe agile. A mon sens ce sont les itérations en time box, les démos avec du logiciel qui fonctionne pour de vrai, et la communication directe. Il y en a bien sûr beaucoup d'autres, mais cela vient progressivement,
  2. du pilotage opérationnel: il faut que l'équipe, et plus largement mon client sache où il va et quels sont les mécanismes de gestion d'un projet agile. La période de coaching ne doit pas générer d'effet tunnel. Par exemple, quitte à me brouiller avec des agilistes chevronnés, je fais en sorte que les itérations atteignent leurs objectifs, et surtout la première itération. L'échec est un luxe que se permettront les équipes rompues à l'agilité. Egalement, il est utile d'organiser des comités de pilotage du projet, celui sur lequel intervient l'équipe coachée, à chaque fin d'itération et avec des participants qui vont au delà du PO (typiquement la hierarchie). C'est là qu'on présentera les indicateurs, les projections de budget à terminaison, la variation du périmètre, bref les mécanismes de pilotage. C'est en quelque sorte la démo de la mission de coaching agile.
  3. de l'écoute, de l'écoute, de l'écoute, et encore de l'écoute: il me semble très important de prêter une oreille attentive à tout le monde c'est-à-dire bien sûr l'équipe, le Scrum Master, et le Product Owner, mais aussi son chef, les collègues, les utilisateurs, le commanditaire de la mission de coaching, son chef, les instances transverses, bref tous! Je ne jette aucune information ni n'écarte d'un revers de la main les réactions inappropriées. Tout commentaire est bon à prendre, toute réaction a son fondement et cache parfois des informations capitales pour la réussite de la transition vers l'agilité
  4. de la communication: expliquer en permanence les principes de l'agilité à toutes les parties prenantes (direction, organisations transverses, équipes métier, contributeurs, prestataires, etc). On s'aperçoit vite que l'équipe coachée est entourée d'un nombre insoupçonné de personnes qui ont un rôle à jouer ou qui influencent d'une façon ou d'une autre le travail de l'équipe
  5. de l'empathie: les membres de l'équipe coachée vont traverser un changement parfois très profond de leurs habitudes de travail. Cela apporte son lot d'incertitude, d'angoisse, voire de souffrance dans certains cas. Je ne suis pas là pour torturer mes clients mais pour leur faciliter la tâche, j'essaye de ne jamais l'oublier.
Bon, tout ça pour dire quoi ?
Pour dire que je suis prêt à entendre qu'il faut sans cesse se cultiver pour améliorer ses pratiques, mais il faut pouvoir ... mettre sa culture en pratique!! Je trouve qu'il y a quand même un bonne partie de toute l'agitation autour du coaching agile qui tient de la démonstration mathématique voire parfois de la masturbation intellectuelle, et qui ne sert pas à grand chose concrètement.

Sayonara !
NB: ce message ne s'adresse pas aux bloggeurs pragmatiques qui adressent également tous ces concepts dans leur messages. D'ailleurs, j'envoie mes remerciements à JC qui reste ma première source d'information pour comprendre le baragouinage de certains :)

3 comments:

Etienne Charignon said...

Interessant l'idée de faire que la première itération se passe avec succès. C'est bête mais je n'y avais pas pensé.
Il est en effet tout a fait possible de faire attention a ce que les objectifs de cette première itération ne soit pas excessifs.

Eric Mignot said...

Salut Gilles
Pour ma part j'aime bien bouquiner de temps en temps des "trucs de coach". Mais pas trop souvent j'avoue.
De manière générale, j'aime bien discuter avec d'autres gens qui font des trucs similaires à ce que je fais pour partager avec eux les joies et les peines que nous vivons.
Lire un bouquin, regarder un modèle, fleurter avec des références d'une autre culture c'est aussi un autre type de conversation. Un monologue en fait. On peut tout oublier lorsque le monologue est fini ou bien conserver ce qui fait sens pour nous.
Ce qui est sûr pour moi c'est que ce qui est dans le cerveau des autres a de la valeur pour moi. Et certains ont pris le temps de flusher leur cerveau dans un livre.
a+
Bob

David Gageot said...

http://agilecoach.typepad.com/agile-coaching/2010/02/shuhari-considered-harmful.html