Être Proxy-Product Owner, c’est grave docteur ?
Le rôle de "Proxy-Product Owner" (PPO dans le jargon, "Presque Product Owner" comme dit sous le manteau par les mauvaises langues…) est de plus en plus présent dans les organisations menant une transformation agile de leur DSI. C’est à travers une métaphore ludique que nous allons tenter de répondre à la question : “Être Proxy-PO, c’est grave docteur ?”
Le Proxy-PO, ce rôle qui n’existe pas dans Scrum
Les symptômes
Vous êtes une équipe agile qui suit le framework Scrum. L’équipe est en souffrance et les résultats espérés ne sont pas au rendez-vous. C’est une évidence : quelque chose cloche ! Vous auscultez donc l’équipe et identifiez ce qui pourrait être l’une des causes du problème : il y a un corps étranger au sein de l’équipe, le Proxy-PO. En effet, après vérification dans la littérature Scrum, ce rôle n’existe pas…
L’avis doctissimo
Souhaitant en savoir plus sur ce rôle, vous vous précipitez sur les forums pour recueillir l’avis de la communauté : le doctissimo de l’agile ! Les premiers avis ne se font pas attendre :
“Votre équipe est à l’agonie, le guide méthodologique Scrum n’est pas respecté !”“C’est un symptôme évident d’une rechute dans la gestion de projet non agile !”“C’est au Product Owner de faire ce travail ! Pas besoin de Proxy-PO !”“Votre produit va mourir !!!”
Ces retours sont assez effrayants et vous hésitez un instant à pratiquer une opération à cœur ouvert pour extraire ce Proxy-PO de l’équipe…
L’avis du médecin
Afin d’opérer cette “ablation” dans de bonnes conditions, vous consultez un spécialiste et en profitez pour confirmer avec lui le bien fondé de cette opération. Et il se trouve que son avis est plus modéré, il vous explique même que dans certains contextes, ce Proxy-PO peut être bénéfique. Il vous cite d’ailleurs un passage du Scrum guide pour le mettre en perspective…
“Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’équipe de Développement. Toutefois, le Product Owner en demeure responsable.” [Scrum guide 2017]
Ainsi, seule une observation terrain du contexte peut permettre de définir si ce rôle de Proxy-PO aide, ou non, à la réussite du produit.
Étude de cas cliniques
Afin d’illustrer ce propos, voici différents cas cliniques que ce médecin a eu l’occasion de traiter. Bien évidemment, secret médical oblige, les noms des patients ont été changés dans un souci d’anonymat.
Le Proxy-PO, assistant respiratoire du PO
“Je suis Proxy-PO au sein d’une équipe Scrum de 8 développeurs. Mon rôle consiste à garantir que l’équipe comprenne correctement les items à réaliser ainsi que de valider ces items une fois développés. Notre PO enchaîne les ateliers métier, points de suivis avec les parties prenantes et autres réunions, aussi il m’arrive d’être en manque d’informations pour rédiger les stories du backlog.” [Julie F., Proxy-PO]
Diagnostic du médecin
Le PO maîtrise les enjeux et le context business : il a la légitimité pour définir le besoin, procéder aux arbitrages et décider des orientations du produit. Toutefois il n’est pas toujours suffisamment disponible pour pleinement assumer son rôle auprès de l’équipe, et peut déléguer cette partie de son rôle à un tiers.
Dans ce cas de figure, le Proxy-PO se fait la voix du PO auprès de l’équipe et lui porte la vision produit. Il partage le besoin auprès de l’équipe et est garant de la bonne compréhension des items du backlog engagés dans le Sprint. Il aide l’équipe à la réalisation d’un incrément de qualité et valide au fil de l’eau les items réalisés.
C’est un cas de figure qui peut fonctionner à condition que le Proxy-PO soit aligné avec le PO sur la vision produit et dispose du mandat pour prendre des décisions sur les items en cours de réalisation, tels que leur priorisation ou leur validation.
Attention aux possibles effets secondaires
Certains Proxy-PO dont le temps est dédié à s’assurer que la team comprenne le besoin se transforment parfois en “scribes” ayant pour occupation principale l’écriture de User Stories… On perd ainsi d’ailleurs l’intention originelle de la Story : exprimer le besoin en le racontant (en contant une problématique utilisateur et la solution qui va améliorer sa vie).
Si le PO ne dispose pas du temps nécessaire pour interagir avec l’équipe, et que le Proxy-PO ne l’accompagne pas sur certains ateliers clefs, les items présentés à l’équipe risquent d’être une interprétation biaisée du vrai besoin.
Le Proxy-PO en symbiose avec le PO
“En tant que Proxy-PO, je binôme les ateliers métier et les événements Scrum avec le PO. Les sujets métiers sont assez pointus et demandent beaucoup de travail avant de fournir à l’équipe des items “ready for Sprint”. Bien que nous soyons deux, nous sommes surchargés et avons du mal à nous organiser pour être plus efficaces et enfin sortir la tête de l’eau” [Kilian G., Proxy-PO]
Diagnostic du médecin
Le PO et son Proxy-PO sont en symbiose et travaillent de concert sur les différents sujets du produit. C’est un cas intéressant qui permet à chacun d’entre eux de bien couvrir les aspects métiers du produit, et en cas de nécessité, le Proxy-PO peut pallier une absence du PO (et oui… le PO a lui aussi droit à des congés, voire même de tomber malade…).
Au regard de la charge de travail présentée sur ce contexte, il serait intéressant que tous les ateliers ne soient pas obligatoirement binômés. Dans le cas où votre proxy-PO dispose des compétences requises, il peut devenir le porteur d’un des pans métiers du produit. Il pourra ainsi s’occuper des ateliers métier de ce pan, ainsi que des stories correspondantes. Cela permettra d’éviter d’être en doublon sur tous les ateliers.
Déléguer, communiquer et partager seront les maîtres-mots de cette relation. Dans cette configuration, chacun présentera à l’équipe de réalisation les sujets qu’il maîtrise le mieux afin de s’assurer de la bonne compréhension de ceux-ci. Savoir déléguer un périmètre fonctionnel plutôt qu’un type d’activité présente de nombreux avantages :
- moins de changements de contexte et donc moins de charge mentale ;
- une responsabilisation du Proxy-PO et donc un meilleur engagement ;
- un regain de lien avec l’équipe de la part du PO : on évite la séparation “PO pour le métier” & “Proxy-PO pour l’équipe” qui rappelle les silos MOA-MOE du cycle en V.
Seuls certains ateliers nécessitent la présence commune du PO et du Proxy-PO. Pour les autres sujets, la mise en place de points de synchronisation ciblés et efficaces permettront d’assurer la cohérence globale du produit (des ateliers BDD seront un temps adéquats et efficaces pour mixer partage d’informations et avancée des sujets).
Attention aux possibles effets secondaires
PO et Proxy-PO auront des responsabilités similaires sur des périmètres distincts, il ne faut donc pas perdre de vue la vision produit dans son ensemble. Le PO en est le garant et c’est donc à lui que reviendra la décision finale s’il devait à un moment avoir une divergence d’opinion.
Le PO n’a pas l’obligation de tout connaître dans les détails. S’il n’arrive pas à lâcher prise sur le détail des éléments délégués à son Proxy-PO, non seulement il risque de ne pas prendre les bonnes décisions (n’ayant pas participé aux ateliers correspondants), mais surtout les points de synchronisation et le reporting va se démultiplier.
Le Proxy-PO mentor sur l’agilité
“Mon Product Owner vient du métier, c’est génial, il connaît parfaitement les difficultés quotidiennes de nos utilisateurs. Cependant, il n’a pas eu d’expérience concrète avec l’agilité avant ce projet, hormis une rapide formation à Scrum. Le Scrum Master de l’équipe nous épaule sur les événements et artefacts Scrum (tels que la review, les estimations relatives…), mais sa connaissance en profondeur de l’activité de PO est limitée. C’est donc moi qui fais monter en compétence le PO sur les méthodes de priorisation du backlog, la roadmap orientée impact, les ateliers de Story Mapping et autres ateliers de Design Thinking. C’est assez perturbant d’être plus calé que mon PO sur son nouveau métier, sans avoir le mandat de leader le produit.” [Jean-Luc V., Proxy-PO]
Diagnostic du médecin
Certains PO ne sont ni habitués aux méthodes agiles ni au monde de l’IT (surtout si, historiquement, l’organisation était silotée). Dans ce contexte, il peut être très intéressant que le PO soit accompagné par un mentor sur la méthode. Un consultant externe ne connaissant pas le métier de l’entreprise, mais expert sur le rôle de PO, peut dans ce cas être un choix judicieux.
Il appartient au Scrum Master de faire monter en compétence le PO sur son rôle (notamment le management de backlog produit), cependant celui-ci n’a pas forcément vocation à connaître les techniques d’idéation tels que le "Design thinking", "Design Durable", les interviews utilisateurs, etc. Dans le cas présent c’est le Proxy-PO qui, en plus d’assister le PO dans ses tâches quotidiennes, apporte le bagage méthodologique permettant de nourrir le backlog de façon agile (nota : ce rôle est parfois nommé différemment, tel “coach produit”).
Au début, le PO sera expert sur le métier et le Proxy-PO expert sur la méthode. Au fil du temps et de leur montée en compétence réciproque on pourra soit :
- arriver au cas de symbiose PO & Proxy-PO si la quantité de travail nécessite 2 personnes ;
- avoir un PO autonome pouvant gérer seul le travail de Product Ownership et un Proxy-PO voguant vers de nouvelles aventures.
Attention aux possibles effets secondaires
Le Proxy-PO va permettre au PO de monter en compétences sur les outils, pratiques et mindset nécessaires à la gestion agile de produit. Il faudra cependant veiller à ce que le PO ne se désengage pas, sous couvert que son Proxy-PO peut faire le travail à sa place : c’est au PO de rester garant de la réussite de son produit.
De même il ne faut pas que, de part son expertise éprouvée, le Proxy-PO “pour aller plus vite et réussir le projet” prenne le lead. Le produit a une vie après le projet et un PO interne lié au métier est la meilleure personne pour garantir la pérennité de ce produit.
Un PO et des Proxy-PO pour un produit à l’échelle
“Je suis la Proxy-PO d’une des 5 équipes travaillant sur un des pans fonctionnels d’un produit en pleine expansion. Je réalise les ateliers d’idéation avec les métiers et m’assure que l’équipe ait tous les éléments pour bien réaliser notre partie du produit. Le Product Owner, en plus d’assurer la vision transverse, leade lui aussi sa propre équipe dédiée à l'un de ces pans fonctionnels. Mon seul souci se trouve sur l’aspect priorisation : je ne suis pas toujours en accord avec le PO...” [Sabrina T.]
Diagnostic du médecin
Lorsque plusieurs équipes travaillent de concert sur un même produit, le Product Owner se trouve vite dépassé : il n’a pas la bande passante nécessaire pour réaliser tous les ateliers métiers, ni pour pouvoir communiquer de façon efficace avec ces différentes équipes. Dans ce cas, il est intéressant d’adopter un pattern de délégation par domaine fonctionnel : c’est d’ailleurs le pattern proposé dans le Framework Large Scale Scrum (LeSS), avec son PO et ses “Area Product Owner”.
Nous avons dans le cas présent un aspect très intéressant : le Product Owner réalise aussi un travail opérationnel avec son équipe, au même titre que les Proxy-PO des 4 autres équipes. En effet, il n’y a pas d’obligation à cantonner le PO à un travail “stratégique” de priorisation transverse qui laisserait le travail opérationnel à 5 Proxy-PO (bien que ce découpage soit souvent utilisé).
Il est important que le produit garde sa cohérence globale. Ainsi, même s’il y a plusieurs pans fonctionnels, il ne doit exister qu’un seul et unique backlog produit. Celui-ci sera alimenté par les différents ateliers métier et priorisé en un tout.
Attention aux possibles effets secondaires
Il pourra parfois arriver qu’un pan fonctionnel du produit ne soit plus la priorité produit à traiter. Et dans ce cas, plutôt qu’une équipe continue de porter ses efforts sur son domaine d’appétence, il serait intéressant de la faire contribuer à un autre pan fonctionnel plus prioritaire. Les équipes ne doivent pas devenir des silos fonctionnels pour le simple intérêt de leur productivité sur ce sujet : on cherche à produire plus de valeur et non plus de fonctionnalités.
Dans le cas d’un PO qui ne s’occuperait que de la vision stratégique et de la priorisation transverse, il faudra faire attention à ce qu’il ne devienne pas un PO “stratosphérique” qui décrocherait de la partie delivery.
La prescription
Les antibiotiques c’est pas automatique !
Ainsi que le précise le Scrum guide, les responsabilités du Product Owner peuvent être déléguées.
“Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’équipe de Développement. Toutefois, le Product Owner en demeure responsable .” [Scrum guide 2017]
Au plus simple, certaines de ses responsabilités sont déléguées au rôle “dev-team member” ; parfois, un rôle spécifique peut être créé pour les gérer. Que ce rôle soit nommé Proxy-PO ou d’un autre nom importe peu, ce qui est important c’est d’être bien certain qu’une même responsabilité :
- ne soit pas gérée en doublon par 2 rôles distincts
- soit gérée par un rôle, et éviter que chacun suppose qu’elle incombe à un autre…
Votre prescription : un atelier rôles et responsabilités !
Donc du coup, il est préférable de garder son Proxy-PO ?
Il faut que son existence soit le résultat d’un vrai choix et réponde à un réel besoin. Dans trop d’organisations, on pourvoit dans une équipe tous les rôles “potentiellement” utiles. La bonne démarche consiste à les créer au besoin, et surtout à oser les supprimer lorsqu’ils ne font plus sens (suite à une rétrospective par exemple).
Vous souhaitez en savoir plus ?
Merci à tout le personnel hospitalier
Encore à merci à tous nos “infirmiers” pour leurs anecdotes et retours d’expériences terrain. Ils ont grandement contribué à enrichir nos réflexions et discerner les patterns récurrents.
© SOAT
Toute reproduction interdite sans autorisation de l’auteur.