Pour la troisième année consécutive, Klee Group a participé en tant que sponsor à cet événement phare de la communauté agile en France. Agile en Seine est un moment de partage très apprécié des agilistes, quel que soit leur niveau d’expérience.
BLOG | Proxy Product Owner : décryptage d’un rôle énigmatique
11/09/2024
Un rôle qui prête à confusion
Parmi les rôles "non-officiels" croisés dans le monde de l’agilité, celui de PPO a pris une place importante dans la réalisation de produits. Il est souvent intégré dans une équipe agile, pour épauler le PO qui n'a pas toujours la disponibilité requise (car plusieurs casquettes ou plusieurs produits). Il se peut aussi qu’un PO soit désigné "volontaire" et n’ait aucune envie de s'impliquer sur ce sujet. Même s’il est préférable de nommer un PO investi dans sa mission, un PPO permettra à son équipe de démarrer sans tarder et d’absorber la plupart des questions et blocages. A terme, le PPO reste un rôle transitoire, qui sera moins présent au fur et à mesure de la progression de son équipe (meilleure autonomie, produit stable en production, PO qui embrasse pleinement son rôle…).
N'étant pas clairement défini, on retrouve de nombreuses variantes du PPO, avec des attributions plus ou moins communes. Le terme même de "Proxy" laisse à penser qu’il n’est qu’un simple relais, un assistant du PO ou un intermédiaire de plus... Il peut devenir bien plus que cela, en lui accordant la légitimité qu'il mérite.
Deux dominantes se démarquent : le PPO plus "technique" et le PPO plus "fonctionnel". Là où le PO se situe généralement côté métier et va travailler sur la valeur, le PPO aura plus souvent une fibre technique. Avec le temps et par la force des choses, il finira par s’approprier toutes les facettes du produit sur lequel il va intervenir.
Clarifier son domaine d’intervention
Pour éviter toute confusion quant à son périmètre et ses redevabilités, il convient de s’entendre avec l’équipe sur ce que le PPO doit faire, ne pas faire ou peut faire avec le niveau de délégation approprié. Il est important d’être clair sur sa liste d’attributions au plus tôt, quitte à l’enrichir et l’ajuster au fil du temps. L’objectif étant que sa participation soit complémentaire de l’équipe, sans qu’il ne soit réduit à faire la petite main ou secrétaire du PO. Ce n’est pas un simple intermédiaire, mais un support précieux sur lequel l’équipe doit pouvoir s’appuyer.
Ateliers Rôles & Responsabilités : RACI, Job Desc, Give & Take, Do & Don’t, Delegation Poker…
Malgré tout, le PPO pourra prendre en charge un certain nombre de tâches qui incombent normalement à d’autres. Classiquement, le PO va lui déléguer une partie de ses responsabilités vis-à-vis du produit et de ses interlocuteurs. Il pourra rédiger des US, participer au DSM, faire de la recette, préparer la Review…
Au-delà des délégations qui peuvent lui être confiées, le PPO sera amené à :
- Faire le lien entre l'équipe et les entités externes
- Comprendre le métier, les utilisateurs et le produit
- Faciliter la conduite du changement hors équipe
- Gérer le catalogue des tests et écrire des scénarios
- Organiser la préparation des livraisons et des MEP
- Participer à l'analyse des incidents de production…
Tout est possible, dans la mesure du raisonnable, des compétences et de l’accord de l’équipe sur les délégations proposées. Le bon sens, l’art du compromis et du consentement seront de mise ; la clarification, le partage et une trace écrite seront essentiels.
Le PPO sera aussi le partenaire privilégié des personnes ou des équipes qui n’évoluent pas dans un contexte agile, ou qui sont en cours d’initiation. Typiquement, lorsqu'une organisation entame une transition agile, nombreux sont les managers qui ne sont pas embarqués au démarrage, et qui seront malgré tout impactés par cette transformation. Avec pour conséquence, la collision entre plusieurs modes de fonctionnement rarement compatibles….
Le PPO a un vrai rôle à jouer dans la conduite du changement, que ce soit auprès des managers, des sponsors ou autres parties prenantes. Il se fera l'interprète des différents interlocuteurs, pour tenter d’aligner des points de vue parfois totalement opposés.
Attention à ne pas se substituer au SM, lui-même en première ligne pour expliquer les bénéfices de l’agilité au sein d’une organisation. Ces deux rôles se complètent très bien sur ce sujet, en s’adressant notamment à des populations différentes.
Enfin, un PPO doit toujours rester conscient de son implication :
IL NE DOIT PAS prendre entièrement à sa charge un autre rôle de l'équipe, spécifiquement celui du PO. Un PPO dont le travail couvre la quasi-totalité de celui du PO, aurait toutes les raisons d’être officialisé à sa place. De même, un PPO à qui on aurait délégué la rédaction, priorisation et validation des US, aurait la légitimité d’assumer entièrement le rôle de PO.
IL NE DOIT PAS palier les dysfonctionnements d'une équipe agile. Les problèmes identifiés doivent être réglés et non contournés (tâche qui revient essentiellement au SM). Ce point est important puisqu’au lieu d’apporter une complémentarité, ce type de PPO va introduire quelques biais :
- Empêcher l’équipe de s’améliorer sur ce qui lui fait défaut
- Induire une variabilité sur les bonnes pratiques
- Retirer de la visibilité sur les possibles dérives
- Endosser un rôle sans réelle valeur ajoutée…
Un Coach Agile est souvent dépositaire d’un mandat pour l’accompagnement d’équipes ou personnes différentes, suivant un mode d’intervention cadré en amont. A l’instar d’un contrat de coaching, il serait intéressant d’expliciter ce qui est attendu d’un nouveau PPO, au travers d’un document rédigé conjointement avec son équipe : périmètre, temporalité, objectifs, indicateurs, moyens… Ce qui permettrait ainsi de concentrer ses efforts sur les priorités qui lui sont données.
Une diversité de qualités et de compétences
Devenir un bon PPO nécessitera un savant mélange de relationnel, d’adaptabilité et de compréhension de son environnement, avec une bonne capacité à jongler entre différentes postures. Sans être excellent partout, son panel de compétences se révélera riche et varié. Parmi les plus pertinentes, on attendra de lui :
- Un relationnel passe-partout
- Des aptitudes à la négociation
- Être réactif, disponible, à l’écoute
- Une bonne dose de culture agile
- Quelques compétences techniques
- Un bon sens d’analyse et de synthèse
- Patience, persévérance et proactivité
- Parler un anglais respectable…
Il n’existe pas d’archétype formel de PPO, c’est un rôle à construire et à conjuguer avec le contexte, les besoins, les contraintes et les forces en présence. Attention toutefois à ne pas s’engager sur des voies ou des champs d’action qui ne conviendraient pas, ou qui nécessiteraient une montée en compétence trop importante.
Proxy or not Proxy
Le binôme PO/PPO est un atout indéniable dans une équipe agile, à condition de clarifier et respecter le périmètre et les redevabilités de chacun. Il devient alors indispensable de mettre en place un point de synchro régulier, pour garder le même niveau d’informations et discuter des actions en cours.
Le PPO joue un rôle important dans la communication entre les membres de son équipe, mais aussi entre l’équipe et son écosystème. Sans être expert de l’organisation ou de la technique, il aura un regard avisé sur des situations qui peuvent parfois sembler obscures aux autres.
De plus en plus, le rôle de PPO a tendance à se confondre avec celui de Business Analyst (BA) ou Agile Business Analyst (ABA). Les différences entre les deux restent suffisamment minimes, pour ne pas les voir évoluer conjointement dans une même structure (c’est avant tout une question d’appellation).
L’avènement de l’agilité à l’échelle promet aussi de donner plus d’envergure à ce rôle mésestimé, avec une transversalité plus importante et des challenges toujours plus grands.
En définitive, le PPO, pas aussi “Proxy” qu’il en a l’air...