Méthodes Agiles – Qu’est ce qu’un PO Proxy ?

Le sujet du « PO Proxy » revient assez souvent dans les discussions autour des méthodes Agiles et SCRUM en particulier. Certains considèrent que ce rôle, n’existant pas dans la méthodologie SCRUM, n’a aucune raison d’être. D’autres disent que ce rôle peut se justifier au cas par cas. D’autres iront même jusqu’à considérer que sa présence est indispensable dans les organisations qui ne sont pas Agiles « du sol au plafond ».

Cependant, bien que le sujet revienne régulièrement sur la table, la littérature disponible sur le sujet est assez limitée, et il n’existe pas de définition exacte de ce qu’est un PO Proxy.

Cet article se propose donc, en se basant sur des observations de terrain, d’essayer de définir ce que peut être un PO Proxy en jugeant sa pertinence en fonction des contextes.

Préambule rapide : Agile ? PO ?

Ces méthodes induisent une transformation des rôles au sein des projets, illustrée par le tableau suivant :

Pour compléter, le rôle du Product Owner (PO) qui est central dans la méthode est très bien décrit dans la vidéo suivante :

Pourquoi un PO Proxy ? Quel est son rôle ?

Au vu des responsabilités qui incombent au Product owner, le candidat idéal pour remplir ce rôle est généralement un Manager côté Métier, qui possède à la fois une maîtrise parfaite du contexte et des enjeux du projet, tout en ayant la légitimité suffisante pour porter la vision et procéder aux inévitables arbitrages lors du projet.

Or les Managers ont rarement la disponibilité requise (à minima 30% d’un temps plein, avec idéalement une présence physique quotidienne auprès des développeurs) pour mener à bien un projet Agile. D’où l’émergence assez répandue d’un rôle supplémentaire, absent de la théorie Agile ; celui de PO Proxy, dont la définition peut se résumer à « combler le manque de disponibilité du PO en formant un binôme avec ce dernier ».

Voyons donc les différentes configurations de binômes rencontrées sur le terrain :

1ère configuration : Y a-t-il un PO dans l’avion ?

La 1ère configuration est celle où le PO nommé maîtrise parfaitement le contexte et les enjeux du projet, a la légitimité pour prendre des orientations et procéder à des arbitrages pendant le projet… MAIS n’a absolument pas la disponibilité pour assumer son rôle. Un PO Proxy est alors nommé pour être l’interlocuteur quotidien de l’équipe de développement à la place du PO. Le terme « PO Proxy » vient du fait que ce dernier devient l’intermédiaire entre l’équipe de développement et le PO (comme le Proxy informatique entre le réseau interne de l’entreprise et Internet), ces derniers n’ayant plus d’échanges directs (à l’exception des Sprint Planning / Sprint Reviews éventuellement).

C’est une configuration souvent rencontrée dans les organisations qui se lancent dans l’Agile sans avoir complètement intégré la philosophie sous-jacente. Ces organisations se tournent vers l’Agile en pensant que cette façon de faire va répondre à leurs problématiques de réactivité et d’adéquation aux besoins utilisateurs, mais elles oublient le principe fondamental de la réussite des projets SI, à savoir une forte implication Métier.

Compte tenu de la disponibilité quasi nulle du PO nommé, cette configuration revient à avoir un « vrai PO » (au sens de la méthode) qui est le PO Proxy. Le PO nommé initialement ne sera en définitive qu’une partie prenante du projet, qui s’exprimera principalement lors des revues de sprint (s’il est présent).

Dès lors, la réussite du projet va dépendre de la capacité du PO Proxy à endosser le rôle du PO

• Si ses choix ne correspondent pas aux attentes des parties prenantes (et en particulier celles du « PO »), le projet court à l’échec car ses décisions seront constamment remises en cause à la fin des Sprints.
• Si ses choix sont les bons, et surtout s’ils sont bien communiqués et compris, le projet sera une réussite… que le PO saura valoriser auprès des autres équipes. Dans ce cas de figure il est important d’être conscient que le vrai PO a finalement été le PO Proxy ; car lancer un nouveau projet avec le PO absent pourra facilement se transformer en échec si le casting du PO Proxy n’est pas aussi bon…

Cette configuration amène naturellement à dire que le rôle de PO Proxy n’existe pas, puisque du point de vue de l’équipe de développement, il n’y avait bien qu’un PO (la question de sa compétence dans le rôle étant un autre sujet).

Voyons donc si d’autres configurations existent.

2ème configuration : Le binôme équilibré (« PO Stratégique » et « PO opérationnel »)

Cette configuration consiste en un binôme équilibré en terme de disponibilité et permet de s’approcher de l’idéal de disponibilité du PO sur un projet, c’est à dire 1 ETP. On rencontrera souvent une répartition du type 20-30% de disponibilité pour le PO et 70-80% pour le PO Proxy, mais une répartition 50-50 peut aussi arriver.

