Le Proxy Product Owner est-il une fonction légitime ?

Dans les méthodes agiles et Scrum, nous entendons parfois parler de Proxy Product Owner (PPO). Mais qu’est-ce qu’un Product Owner ? Quel rôle a-t-il dans le travail d’équipe ? Si on reprend le Scrum Guide, il n’est fait mention nulle part du rôle de Proxy PO. La Scrum team est composée d’un Scrum Master, d’une development team (équipe de développement composée de tous les acteurs qui permettront de réaliser le produit) et d’un Product Owner. Alors qu’en est-il du Proxy PO ? Décryptage.

1. L’origine du rôle de Proxy Product Owner

C’est lors de la transformation des grandes entreprises vers la méthode agile que le métier de PPO est apparu.

Dans une équipe Scrum, la question de trouver une mission/un poste à chaque personne a dû se poser. Plusieurs cas de figures relatifs aux attributions de chacun sont possibles. Très souvent, les chefs de projet Maîtrise d’Oeuvre (MOE) ont pris le rôle de Scrum Master, les chefs de projet Maîtrise d’Ouvrage (MOA) sont devenus Product Owner ou de Proxy PO. Les chefs de projet plus aguerris ou les managers ont eux, pris le rôle de PO (ce qui amène d’autres problématiques abordées dans l’article “Le Product Owner peut-il aussi être manager et spécialiste ?”), et les autres sont restés à leur place dans le pôle développement. Cela a sans doute permis à première vue de gérer les égos et d’éviter des conflits que les Ressources Humaines ne voulaient pas gérer.

Lors du recours aux méthodes agiles telles que Scrum, il est aussi possible de trouver des Product Owner internes. Ils endossent ce titre en plus de leur fonction, mais ils ne sont pas réellement Product Owner et n’ont généralement pas suivi de formation à ce métier. Pour combler ce manque d’organisation, on fait alors appel à un Product Owner externe. Dans le cadre de la méthode agile, il sera Proxy PO, mais en réalité il réalisera toutes les missions d’un Product Owner. Le Product Owner existant est la personne qui sera le stakeholder ou sponsor du projet.

Autre cas de figure : le client fait appel à un prestataire pour trouver un Proxy PO afin d’aider le Product Owner. Pourquoi ? Parce que laisser les rênes d’un plan de transformation digitale à une personne externe à l’entreprise est souvent politiquement impossible ou parce que le Product Owner gère plusieurs projets en même temps. Au moins dans ce cas, la règle qui consiste à n’avoir qu’un seul Product Owner sur un même projet est respectée. Mais est-ce que cela fonctionne pour autant ?

Enfin, un autre cas probable est qu’un Proxy Product Owner, dans la croyance collective, coûtera moins cher qu’un PO. On est donc face à une distinction par l’expérience et par le coût, ce qui est plutôt péjoratif.

2. L’impact du Proxy Product Owner dans les organisations

Dans le secteur digital ou autre, les missions d’un Product Owner ne peuvent pas être réalisées par un Proxy PO. En effet il lui sera difficile d’acquérir la vision du projet et surtout de la partager à la partie développement et aux autres acteurs de la méthode agile Scrum. Les cas seront rares où le Proxy PO détiendra la vision, qui restera dans les mains du Product Owner. Sans elle, il ne pourra pas driver correctement la transformation agile, voire même ne pourra pas du tout driver comme il devrait. Il manquera totalement d’autonomie et ne pourra pas être un responsable efficace. Il ne pourra également pas faire une bonne gestion des tâches dédiées à chaque personne dans l’équipe. Au final, son rôle s’arrêtera à produire des user stories. On ne peut alors pas qualifier le Proxy PO de Product Owner car ce n’est pas son travail.

