J’entends beaucoup parler autour de moi du rôle de Proxy Product Owner. Mais qu’est-ce que c’est ? Est-il un Product owner ? Quel rôle a-t-il dans l’é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 (composée de tous les acteurs qui permettront de réaliser le produit) et d’un Product Owner.
Alors pourquoi diable parle-t-on de Proxy Product Owner ? D’où vient cette invention ?
On rencontre surtout des Proxy Product Owner dans les grandes organisations.
Lors de leur transformation vers l’Agile, en équipe Scrum, la question de trouver une mission/un poste à tout le monde a dû se poser. Plusieurs cas de figures sont possibles, mais le plus probable est que les chefs de projet MOE ont pris le rôle de Scrum Master, les chefs de projet MOA ont pris le rôle de Product Owner ou de Proxy PO, les chefs de projet plus aguerris ou les managers ont 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. 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.
Il est aussi possible de trouver des Product Owner internes. Ils endossent ce titre en plus de leur fonction, mais qui ne sont pas réellement Product Owner et qui n’ont pas été formés à celle-ci. Pour combler ce manque, d’organisation fait alors appel à un Product Owner externe. En fait sur le papier il sera Proxy Product Owner. Mais en réalité il réalisera toutes les missions d’un Product Owner. Le Product Owner existant est en fait un Stakeholder ou sponsor du projet.
Autre cas de figure. Le client fait appel à un prestataire pour trouver un Proxy Product Owner afin d’aider le Product Owner. Pourquoi ? Parce que laisser les rênes d’un projet à une personne externe à l’entreprise est souvent politiquement impossible. Ou par ce que le Product Owner gère plusieurs projets en même temps. Il y a des risques à avoir plusieurs PO sur un même projet, vous pouvez lire cet article “Est-ce une bonne idée d’avoir plusieurs Product Owner dans une même équipe ?”. 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 Product Owner. On est donc face à une distinction par l’expérience et par le coût, ce qui est plutôt péjoratif.
Tout cela semble fonctionner sur le papier, que se passe-t-il en réalité dans les équipes avec ce genre d’organisation ?
La première chose et non des moindres, est que la première mission du Product Owner ne pourra pas être remplie par un Proxy PO. En effet il lui sera difficile d’acquérir la vision du projet et surtout de la partager. Les cas seront rares où le Proxy PO détiendra la vision, qui restera dans les mains du Product Owner. Sans vision le Proxy PO ne pourra pas driver correctement le projet. Voire même ne pourra pas du tout driver le projet, il manquera totalement d’autonomie. Au final son rôle s’arrêtera à « pisser » de la user story. On ne peut alors pas qualifier le Proxy PO de Product Owner, il n’est plus que Proxy.
Quand bien même, le Product Owner et le Proxy PO partagent et portent tous les deux une vision. Ils ne porteront sans doute pas la même. Dans ce cas ils ne prioriseront pas les mêmes features. Les priorisations pourront être remises en question par l’équipe. Le Product Owner et le Proxy PO remettront eux-mêmes en cause leurs visions. 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 amènera à 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, dans la priorisation des US. Il ne peut pas prioriser le backlog sans le Product Owner, il n’est donc pas Product Owner.
Mais alors quoi faire ? Comment tirer parti de cette ressource ?
La première solution est simple, il s’agit de n’avoir qu’un seul Product Owner sur un projet. Mais alors on fait quoi du Proxy PO ? La réponse est juste en dessous.
Une autre solution est de faire le point sur les missions de ces deux rôles. Que fait le Product Owner, que fait le Proxy PO ? 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 Rôle de Product Owner. Et ainsi abandonner la particule Proxy qu’il traîne comme un boulet, pour se concentrer sur les activités et actions du quotidien.
De manière plus traditionnelle, le Product Owner est peut-être un analyste qui va se concentrer sur le recueil des besoins utilisateurs. Séparer alors clairement les rôles. Séparer les tâches qui incombent au Product Owner, qui est dans l’équipe, de celle de l’analyste (ou autre fonction), qui ne peut pas être Proxy PO, et qui n’est pas dans l’équipe.
Demandez à l’équipe comment elle souhaite s’organiser, après tout elle connait le produit, elle connaît les enjeux, elle se connaît et sait comment s’organiser. Et puis si ça ne marchait pas, au moins vous auriez testé et vous pourrez en discuter lors d’une rétrospective. Et alors ajuster l’organisation, 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. Appelons le PPO, Product Owner, puisqu’il l’est vraiment.
Soit l’équipe n’a qu’un seul Product Owner, soit elle en a deux, ce qui n’est pas possible. Si elle a 2 Product Owner alors l’un des deux ne peut pas être Product Owner. Le 2nd product owner a donc un autre rôle dans le projet.
Le Product Owner est indispensable à l’équipe et au 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. Mais nous en parlerons dans un autre article (Que se passe-t-il si le Product Owner n’est pas suffisamment disponible ?).
Alors pensez-vous que le Proxy Product Owner est légitime ?
