De plus en plus important au sein des équipes agiles, le rôle du Proxy Product Owner (PPO) n’est pas défini dans la méthode classique de l’Agile Scrum. Ce rôle a été créé ad hoc pour répondre aux besoins de soutien du Product Owner (PO) pour des programmes et projets Agiles au sein d’organisations complexes.
En effet, le Product Owner a un rôle central dans les équipes Scrum. Il est responsable de la vision du produit, construite et alimentée par les besoins des utilisateurs et la stratégie de l’organisation, ainsi que de la gestion du backlog en lien avec l’équipe de développement pour concrétiser les solutions à développer.
Voilà pour la théorie du PO ; dans les faits, que ce soit dans des organisations complexes ou sur des projets et produits composés de plusieurs solutions techniques et services métier, le PO, qui est un représentant métier, voit sa charge augmenter. Entre la gestion des nombreuses parties prenantes et la préparation des instances internes, le PO est rarement dédié – et n’a que peu de temps à dédier – à l’opérationnel. C’est pour cela que le PPO, ou Proxy Product Owner, est un nouveau rôle indispensable : le bras-droit du PO.
Le PPO a pour mission de décharger le PO d’une partie des tâches très opérationnelles (gestion du backlog, suivi rapproché avec les équipes de développement…). Il fait partie intégrante de l’équipe Scrum, en binôme avec le PO. Il est à l’interface entre les utilisateurs, les métiers et les équipes techniques.
Nos expert·e·s PPO Saegus Jean-Baptiste, Consultant Senior, et Marouchka, Manager Acceleration Tactics, répondent à nos questions pour y voir plus clair sur ce rôle qui s’est imposé nécessaire dans beaucoup de grandes organisations.
#1 Concrètement, quel est votre rôle au quotidien chez votre client ?
Déjà, le PPO doit comprendre et préciser les besoins des utilisateurs et gérer le backlog du projet sur lequel il est impliqué. Il doit produire et ajuster tous les éléments nécessaires (epics, user stories, tâches…) pour répondre à la vision des prochains sprints.
Par exemple, chez notre client actuel nous contribuons à la mise en place d’un outil de gestion de portefeuille de projets. Celui-ci doit notamment permettre à divers métiers de renseigner des projets et études prévisionnels puis de les mettre à jour au gré de leurs concrétisations. Des formulaires, des tableaux de suivi et des interfaces de paramétrage ont donc été développés.
Pour ces fonctionnalités, il a fallu préciser le besoin des métiers, la manière d’intégrer les formulaires et tableaux à l’outil existant, la manière dont les informations doivent être liées avec d’autres systèmes de gestion des données, mais aussi prendre en compte leur adoption et leur intégration aux usages des métiers.
Une fois le contexte des métiers compris, il faut traduire les solutions à mettre en place sous forme d’user stories permettant d’alimenter le backlog du produit. Ce travail hebdomadaire génère des dizaines d’user stories, voire des centaines.
La méthode d’Agile Scrum reposant sur des cycles courts et itératifs de développement, appelés Sprints, toutes ces US ne peuvent être développées en même temps. En tant que PPO nous participons à la priorisation des US à intégrer à lors des itérations de l’équipe. C’est un rôle qui permet d’avoir une vision d’ensemble sur tout ce qui est en cours de développement et à venir.
Pour chaque itération nous suivons la réalisation avec l’équipe de développement et en interaction avec les métiers. Nous coordonnons ensuite les tests avec les métiers pour valider la bonne réalisation de chacune des user stories.
Le PPO coordonne les sprints de l’équipe de A à Z en collaboration constante avec le PO. Le Product Owner se concentrant généralement essentiellement à la définition de la vision et la stratégie du produit, ainsi qu’au cadrage des besoins avec les métiers, là où le PPO est davantage engagé dans les tâches plus opérationnelles du cadre de travail Agile.
#2 Quels challenges rencontrez-vous à travers vos différentes missions ?
Les challenges sont multiples ! D’abord, puisque c’est une fonction en interaction avec les métiers d’une part et avec les équipes de développement d’autre part. Il faut d’abord comprendre les besoins, attentes et contraintes de ces parties prenantes essentielles au projet. Il faut réussir à adopter un langage et des codes adaptés à chacune d’entre elles.
Le deuxième challenge, c’est de réussir à faire comprendre les besoins métiers aux équipes de développement, et inversement de présenter aux métiers les réalisations des équipes de développement, ainsi que les limites et les difficultés rencontrées liées, par exemple, aux contraintes des outils ou des écosystèmes IT de l’entreprise.
Enfin, il y a un sujet de légitimité : le PPO doit faire en sorte que son rôle de coordination et de support soit bien compris étant donné qu’il ne produit pas les solutions présentées aux utilisateurs et qu’il n’a pas toujours la réponse aux questions posées par les métiers (notamment sur les sujets très techniques).
Pour éviter toute incompréhension, la règle d’or est de communiquer régulièrement sur le fonctionnement de l’équipe Scrum et les rôles de chacun.
#3 Pourquoi le rôle de PPO est de plus en plus présent dans les projets en agile ?
Historiquement, sur le framework Scrum, le Product Owner est responsable de la vision du produit auprès de son équipe et ses sponsors ainsi que de la gestion du backlog.
Dans les grandes organisations, ou sur des produits et programmes avec plusieurs solutions technologiques et services, le Product Owner est rarement dédié à 100% à cette fonction. Il a également la charge de tâches et missions qui lui incombent sur d’autres dimensions de son poste. Il lui est donc difficile de gérer les aspects opérationnels du rôle de PO.
Le PPO a donc pour fonction de suppléer le PO sur les aspects les plus opérationnels de ses attributions.
D’autre part, les principes de l’agilité et la méthode Agile Scrum sont adoptés progressivement dans des organisations dont le cœur de métier est éloigné du digital et dont les héritages culturels et organisationnels liés aux méthodes antérieures de gestion de projet restent forts.
Ainsi, pour favoriser le fonctionnement en mode agile dans ces organisations complexes, le rôle de PPO, complémentaire à ceux de la méthode Agile Scrum, est nécessaire.
#4 Quelles sont pour vous les trois qualités d’un bon PPO ?
La première qualité, sans hésitation, c’est la diplomatie ! Face à des métiers qui ont des demandes parfois complexes voir techniquement irréalisables, il faut savoir trouver des solutions pour répondre à leurs besoins en prenant en compte les contraintes techniques. Notre rôle est de « comprendre et faire comprendre » les enjeux, les besoins, les contraintes de l’ensemble des parties prenantes du projet, en prenant le temps de valoriser l’implication de chacun.
Ensuite, il faut faire preuve de multidisciplinarité. Le PPO doit à la fois comprendre le besoin de métiers éloignés du sien, le point de vue – souvent très technique – des développeurs ainsi que les bonnes pratiques UX/UI issues du design pour faire la synthèse des solutions à mettre en place.
La dernière qualité est forcément la rigueur : c’est à lui de gérer le backlog, afin que les US soient claires et compréhensibles pour les développeurs et les testeurs de l’équipe produit. Sans rigueur, le PPO ne peut remplir sa mission d’intermédiaire et de facilitateur.
#5 Quels outils utilisez-vous au quotidien ?
D’un point de vue général, nous privilégions des outils agiles tels qu’Azure DevOps ou Jira d’Atlassian, mais certaines missions peuvent également nous contraindre à utiliser des outils internes aux entreprises. Le PPO doit d’ailleurs assurer la migration d’un outil vers un autre lorsque cela est nécessaire. C’est par exemple le cas chez notre client actuel, pour qui nous assurons la migration de l’équipe et du backlog sur ServiceNow.
Ce qui reste primordial est qu’il faut des outils adaptés, pensés pour une gestion agile, pas des outils détournés pour ce genre de gestion. En plus du backlog, l’outil doit aussi par exemple permettre de stocker la documentation technique ou de stocker les maquettes métiers. Il nous arrive donc parfois d’utiliser plusieurs outils pour un même projet : par exemple, une équipe collaborative permettant la gestion documentaire, comme Teams, est indispensable !
Conclusion
Pour conclure, le rôle de PPO est un rôle multifacette. En interaction avec les parties prenantes d’une mission en agile, il doit être capable de comprendre les besoins des utilisateurs tout en communiquant avec les équipes de développement, et de porter les messages du PO lorsque cela est nécessaire.
C’est un rôle que nous conseillons à toute personne qui fait de l’agile pour comprendre l’ensemble des processus, apprendre à utiliser de nouveaux outils et s’adapter à un environnement complexe.
Envie d’en savoir plus sur le rôle ou de rejoindre les équipes Saegus ? N’hésitez pas à nous contacter ! Et retrouvez toutes les offres disponibles ici : https://bit.ly/3mZjDZM.