Le Proxy Product Owner : nouveau rôle ou anti pattern agile ?

Ces dernières années, un nouveau rôle a vu le jour dans les équipes agiles : celui de Proxy Product Owner (désigné aussi sous le nom de Proxy PO ou encore PPO). Si ce rôle n’est pas défini dans la méthodologie Scrum, en pratique, il s’avère de plus en plus utilisé.

Quel est le périmètre du PPO ? Quelle est sa pérennité au sein de l’entreprise agile ?

Les équipes projets ont pris l’habitude de travailler à distance, sur des sites d’entreprise différents, avec parfois aussi des langues différentes. Cela s’est encore accentué avec la crise sanitaire et le recours au télétravail.

Malgré les outils collaboratifs qui facilitent le travail à distance, les équipes se retrouvent souvent confrontées aux mêmes problématiques :

• le Product Owner est peu disponible pour les développeurs : il est souvent situé côté métier et non dans les équipes Scrum directement.

• les équipes Scrum aimeraient que le PO ait une meilleure connaissance de l’agilité.
• Les équipes Scrum manquent de visibilité sur les évolutions à venir alors même que cette visibilité pourrait leur permettre de faire de meilleurs choix technologiques, y compris dans la façon de concevoir le code.

Alors, quel périmètre pour le PPO ?

Le PPO peut prendre plusieurs rôles :

• le PPO vient combler un manque de temps du PO : dans ce cas, le PPO est finalement un « PO à la place du PO» dans les rôles et missions qu’il endosse.
• Le PPO fonctionne en binôme avec le PO : le PO peut se concentrer sur les aspects stratégiques et le PPO se frotter aux taches plus opérationnelles en lien avec le Scrum Master.

Dans la pratique, les trois rôles se complètent et on peut parler d’un trio : PO/PPO/Scrum master.

Dans toutes ces configurations, il est essentiel de définir et de communiquer sur le rôle précis du PPO : son périmètre fonctionnel et ses redevabilités vis-à-vis des parties prenantes. Ainsi, il pourra trouver sa place et être légitime vis-à-vis du collectif agile.

En fonction de la façon dont s’équilibre le trio PO/PPO/scrum master, on va retrouver fréquemment dans le périmètre du PPO les missions suivantes :

• Les actions classiques du PO : alimentation du backlog, description des besoins métiers sous les outils collaboratifs (par exemple Jira/Confluence…), rédaction et découpage des User Stories (US), suivi de l’état d’avancement,
• Des missions de clarification sur certains sujets (précision sur une user stories, à quel besoin client cela répond etc…) : cela va permettre de lever rapidement les ambiguïtés et de diminuer ainsi le temps perdu dû aux allersretours dans des discussions entre le PO et l’équipe Scrum. Cela contribue également à instaurer un cadre de confiance avec les développeurs….
• Le PO peut également se charger de l’analyse des anomalies clients et des retours suites aux mises en production (MEP)…

Quel que soit son rôle, le PPO va contribuer à la création de valeur et faciliter la  réussite du projet.

Et concrètement sur le terrain ?

Le rôle de PPO n’étant pas précisément défini dans la méthodologie Scrum, il est courant de retrouver dans des projets ce rôle de PPO organisé différemment et avec d’autres dénominations.

Par exemple, dans le cadre d’un projet mené par nos équipes, il a été important de distinguer les «PO métiers » des «PO IT », allant jusqu’à former un collectif de 6 PO.

Au-delà du nom utilisé, c’est encore une fois la définition du rôle et du périmètre associé qui est déterminante pour que le collectif fonctionne efficacement.

Toujours dans  le cadre de ce projet, l’intervention d’un coach agile a été bénéfique pour permettre à chaque partie prenante d’exprimer ses douleurs et collectivement de trouver des solutions (ici, l’ajout de nouveaux rôles de PO et la mise en place de nouvelles features team).

Pour conclure, même si on peut reprocher à ce rôle de Proxy Product Owner de venir combler des dysfonctionnements dans la mise en place de l’agilité, il est un rouage important dans l’équilibre du projet.

C’est aussi un levier pour avancer dans la transformation Agile.

Anti-Pattern : En génie logiciel, les anti-patrons ou antipatterns sont des erreurs courantes de conception des logiciels. Leur nom vient du fait que ces erreurs sont apparues dès les phases de conception du logiciel, notamment par l'absence ou la mauvaise utilisation de patrons de conception, appelés design pattern en anglais.

Par extension, le terme anti-pattern désigne les différentes erreurs commises couramment dans l’application d’une méthodologie (dans notre article la méthodologie Agile).