Dans cette configuration le PO (« PO Stratégique ») porte la vision du produit et prend les décisions les plus importantes. Il est également présent quelques demi-journées par semaine sur le plateau projet, au contact de l’équipe, pour répondre aux questions des développeurs. Il procède également aux recettes des stories pendant le Sprint (à minima, les plus importantes), au fil de l’eau des livraisons de l’équipe. Il est bien entendu présent aux Sprints plannings et Sprints reviews.

Le PO Proxy (« PO Opérationnel ») quant à lui, est davantage présent sur le plateau projet. Il répond à la majorité des questions des développeurs, procède à l’ensemble des recettes, et maintient à jour le Backlog Produit (rédaction des user-stories, des axes d’acceptance, des personas, etc.) ainsi que la documentation nécessaire à l’équipe (description des règles métiers, éventuellement maquettes des IHM attendues, etc.)

Ce binôme, équilibré sur le papier, peut aussi bien être une réussite qu’un échec. Pour que ce type de binôme fonctionne, il est impératif que le PO et le PO Proxy partagent parfaitement la vision du produit attendu, et que les décisions de l’un ne soient pas remises en cause par l’autre le jour suivant. Il est en outre primordial que les 2 acteurs répartissent de manière intelligente leurs plages de disponibilité pour que l’équipe ait quotidiennement un référent (il est en effet peu productif d’avoir le PO et son Proxy disponibles tous les deux le lundi et le vendredi toute la journée, et un trou de disponibilité pour l’équipe du mardi au jeudi)

3ème configuration : Le PO Proxy « double action »

Il existe une dernière configuration rencontrée sur le terrain, qui met le PO Proxy dans un rôle hybride de complément aux rôles du PO et du Scrum master.

Pour rappel, le Scrum master est responsable à la fois :

• de la bonne application de la méthode SCRUM par l’équipe
• du maintien de bonnes conditions de travail pour l’équipe (éviter les perturbations externes, lever les obstacles au bon déroulement du projet)

Or, dans certaines organisations, le Scrum Master peut ne pas avoir les leviers pour lever les obstacles, notamment lorsque ces derniers sont organisationnels et que leur levée nécessite une connaissance fine de l’organisation et une disponibilité élevée (un Scrum master peut être impliqué sur plusieurs projets à la fois).

Je pense notamment à la situation où l’équipe Agile est en interactions avec plusieurs équipes « non Agiles » de la DSI (l’équipe d’exploitation, la sécurité, les architectes, ou d’autres équipes de développement calées sur le modèle « cycle en V »). Mobiliser et coordonner l’ensemble de ces acteurs peut nécessiter une connaissance approfondie de la DSI et de ses procédures ainsi qu’une charge importante de travail.

Un PO Proxy qui connaît bien les rouages organisationnels de la DSI et de l’entreprise et qui forme un binôme équilibré avec un PO disponible et bien dans son rôle, peut alors avoir la disponibilité pour agir sur les problèmes bloquants du projet (organiser des réunions de travail avec les bons acteurs, escalader si besoin auprès des bonnes personnes, anticiper les demandes techniques, etc.) en soutien à l’équipe et au Scrum master.

Le PO Proxy forme alors un trio avec le PO et le Scrum Master, et joue un rôle de fluidification du projet sur les 2 tableaux : Métier et SI.

Conclusion :

La théorie Agile veut qu’il n’y ait qu’un seul maître à bord : le Product owner. Ceci dans un souci de simplicité et d’efficacité des échanges au sein de l’équipe. Cependant la philosophie Agile prône une application pragmatique de la méthode.

L’application « by the book » n’a aucun intérêt : il faut faire ce qui fonctionne et cela peut être différent au sein de chaque organisation.

Le rôle de PO Proxy, même s’il n’existe pas dans la méthode, est donc acceptable. Il reste cependant absent de la théorie, car c’est un rôle à géométrie variable nécessitant des compétences différentes selon le contexte, allant d’une pure connaissance Métier (lorsque le PO Proxy joue le rôle de complément du PO) à un mix Métier / SI (lorsque le PO Proxy complémente à la fois le PO et le Scrum master)

Ce qui nous ramène à l’un des facteurs clés de succès de tout projet Agile : la réussite du casting sur chacun des rôles !

Le PO Proxy ne doit pas être propulsé dans une équipe déficiente en espérant qu’il redressera à lui seul la barre… L’équipe doit être pensée dans sa globalité pour être efficace et chacun doit avoir la disponibilité nécessaire pour assurer son rôle.

Nicolas Montens

Nos autres articles sur les méthodes agiles :

Méthodes Agiles – quelles leçons tirer de leur utilisation ?

Les développements agiles sont-ils plus rapides ?