Coaching Agile, what else ?

Voilà plus de deux ans que je travaille en tant que Coach Agile et Organisationnel au sein de Soat Agile, avec une prédominence pour les aspects techniques, ce qui me pousse aujourd’hui à prendre du recul sur les prestations que j’ai menées. Evidemment, je ne vais pas rentrer dans le détail de chaque mission, mais plutôt vous présenter les freins rencontrés lors de la mise en place de l’Agilité, que ce soit au sein d’un projet, ou d’une DSI.

Commençons par rappeler ce qu’est le coaching et quel en est l’objectif.

Présentation et analogie

Le coaching est un accompagnement personnalisé dont l’objectif est d’obtenir des résultats concrets et mesurables. Dans le monde du sport, par exemple, l’appel à un coach a pour objectif d’améliorer les performances d’un athlète, que ce soit au niveau de sa vitesse, de son endurance ou encore de ses capacités musculaires.

Malgré l’apparente logique de cette approche, les objectifs énumérés précédemment sont le fruit d’une interrogation complexe que chaque coach se doit d’avoir vis-à-vis de son client, sans quoi il risque l’échec de la mission :

• Quelles sont vos attentes ?
• Vers où voulez-vous aller ?

Il ne s’agit pas d’accompagner brutalement ou mécaniquement son client, mais plutôt de comprendre ses attentes : pourquoi et comment veut-il améliorer ses performances? Il peut exister des attentes cachées, qui pourraient orienter la prestation.

Laissons de côté l’analogie au sport et concentrons-nous sur le secteur informatique, et plus particulièrement le développement de logiciels, sur lequel nous transposerons les interrogations que nous venons de définir.

Quelles sont les attentes ?

En général, le client veut améliorer la qualité de son projet, de ses livrables ou de ses process de gestion du besoin. Parfois, il souhaite améliorer la relation entre ses équipes en les rapprochant. Si jusque-là, il n’y a rien de transcendant, cela devient intéressant lorsque l’on s’intéresse aux moyens mis à disposition du coach pour mener à bien sa mission. En effet, et cela fut une erreur d’appréhension du contexte client que je fis, il est important de s’interroger sur le périmètre d’action autorisé par le client. En y réfléchissant, il est normal de ne pas avoir carte blanche à tous les niveaux, même si cela représente un frein.

Les freins clients

Si nous revenons à notre analogie, le coach sportif a pour mission de transformer son client en marathonien. Compte tenu des paramètres physiques et mentaux de ce dernier, la mission serait réalisable en deux mois. Pourtant, six mois seront nécessaires, car il n’a pas les mains libres. En effet, il doit composer avec l’emploi du temps de son client, ainsi que l’approche que celui-ci souhaite avoir de son entraînement, qui peut être contradictoire avec ses attentes (comme par exemple manger de la pizza à tous les repas).

Je vous propose de détailler trois exemples de freins rencontrés :

Manque de partage de la vision du client

C’est le point que beaucoup d’entre vous s’attendaient peut-être à voir apparaître dans le paragraphe précédent.

La participation du coach dans la communication lors de la transition vers Agile est une part importante de son activité. Pour que cela se passe bien, il devrait définir, en accord avec les équipes, les actions qui vont être menées, ainsi que les faire participer à l’avancement, afin d’atteindre la vision souhaitée. Malheureusement, dans certaines situations, le coach et le client ne partagent pas la même vision et les mêmes objectifs quant à la transition vers Agile, que ce soit dû à des raisons politiques ou à un simple problème d’expression. Dans ce contexte, le coaching est un exercice d’équilibriste, qui obligera à faire valider chaque action entreprise au risque de rencontrer un refus, ce qui empêchera le coach de se projeter dans l’accompagnement de manière sereine et assurée. De la même façon, il ne pourra pas mener efficacement les équipes lors de cette transition.

Ce manque de précision dans la vision du client engendre un risque d’insatisfaction quant au résultat de la prestation, ainsi qu’une perte de crédibilité du coach vis-à-vis des équipes. Pire encore, si la situation n’évolue pas, les équipes s’en verront démotivées.

Amélioration d’un projet Agile en se focalisant sur les développeurs

Il est fréquent que, pour des raisons politiques de droit de rayonnement, il ne soit pas possible d’intervenir sur les équipes métier. De ce fait, en se focalisant uniquement sur les développeurs, il n’est possible que de fluidifier la production de code, en assurant un développement technique plus rapide (tâches, User Stories). Le travail porte donc sur les axes suivants :

• Rendre les développements sereins
• Faciliter la maintenance des fonctionnalités
• Assurer la scalabilité du projet

Pour cela nous prônerons, si ce n’est pas déjà le cas, la mise en place des pratiques suivantes :

• Tests unitaires automatisés
• Tests fonctionnels automatisés
• Intégration continue
• Introspection de la qualité du code (Sonar)
• …

Dans cette typologie de mission, il est important de stipuler que la maintenance de telles pratiques nécessitent l’implication des équipes métier. Même si l’appropriation des pratiques est effective, que la qualité est de nouveau au rendez-vous, la mise en place de tests unitaires (par exemple) a un coût que le métier devra se faire expliquer. En effet, la diminution temporaire de la capacité de production reste un élément sensible à présenter, et difficile à faire accepter, au marketing ou aux équipes métier.

Il est important de retenir que l’accompagnement Agile d’une entité rayonne très rapidement sur les équipes qui constituent un projet, et engendre des effets sur ces dernières.

Absence d’un sponsor fort

Même si ce contexte est rarement rencontré, l’absence d’un sponsor fort est extrêmement délicate à traiter. L’agilité, et sa mise en place, nécessitant un engagement important des équipes (métier, développement, qualité, intégration, …), il faut s’attendre à une baisse de productivité durant la phase de migration des pratiques de travail (formation, appréhension des pratiques nouvelles, …). Afin d’éviter tout dysfonctionnement inter-équipes, il est impératif que le porteur de la transition, ou sponsor, soit légitime quant à la concordance des équipes dans leurs actions.

En l’absence d’un tel sponsor qui identifiera, auprès de tous, le coach comme l’ayant-droit à la vampirisation du temps de travail des collaborateurs, la transition ne pourra s’effectuer correctement. Cela semble catégorique comme conclusion, malgré tout c’est un fait.

Pour illustrer cela, partons d’un coaching bottom-up (des équipes de développement vers les équipes métiers) porté par le responsable de développement. Tant que les actions seront menées dans le périmètre des développements, la légitimité d’intervention sera promue par ce dernier. Le périmètre des équipes métier sortant de son scope, il sera difficile (voir contre-productif) d’apporter de l’agilité dans la gestion du besoin.

L’incompréhension du rôle et des objectifs du coach amèneront à un rejet, ou au mieux à une indifférence, vis-à-vis des actions de ce dernier.

Conclusion

Le coaching Agile consiste à faire avancer ensemble des équipes et des entités vers un objectif et une vision commune. Le coach a pour objectif, comme j’aime le dire, “de donner de la disponibilité cerveau à ses clients”. Il est le fédérateur des idées (avec un regard critique basé sur son expérience) et l’orchestrateur de la mise en place. Il fait faire sans s’impliquer, afin d’assurer l’appropriation des pratiques et de l’organisation mises en place. Comme je l’ai présenté, le coach doit s’attendre à faire face à de nombreux écueils lors de la réalisation de ses objectifs. Avant d’initier l’accompagnement, il est donc important de garder en tête les freins précédemment cités (liste non exhaustive).