Lors d’un projet, le Product Owner et le Proxy PO partagent et portent tous les deux une vision qui n’est pas forcément similaire. Dans ce cas ils ne prioriseront pas les mêmes features et les priorisations de la stratégie de management, les techniques utilisées et la réalisation du backlog pourront être remises en question par l’équipe. Le Product Owner, responsable du projet et le Proxy PO, son assistant, remettront eux-mêmes en cause leurs idées. Pire, le projet sera bloqué car au final le Proxy PO ne pourra prendre aucune décision tant qu’il n’aura pas eu la validation du Product Owner. Ce retard de prise de décision lors d’un sprint amènera à des problèmes de management, à des conflits, à une démobilisation de l’équipe et à toutes les conséquences qui vont avec. Ici aussi si le Proxy PO n’est pas autonome dans sa prise de décision ni dans la priorisation des user stories et s’il ne peut pas prioriser le backlog sans le Product Owner, il n’est donc pas Product Owner.

3. Comment tirer parti de ce rôle ?

La première solution est simple, il s’agit de n’avoir qu’un seul Product Owner qui sera l’unique responsable. Mais alors on fait quoi du Proxy PO ?

Une autre solution est de faire le point sur les missions de ces deux métiers. Peut-être que le Product Owner a plus un rôle de Product Manager (ou de stakeholder?) avec une vision plus transverse, plus large et plus marketing. Dans ce cas, le PM pourra se concentrer sur la relation client, l’idéation à long terme et la stratégie du produit. Quant à lui, le Proxy PO peut alors prendre pleinement son statut de Product Owner et abandonner la particule Proxy qu’il traîne comme un boulet. Au lieu de se contenter d’écrire des user stories, il peut donc se concentrer sur les activités et les actions du quotidien comme stipulé dans les méthodes agiles.

De manière plus traditionnelle, le Product Owner est un analyste qui va se concentrer sur le recueil des besoins utilisateurs bien qu’il n’ait pas une formation spécifique. Séparer alors clairement les rôles et les tâches en se basant sur les métiers exercés par les membres de l’équipe est l’une des attributions qui incombe au Product Owner. Dans la configuration du groupe tourné vers l’agilité, la fonction d’analyste (ou autre) ne peut pas être attribué au Proxy PO, qui est d’ailleurs une personne ne pouvant pas faire partie de l’équipe interne.

Proposez à l’équipe de créer une configuration correspondant aux métiers engagé dans le projet basé sur l’agilité. Puisqu’ils connaissent parfaitement le projet et le produit, les intervenants sont parfaitement équipés pour gérer les divers enjeux. Lors d’un sprint ou durant un backlog, l’équipe organisera une stratégie marketing pour le digital, le data ou d’autres points. Elle procèdera elle-même à une gestion des activités pour une plus grande efficacité et pour faire des offres correspondant aux besoins du client. Et puis si ça ne marchait pas, au moins vous aurez testé et vous pourrez en discuter lors d’une rétrospective des actions menées. Il sera alors possible d’ajuster l’organisation, la formation de l’équipe et son management. L’acception de l’équipe n’en sera que plus grande.

Quoi qu’il en soit, arrêtons de parler Proxy PO – la particule Proxy n’a pas de sens et ne fait qu’embrouiller les responsabilités de chacun. Un Proxy PO est soit un Product Owner en tant que tel et arrêtons de l’appeler Proxy, soit ce n’est pas un Product Owner et arrêtons aussi de l’appeler Proxy PO. Si le Product Owner n’est pas PO, appelons le par son vrai nom, et appelons le Proxy PO, Product Owner, puisque c’est son vrai travail.
Soit l’équipe n’a qu’un seul Product Owner, soit elle en a deux, ce qui n’est pas possible. Dans ce cas, alors l’un des deux ne peut pas être Product Owner et a donc une autre fonction.

Le Product Owner est indispensable à l’équipe et à la gestion du projet. Sans lui le produit n’ira pas dans la bonne direction. Si le Product Owner n’est pas là il ne pourra pas apporter la valeur attendue par l’utilisateur et les livraisons seront problématiques.

Alors pensez-vous que le Proxy Product Owner est légitime ? N’hésitez pas à vous renseigner sur ce métier et son importance dans votre organisation !

En résumé :