Dans son article “Why Agile Coaches Can’t Be Product Coaches” publié le 11 juillet 2023, Petra Wille affirme que donner le rôle de Coach Produit à un Coach Agile est une mauvaise décision. Elle soutient que le Product Management se divise en deux dimensions : le delivery et le discovery.

Selon elle, le Coach Agile n’a de compétences que pour le delivery. Cet article démontre que cet argument repose sur une mauvaise compréhension de l’agilité. Je vais expliquer pourquoi l’agilité est une stratégie de gestion de produit. Enfin, je prouverai qu’un bon coach agile est la personne idéale pour être coach produit.

Pour comprendre ce qu’est l’agilité dans le développement logiciel, en profiter au maximum dans son entreprise et ne pas faire l’erreur de la réduire au delivery, il faut revenir au contexte de son apparition. L’agilité est dans ses origines une réponse aux méthodes de gestion de projet traditionnelles (Waterfall et Cycle en V). Le fondement de ces méthodes dépassées est avant tout la croyance que l’humain peut prédire l’avenir. La croyance que suivre un plan établi en amont donnera le succès en aval. La croyance que tout projet qui dévie du périmètre, du délai et du budget initialement prévus échoue forcément. La réalité du terrain du développement logiciel est venue briser cette croyance.

L’agilité : Un changement de paradigme vers la validation continue avec les utilisateurs

L’expérience a montré qu’on pouvait appliquer le plan à la lettre et finir avec des utilisateurs insatisfaits, des clients qui ne veulent pas de notre produit et un projet qui ne sera jamais rentable. Passer plus de temps à tenter de prédire et planifier n’y changeait rien. On s’est rendu compte que le risque de se tromper en suivant un plan était énorme, et qu’il valait mieux partir du principe qu’on est dans le flou tant qu’on a pas validé ce qu’on a développé auprès des utilisateurs. C’est un changement complet de paradigme. On admet qu’on n’a pas de boule de cristal, on accepte le changement, on le cherche même activement en gardant un contact rapproché et fréquent avec nos utilisateurs, et on s’adapte à ce qu’ils nous disent et à ce qu’on observe chez eux. C’est ainsi qu’on « minimise le risque de créer la mauvaise chose ».

Ne limitez pas l’agilité au delivery, faites-en une stratégie de gestion de produit complète

Je viens de citer ici Petra Wille, qui fait l’erreur de n’utiliser ces mots que pour définir le discovery, alors que c’est en fait une parfaite définition de l’agilité, le delivery n’étant que le « comment » de cette gestion du risque. Tout ce qui a trait au delivery dans l’agilité a pour effet recherché de livrer tôt, petit et fréquemment, et ce dans l’objectif d’avoir un retour des utilisateurs qui remettent peu de choses en question, plutôt que d’attendre 6 mois pour que nos utilisateurs nous montrent qu’il faut tout jeter à la poubelle. C’est du delivery dans le but de faire du discovery. L’un ne peux exister sans l’autre quand on est agile. L’agilité est une façon de faire de la gestion de produit.

Lorsqu’on donne les moyens à un coach agile de faire ce qu’il sait faire, il mène l’entreprise à confronter le plus tôt possibles ses hypothèses à la réalité auprès d’utilisateurs (delivery), et à s’y adapter correctement (discovery).

En conclusion, un coach agile ne peut pas ne pas être un coach produit, sans quoi il se coltine au delivery, et l’entreprise livrera petit, tôt et fréquemment mais n’en tirera rien. Elle ne sera pas agile, et ce coach ne pourrait pas prétendre l’être non plus. L’agilité est de la gestion de produit, quand elle est correctement mise en place. Et pour qu’elle le soit, il ne faut pas la limiter au delivery.
Si vous croyez qu’une meilleure gestion de produit repose sur des retours réels d’utilisateurs, un coach agile peut vous guider. Il vous aidera à structurer votre entreprise pour intégrer ces retours tôt et fréquemment. Cependant, cela nécessite de ne pas limiter son rôle aux seules questions de delivery.