Imaginez le contexte suivant : une bonne connaissance à moi est chargée de mener un projet de développement d’un produit électronique (ingénierie) impliquant beaucoup de développement logiciel dans un contexte R&D.  Il travaille pour une grosse société habituée aux processus en cascade typiques de l’ingénierie, mais a entendu du bien de l’Agilité (par moi, ô mon Dieu) et veut utiliser cette approche.  Mais bien évidemment, il est à l’autre bout de la planète par rapport à moi et on n’a que le téléphone et les courriels pour échanger.

Il fait ses devoirs et lit sur le Web ce qui se rapporte à l’Agilité, et en a compris plusieurs caractéristiques : les itérations, l’engagement de l’équipe, la revue, etc.  Il oriente donc son équipe vers cette approche, même si évidemment, ne l’ayant jamais vécu, il n’en comprend qu’une petite partie.  En effet, après quelques échanges avec lui, je réalise :

• Qu’il n’a pas de carnet, sinon pour l’itération en cours;
• Qu’il n’a pas de PO, c’est l’équipe qui priorise la fonction de la cible à long terme;
• Qu’il n’y a pas non plus de vision claire du produit final (la cible restant « changeante »);
• Que bien que des jalons soient établis (V0.5, V0.8, V1 // étalés sur 12 mois) chacun avec des démos, il n’y pas de démos récurrentes à un PO (par itération).

J’entame une discussion avec lui afin de l’inciter à :

• Tenir un atelier de découverte avec des utilisateurs types (basé sur les cas types d’utilisation de son produit) afin de mieux comprendre leurs besoins et d’en déduire un carnet, plutôt que d’attendre la fin (les essais) et de peut-être d’obtenir une rétroaction négative (trop tard);
• Se définir une vision plus claire de la cible et la partager avec ses coéquipiers;
• S’en tirer un carnet (au pis aller, une ébauche des composantes qui, itérativement, seront réalisées, testées et livrées);
• Se donner un planning grossier permettant d’établir les grandes cibles des itérations en fonction des jalons à atteindre et de parfois mettre de la pression sur l’équipe;
• Établir qui agira comme PO (peut-être son partenaire qui n’a pas les mains dans la réalisation).

Évidemment, comme coach passionné du sujet, j’y vais trop fort et comprends vite que la bouchée est trop grosse.  Je tente de m’ajuster et d’agir comme caisse de résonance bihebdomadaire, lui permettant de mettre en place un suivi d’avancement, une rétroaction des avancées Agile, mais rapidement, le tout s’arrête.  Il n’y trouve pas l’intérêt et est préoccupé par l’avancement de son projet.  Et la distance n’aide évidemment pas.

J’AI appris une grande leçon :

1. L’Agilité ne s’apprend pas en cascade (formation -> mise en pratique), mais de façon itérative, à travers de petits succès, au travers desquels on l’apprivoise doucement;
2. Le coaching à distance est éminemment difficile, ne permet pas d’utiliser un tableau blanc pour mieux se comprendre et, surtout, implique des techniques différentes du coaching direct;
3. Sans au moins une personne dans l’équipe qui en a le vécu (et qui agira comme multiplicateur), déployer une vraie approche Agile relève du défi (peut-être insurmontable) et exige un gros effort de coaching (plus que je ne m’y attendais et que je pouvais fournir à distance).

La bonne nouvelle, c’est que malgré tout ça, son projet avance bien, et que la perception de l’équipe de l’Agilité (première itération de l’adoption) est bonne !!!