Le rôle de proxy Product Owner

Il y a environ six mois, je rencontrais Xebia à propos d’un poste au contour flou de business analyst / product owner / interlocuteur métier / consultant fonctionnel pour les projets de Xebia Studio. Lors de cet entretien, nous tâtonnions dans une définition de cette fonction. Aujourd’hui encore, lors d’avant-ventes, nous prenons soin de bien expliquer ce rôle de business analyst / product owner / interlocuteur métier / consultant fonctionnel / proxy PO et surtout ce qu’il va apporter au projet. Après tout, le proxy PO ne connaît pas tous les métiers de la terre (qui pourrait prétendre ça ?) ! Alors comment peut-il être côté métier, et ce quel que soit le métier ?

Je vous propose de répondre au mieux à cette question, notamment au travers des missions auxquelles j’ai participé et qui m’ont permis de devenir proxy PO.

Le premier fait extrêmement marquant, et qui rend la description d’autant plus compliquée, est que ce rôle dépend beaucoup du projet, de l’équipe de développement et surtout du PO ou responsable marketing avec lequel je travaille. En effet, être proxy PO c’est faire en sorte que l’équipe de développement puisse travailler tranquillement, en toute sérénité. Une définition bien vague que je vais donc illustrer en relatant mon quotidien.

Pour commencer, j’écris ou j’aide à écrire des stories car le PO n’a pas le temps ou bien il n’a pas l’habitude de se positionner du côté de l’utilisateur. Je suis donc garante du backlog. Je fais beaucoup de backlog grooming, ce qui consiste à prioriser les stories, à les remettre à jour, etc. Et surtout, j’essaie autant que possible de préparer les inputs liés aux stories (graphes permettant de visualiser les écrans au tout début d’un projet, règles métiers par la suite, etc.). Ceci permet à l’équipe d’être plus sereine : nous savons où nous allons dans le sprint notamment. Il y a parfois des ratés mais l’intention est là :-)

Je participe également aux ateliers avec le PO et d’autres intervenants du projet (l’ergonome, le service communication, etc.) afin de capturer les informations nécessaires aux inputs de stories mais aussi de faciliter les échanges.

Ensuite, je suis présente aux stands up — quand je le peux, car mon temps est partagé entre deux projets et c’est parfois compliqué… Mais il s’agit là d’un autre débat. Le stand up est très important pour réussir la bascule d’un projet à l’autre. Mais aussi et surtout, il est important pour l’équipe, qui en profite pour poser toutes les questions métier en réserve.

J’ai lu récemment un article remettant en question l’existence du proxy PO. L’auteur défend qu’il peut exister plusieurs PO, mais que le rôle de proxy n’existe pas. Il est vrai que Scrum ne définit pas ce rôle. Néanmoins, c’est un rôle qui émerge du terrain par un manque identifié. Les attributions du PO sont conséquentes. On parle souvent de « polymath ». Il faut alors trouver la perle rare : à la fois compétente dans le métier, mais aussi intéressée par les processus agiles et ayant le temps de porter toutes les responsabilités lui incombant. J’ai bien peur qu’il y ait souvent besoin de plusieurs personnes pour tout ça… Plusieurs PO ? Pourquoi pas, cependant il y a souvent un PO plus stratégique (vision stratégique, proche des stakeholders) et un PO plus « tactique » (gestion du backlog, du produit à court et moyen terme). D’où le terme de proxy. Certes ce rôle est peut être une béquille transitoire dans les organisations en phase d’apprentissage agile ou juste une variante plus réaliste du « Unbreakeable PO », super héro remplissant toutes ses tâches au mieux.

Quoiqu’il en soit, le rôle de proxy PO au sein de mes missions permet d’enrichir les interactions. N’est-ce pas plus important que de respecter Scrum by the book ? Il permet d’éviter certains écueils et, pour paraphraser un autre article de blog (très amusant par ailleurs), les concepts agiles doivent supporter des adaptations lors de leur mise en application afin de sauver l’agilité.

Pour conclure, en tant que proxy PO je suis le bras droit du PO et je me place donc dans les trous, les espaces vacants que le PO ne peut pas occuper par manque de temps le plus souvent, parfois par manque d’habitude. Parce qu’à force, les ‘je veux… afin de…’, j’en ai l’habitude !

3 Responses

  • Ce rôle DOIT exister ! Les clients ne sont pas toujours des informaticiens et de plus ont plusieurs projets à gérer qui sont plus importants que le nôtre !

  • Mais dites donc, ce rôle existe depuis bien longtemps. Pas dans la Scrumosphère, certes. Il émerge de la prestation de service pour les développements externalisés et de la segmentation des rôles pour les développements internes. Les seuls lieux où l’on trouve des Product Owners depuis longtemps, c’est chez les éditeurs. On les appelle « Chef produit ». Et dans tous les endroits où il n’y a pas un vrai PO, il faudra toujours quelqu’un pour tirer les verres du nez des clients, recadrer leurs idées, les aider à analyser leurs besoins réels. Du coup, il me vient une petite équation caustique : « CdP Maitrise d’Ouvrage legacy + Proxy Product Owner = Product Owner = Proxy Product Owner + Client débordé ». Donc, « CdP Maitrise d’Ouvrage legacy = Client débordé »… Hum hummmm. Tout s’éclaire donc. Vive Scrum!

  • « Ce rôle DOIT exister ! Les clients ne sont pas toujours des informaticiens et de plus ont plusieurs projets à gérer qui sont plus importants que le nôtre ! »
    Non bien sûr, en même temps le PO « traditionnel » est là pour ça, assurer la communication entre le(s) client(s) et l’équipe. Ca ne concerne pas le rôle de PO Proxy

    Le Product Owner a un rôle bien définit dans Scrum. Il n’y a que peu de cas où il a besoin d’être secondé. En revanche ce qui arrive fréquemment c’est que le Product Owner travaille avec une équipe Scrum dans une entreprise non Scrum. Et dans ce cas il faut participer aux COPIL, expliquer la méthode, faire des comptes-rendus, etc. Bref rendre compréhensible pour des personnes issues de méthodologies plus traditionnelles la philosophie Scrum. A ce moment là, et pour ne pas surcharger le PO, il devient utile d’avoir un PO Proxy qui va faire le lien entre les personnes travaillant en Scrum et ceux travaillent d’une autre manière. D’où le terme de Proxy.

Laisser un commentaire