On n'insistera jamais assez sur la présence/disponibilité du client (product owner, MOA etc) comme facteur de succès d'un projet de développement informatique.
Henrik Kniberg, dans son excellent et pragmatique bouquin "Scrum and XP from the Trenches" nous propose des pistes pour convaincre un client de sa nécessaire présence, au moins au planning de sprint :
Que faire si le directeur de produit persiste à dire qu'il n'a pas le temps de participer aux réunions de planning de sprint ? Habituellement j'essaie les stratégies suivantes, dans l'ordre proposé :
• Essayer d'aider le directeur de produit à comprendre pourquoi sa participation directe est cruciale, et espérer qu'il change d'avis.
• Essayer de convaincre quelqu'un de l'équipe de se porter volontaire pour servir de représentant du directeur de produit pendant la réunion. Dire au directeur de produit : « Puisque que vous ne pouvez pas venir, nous laisserons Jeff ici présent vous représenter. Il aura les pleins pouvoirs pour changer la priorité et la portée des histoires pendant la réunion. Je vous suggère de vous synchroniser avec lui le mieux possible avant la réunion. Si Jeff ne vous convient pas comme représentant, merci de suggérer quelqu'un d'autre, à condition que cette personne puisse rester avec nous pour toute la durée de la réunion. »
• Essayer de convaincre l'équipe de direction de désigner un nouveau directeur de produit.
• Repousser le démarrage du sprint jusqu'à ce que le directeur de produit trouve le temps de participer à la réunion. En attendant, refuser de s'engager sur une quelconque livraison. Laisser l'équipe consacrer chaque jour à ce qui lui paraît le plus important ce jour-là.
Finalement, on peut se demander pourquoi s'évertuer à trouver des arguments de ce type puisque, a priori, tout le monde est déjà convaincu.
Pourquoi diable le client est-il chroniquement si peu disponible pour son propre projet ?
La raison que je rencontre le plus souvent est qu'il intervient sur X projets à la fois et/ou qu'il passe pas mal de temps à les élaborer ces fameux besoins au sein d'une équipe qui elle-même est morcelée, disjointe, éloignée !
Donc l'idéal serait :
• que le product owner ne s'occupe que d'un ou deux projets max en reconcentrant ses efforts sur le suivi du dev plutôt qu'élaborer péniblement les besoins de 10 projets simultanément
• qu'il gère mieux les priorités afin d'obtenir plus vite l'expression des besoins de premier plan