Si le rôle du Product Owner (PO) est cadré et clairement défini par le Scrum Guide, celui de Proxy PO n’y est pas mentionné. Il est pourtant relativement répandu dans les équipes Scrum, mais souvent décrié ou critiqué dans la littérature agiliste. Posons-nous la question de la légitimité de ce rôle, de son utilité dans une équipe Scrum et de ses relations avec le PO.
Le PO, son rôle, sa définition
Pour commencer, reprenons les bases, le Scrum Guide 2020 et sa définition du Product Owner :
« Le PO est responsable de maximiser la valeur du produit résultant du travail de la Scrum Team. [..] Le PO est également responsable de la gestion efficace du Product Backlog qui comprend :
- Développer et communiquer explicitement l’Objectif de Produit ;
- Créer et communiquer clairement les éléments du Product Backlog ;
- Ordonner les éléments dans le Product Backlog ; et,
- S’assurer que le Product Backlog est transparent, visible et compréhensible. »
Dans l’équipe projet, le PO représente donc le produit, le « quoi » et même le « pourquoi » du projet, la partie technique étant portée par l’équipe de développement et le Scrum Master facilitant les aspects organisation et amélioration continue.
Le PO doit apporter la vision produit : il comprend et analyse le besoin client, il le traduit, l’exprime et le partage à l’ensemble de l’équipe. Il a une bonne connaissance des enjeux stratégiques, des attentes du client ou des utilisateurs. Il peut affiner les objectifs sans les dénaturer, il comprend les besoins sans les interpréter et les retranscrit parfaitement. Il doit partager avec l’équipe les enjeux du projet, la vision et la valeur du produit.
Dans la pratique, il est l’unique responsable du Backlog Produit, il choisit les fonctionnalités à développer, il ordonne les éléments de Backlog et les priorise, il définit avec l’équipe l’objectif de chaque sprint.
Le PO doit donc être une personne expérimentée, disponible, organisée et avec de très bonnes compétences en communication. Il doit être présent au sein de l’équipe, pour répondre aux questions, donner des précisions.
Le Scrum Guide 2020 précise :
« Le Product Owner peut effectuer le travail ci‐dessus ou peut déléguer la responsabilité à d’autres. De toute façon, le Product Owner en demeure responsable. [..] Le Product Owner est une personne, et non un comité. »
Cette disposition permet d’accélérer la prise de décision, de donner à l’équipe de développement un seul interlocuteur au sujet du produit, un seul son de cloche et donc de garantir la bonne organisation et l’efficacité de l’équipe.
En revanche, il n’est pas interdit au PO de déléguer une partie de ses tâches à l’équipe, tout en demeurant le seul responsable. La Scrum Team pourra alors collectivement s’organiser pour qu’une personne réalise certaines tâches habituellement dévolues au PO, comme écrire les User Stories par exemple.
Un Proxy PO, pourquoi ?
Forts de cette mise au point, demandons-nous maintenant pourquoi le Proxy PO (PPO) émerge dans certaines équipes ? Quel est son rôle ? Pourquoi a-t-on eu besoin d’inventer un nouveau rôle que le Scrum Guide n’avait pas jugé utile ?
Mon expérience me pousse à affirmer une chose : une équipe, avant d’être une équipe Scrum, est d’abord une équipe agile, et donc une équipe qui cherche à fonctionner au mieux, en gardant l’humain au centre, pour livrer régulièrement des incréments d’un produit de très bonne qualité.
L’organisation, la méthodologie utilisée, le cadre de travail mis en place doivent être réfléchis, remis en question régulièrement et modifiés, remodelés si le besoin s’en fait sentir.
Si l’empirisme, porté par les piliers Inspection et Adaptation de Scrum, est à l’œuvre dans la partie développement du produit, je pense qu’il doit l’être aussi pour la partie organisationnelle de l’équipe. Pour moi, si le PO, en accord avec le reste de l’équipe, ressent le besoin de s’adjoindre une autre personne pour l’aider, si la décision a été prise collectivement, alors il faut essayer, puis se demander si c’est la bonne solution et en chercher une autre le cas échéant.
Certes, ce ne sera plus une équipe Scrum, puisqu’elle a dérogé au Scrum Guide, mais elle aura su se poser les bonnes questions et trouver le fonctionnement qui lui convient.
Qu’est-ce qui peut donc pousser une équipe Scrum, organisée selon le Scrum Guide, comportant une équipe de développement pluri-disciplinaire, un Product Owner et un Scrum Master, à adopter une personne supplémentaire et à lui donner le titre de Proxy Product Owner ?
Comme nous l’avons vu plus haut, le PO doit être expérimenté, disponible et bon communicant. Si l’une de ces trois qualités n’est pas sienne, on peut aisément concevoir qu’il aura besoin d’un adjoint. On peut dès lors imaginer de nombreuses situations : le PO est un nouvel embauché, il ne connaît encore pas très bien les rouages fonctionnels du service dans lequel il arrive, ou les partenaires à qui il doit s’adresser ; ou au contraire, le PO a une réelle maîtrise de tout l’éco-système de l’organisation, de ce fait il est sollicité comme expert sur d’autres projets et n’est pas disponible à plein temps auprès de son équipe projet ; ou encore le PO est un développeur de l’équipe, son temps est partagé entre le développement et la gestion du Backlog mais il n’a ni le temps ni l’envie de participer aux discussions avec les parties prenantes du projet…
Dans ces situations, le besoin d’intégrer une personne pour décharger le PO ou pour combler des manques est réel, et la solution de créer le rôle de Proxy PO dans l’équipe peut être envisageable.
Cependant, le PO « officiel » doit rester l’unique responsable du Backlog. Il aura la décision finale en cas de désaccords.
Parfois, les rôles peuvent glisser : un Product Owner qui prendrait tellement de responsabilités dans la définition du besoin, dans la partie marketing par exemple pourrait devenir alors une partie prenante du projet et laisser à son Proxy PO le rôle de PO ; ou bien si, comme plus haut, il est développeur et PO, il peut reprendre son rôle de développeur complétement et laisser le rôle de PO au Proxy PO. Mais il faut pour cela un accord concerté de l’ensemble de l’équipe car les relations entre tous ses membres, et les responsabilités de chacun s’en trouveraient chamboulées.
Le Proxy PO peut aussi être le bras droit du Product Owner. Si l’équipe entière pense qu’une personne supplémentaire, qui travaillera en complète collaboration avec le PO, aidera à livrer des incréments de valeur, alors pourquoi s’en passer ? Cependant, tous devront être attentifs à ce que le PPO ne devienne ni la secrétaire du PO qui ne fera qu’écrire les User Stories, ni le passe-plat qui ne sera qu’un éternel facteur entre l’équipe de développement et le PO. Pour qu’une telle organisation fonctionne, la collaboration devra être constante entre le PO et son PPO.
Mon analyse
En réalité, on peut constater qu’une équipe qui éprouve le besoin de recruter un Proxy Product Owner est dans le fond une équipe qui ne va pas si bien… L’important serait donc peut-être de se poser les bonnes questions pour remonter à la cause du problème : l’équipe est-elle trop grosse ? Le produit trop gros ? Que fait réellement le PO ? Peut-être n’est-il pas la personne la plus adéquate pour le poste ?
La question du Proxy PO a déjà fait couler beaucoup d’encre. C’est un sujet qui fait parler car chaque équipe doit trouver son fonctionnement optimal, en gardant en tête son but premier : livrer régulièrement et fréquemment un incrément de produit de qualité, ayant de la valeur pour les utilisateurs, et en s’enrichissant des feedback de tous.
Si l’intégration d’un Proxy PO aide à atteindre ce but, si le PO et le PPO travaillent main dans la main, avec la même vision produit et en symbiose, alors le rôle est, à mon sens, valable et utile.
En revanche, dès que des tensions émergent, ou que l’on sent que ce rôle n’a plus lieu d’être ou gêne l’équipe plus qu’il ne l’aide, il ne faut pas hésiter à le supprimer. Et donc à se séparer d’un membre de l’équipe.
En conclusion, vu que le rôle de PPO n’existe pas dans le framework Scrum, on peut évidemment dire qu’une équipe qui se dote d’un Proxy PO n’est pas une équipe Scrum.
A mon sens, je pense qu’il faut être un peu plus nuancé et admettre que l’important est que l’organisation de l’équipe fonctionne, et que si elle vient à ne plus fonctionner de manière optimale, il faut à tout prix remettre en cause cette organisation et chercher à en changer. Même si elle doit pour cela accepter de ne plus suivre le framework Scrum, de ne plus être une équipe Scrum.
par Cécile Vivant – Conceptrice Fonctionnelle à PROXIAD LYON
