Trouver le bon « Coach Agile »

En 2004 et 2005, de plus en plus d'équipes sont passées aux méthodes agiles et, naturellement, elles avaient d'abord besoin de conseil et de formation. Malheureusement, dans de nombreux cas, j'ai dû intervenir dans les entreprises après les formations pour remettre de l'ordre dans le chaos laissé par les formateurs. À l'époque, j'ai supposé à tort que ce problème ne durerait que le temps que les nouvelles équipes agiles – en particulier dans les entreprises développant des logiciels standards – acquièrent de l'expérience. Hélas, le problème des mauvais formateurs et coaches n'a pas disparu. Bien que de nombreuses entreprises aient déjà opté pour de bons formateurs, ils restent à mon avis plutôt l'exception.

Comme pour beaucoup d'autres choses, c'est bien sûr au client de trouver le meilleur formateur pour lui. Cependant, lorsqu'une équipe a besoin de formation, il est très probable que ceux qui doivent prendre cette décision n'aient pas encore d'expérience en la matière. L'intention derrière cet article est donc d'aider les entreprises de produits à trouver les bons formateurs et coaches en méthodes agiles.

Différents facteurs pour trouver le bon Coach Agile

1. Dans la plupart des cas, les logiciels sont encore développés à des fins internes (IT) ou spécifiquement pour un client particulier. C'est pourquoi de nombreux formateurs agiles ne s'adaptent tout simplement pas bien aux entreprises qui développent des solutions pour le marché de masse. Bien sûr, tu ne veux pas être l'entreprise sur laquelle un tel formateur s'exerce. Il est donc important de savoir à l'avance si le formateur potentiel comprend la différence entre l'IT (interne), le développement de logiciels sur mesure et le développement de logiciels standards.

2. Dans les entreprises qui développent des logiciels standards, les rôles sont très différents de ceux des autres types de logiciels. Un formateur potentiel doit comprendre le rôle du chef de produit, du marketing produit, de l'équipe expérience utilisateur, des designers d'interaction, des designers visuels et des chercheurs utilisateurs.

3. Le formateur doit savoir comment les chefs de produit et les designers UX collaborent avec l'équipe de développement agile. Le formateur devrait avoir une expérience personnelle du Dual-Track Agile (développement à deux voies) – c'est-à-dire de la Product Discovery et de la Product Delivery.

4. Dans une entreprise de logiciels, il faut parfois être capable de faire des engagements concrets et de donner des estimations fiables sur les dates de livraison. Cela doit se faire avec intégrité, en étant conscient que les roadmaps conventionnelles sont souvent remplies d'éléments qui n'apportent pas vraiment de valeur au client. Le formateur doit donc comprendre comment prendre de tels engagements et comment ils sont gérés au sein d'une équipe produit.

5. Dans les équipes de développement de logiciels standards, la vision produit est extrêmement importante pour créer un contexte et motiver l'équipe. Un formateur en méthodes agiles doit donc comprendre le rôle clé de la vision produit et de la stratégie, ainsi que leur articulation avec la Product Discovery et Delivery.

6. Pour les logiciels internes, beaucoup de formateurs agiles pensent être assez rapides en testant quelques idées à chaque sprint de deux semaines. Pour les logiciels standards, cela serait considéré comme extrêmement lent. Assure-toi que ton formateur a compris que la rapidité est cruciale pour l'innovation et comment le Dual-Track Agile nous aide à valider la plupart des idées sans avoir à écrire de code.

7. Dans les organisations de logiciels standards, on a un cycle continu où l'on construit quelque chose (prototypes et production), on mesure les résultats, on en tire des enseignements, puis on répète le processus. Il est très important que le formateur comprenne l'importance de ce cycle ainsi que des prototypes, des analyses et des tests A/B pour la prise de décision, les tests et l'apprentissage continu.

8. D'un point de vue culturel, il existe une grande différence entre les développeurs d'une organisation IT et ceux d'une organisation de logiciels standards. Le formateur agile doit savoir que le niveau d'expérience et de compétences des développeurs varie considérablement et que l'approche doit être adaptée en conséquence. Beaucoup de développeurs ont bien plus d'expérience dans le développement de vrais produits que la plupart des formateurs. C'est pourquoi les formateurs avec la mauvaise attitude peuvent rapidement échouer à gagner le respect de l'équipe.

9. Une autre grande différence réside dans le fait qu'une équipe dans une organisation IT doit répondre aux besoins de l'entreprise. L'équipe produit dans une organisation de logiciels standards est là pour développer des solutions pour les clients, d'une manière qui soit réalisable et rentable pour l'entreprise. Ce n'est pas une différence anodine. Le formateur doit comprendre qu'il ne s'agit pas d'une organisation de services orientée vers la satisfaction des besoins de l'entreprise.

10. En fin de compte, il est crucial que le formateur comprenne non seulement les entreprises de logiciels standards, mais aussi les exigences et méthodes des services SaaS (Software as a Service) critiques pour l'entreprise. Des sujets comme la mise à l'échelle, la fiabilité, la tolérance aux pannes, la performance, la surveillance et le contrôle, l'automatisation des tests et la dette technique ne sont plus optionnels mais absolument indispensables. De plus, dans le développement de logiciels standards, il n'y a pas de place pour une adhésion dogmatique et aveugle aux processus. Certaines personnes confondent volontiers, dans les méthodes agiles, les moyens d'atteindre un objectif avec l'objectif lui-même. Le seul objectif qui compte vraiment est un produit réussi.

Conclusion

Lorsque tu choisis un formateur ou coach en méthodes agiles, garde à l'esprit que l'entreprise pour laquelle il travaille n'est souvent pas aussi déterminante que la personne elle-même. Vérifie donc le candidat potentiel et découvre s'il possède l'expérience avec les entreprises de logiciels standards dont tu as besoin.

De manière générale, on peut dire qu'un formateur vient chez toi, t'explique la théorie, puis repart. Un coach, en revanche, applique réellement les méthodes avec ton équipe dans ton environnement unique.

Ce texte provient du blog de Marty Cagan et a été traduit par nos soins en allemand.