Product Owner : attentes VS réalité

Qu’est-ce qu’un Product Owner ? Quel est son rôle et quelles sont les tâches associées à son poste ? Toutes ces questions ont déjà fait l’objet de nombreux articles sur la toile.

Il est donc assez aisé de se faire une idée rapide, de ce qu’est un PO (oui, appelons-le par son petit nom). Cependant, le rôle du PO est bien plus vaste et bien plus complet que ce que l’on peut lire. Il est changeant et différent selon les structures voire les entités au sein d’une même entreprise.

Le rôle du Product Owner vu au travers d’un projet précis respecte-t-il les préceptes théoriques de la méthode Agile et les différentes définitions que l’on prête à ce poste ?
Antoine et Divya sont tous deux Product Owners chez World of Digits. Et ils peuvent d’ores et déjà t’apporter une réponse (de normand) : cela dépend 😊. C’est le propre même de l’Agile.

Ainsi que de toutes les organisations qui mettent en place cette méthodologie de projet ou qui pensent la mettre en œuvre. Formés peu ou prou sur des bases communes, les PO ne se ressemblent qu’assez peu finalement. Ils s’adaptent, apprennent et se renouvellent constamment. À la limite de la schizophrénie. Et ce, quelle que soit leur formation, parcours ou expériences professionnelles.

La vision du Product Owner chez WOD

Chez WORLD OF DIGITS, on part du principe qu’il faut en tout cas maitriser ce cadre méthodologique théorique qui les gouverne tous : le manifeste Agile, et passer les certifications ou les formations qui en découlent.

Le Product Owner sait qu’il aura par ailleurs à animer ou à participer à des Daily Meetings, des Backlog Grooming, des Sprints Planning, des chiffrages, des rétrospectives et à écrire des US …

Il sait qu’il devra gérer tout cela selon le projet et le fonctionnement de l’équipe : internalisation des compétences ou fonctionnement en TMA, projet en Kanban ou projet en Sprint …

Pour conclure, il est difficile de définir très précisément le profil et le domaine d’intervention du PO, variable en fonction des organisations.

Ceci étant posé, on te propose de découvrir la vision de World of Digits du rôle de Product Owner au travers des différentes expériences professionnelles de Divya et d’Antoine au sein de notre cabinet. Bonne lecture !

ENGIE, Société Générale, Accor Hotels, AXA, SNCF, et Crédit du Nord. Voici les différents clients chez lesquels nous avons eu l’opportunité d’apprendre et pratiquer le rôle du PO. Six structures différentes pour autant de différences sur la vision du rôle du PO !

Product Owner – la fonction

Tout d’abord commençons par la dénomination même de ce poste.
Les missions liés au PO peuvent revêtir plusieurs noms selon les structures : Business Analyst (BA) ou Proxy Product Owner (PPO). De plus l’important est de regarder les attributions du rôle plutôt que la dénomination. Les définitions théoriques du rôle du PPO affirmeront qu’il est le « bras droit » du PO ou plus communément appelé « assistant chef de projet ». Mais cela dépend des tâches qui lui sont affectées et du rôle même du PO avec qui il travaille.

L’expérience PO chez WOD

Pour quels clients as-tu travaillé ?

Témoignage d’Antoine : « J’ai eu l’opportunité d’occuper le rôle de BA et celui de PO au sein d’AXA France. Tous deux sur des projets majeurs et critiques. En tant que BA, mon domaine d’intervention n’était finalement pas très éloigné de celui de PO. Je menais les principaux ateliers et rituels de la méthode Agile (avec l’équipe Scrum, avec le Métier ou avec d’autres parties prenantes).

Quelles sont les différentes responsabilités et tâches quotidiennes en tant que PO ?

Je me conformais aux tâches « classiques » d’un PO.
La différence résidait dans deux aspects.
Le premier étant le reporting. L’état d’avancement des projets était directement remonté au PO qui se chargeait de participer aux comités de pilotages et partageait les informations aux différents sponsors.
Le second aspect différenciant était la gestion budgétaire de l’équipe Scrum en lien direct avec la Product Manager.

Au sein de la SNCF et de la « Factory », sur le poste que j’occupe actuellement pour m’occuper du site sncf.com, le PO est, cette fois, le Métier (ou le Business Owner). Dans cette organisation, j’adopte le nom de « PPO » selon certains et de PO pour d’autres. J’ai en charge l’ensemble du pilotage du projet et du cycle de delivery des sprints.

La phase de cadrage du besoin et de définition des nouvelles fonctionnalités est à la charge de la « PO Métier ».
Cette structuration est totalement différente au sein d’une autre entité de la SNCF dans laquelle j’intervenais en tant que PO du Chatbot TGV INOUI. »

Le scope d’intervention d’un PO est donc variable en fonction de la structure, d’une entité voire même d’une équipe. PO, BA ou PPO, il reste quoi qu’il arrive l’unique garant de la qualité du produit délivré et l’intermédiaire de toutes les parties prenantes du projet. Et elles sont nombreuses.

Quelle est l’importance d’un Product Owner au sein d’une équipe agile  ?

Par ailleurs, le PO doit collaborer avec l’ensemble des compétences d’un projet Agile, tel que UX/UI Designer, développeur, testeur, Scrum Master, Business Owner, Product Manager. Chacune des visions viendra faire mûrir et évoluer le besoin. Chez Wolrd of Digits, nous sommes convaincus que la réussite du PO passe par cette approche interdisciplinaire. Il est le seul à avoir une vision à 360 degrés sur les différentes facettes du produit. Du marketing au design, en passant par l’ergonomie de son produit et les problématiques techniques, il est seul acteur transverse.

Pour mener à bien les phases de cadrage, de delivery voir de RUN, le PO anime et participe à un certain nombre de rituels Agile. Ces rituels sont désormais connus, pour la plupart. On ne présente plus les Daily Meetings (ou DSM), les Weekly Meetings, les Backlog Refinement (ou Backlog Grooming), les Story Mapping, les Sprints Planning, les chiffrages (ou Poker Chiffrage), les “démos”, les rétrospectives et on en passe 😊. Bien évidemment, le PO assiste à toutes ces cérémonies et en anime un grand nombre. Elles revêtent toutes une certaine importance mais ne s’appliquent pas à tous les projets. Leur format peut également différer selon les organisations.

Témoignage de Divya :

Pour quels clients as-tu travaillé  ?

« En tant que PO de l’application mobile d’ENGIE « particuliers », j’ai eu l’opportunité d’appréhender la large palette des rituels Agile qui s’offrent à nous. Sprint Planning, Rétrospective, Sprint Review, Poker Chiffrage, Daily ou encore la cérémonie que le métier et les autres parties prenantes attendent particulièrement : la démonstration.
Ils ont bien évidemment tous leurs intérêts et demandent un temps de préparation plus ou moins long. Mon objectif était donc d’allier une organisation qualitative de ces rituels avec la gestion du temps d’écriture de mes US.

Comment utilises-tu ces rituels Agile dans tes missions ?

Au sein d’ENGIE, un rituel m’apparaissait être primordial : le « Refinement Backlog ». Cet atelier de « toilettage » à la main du PO, permet de présenter les US qui seront embarquées dans le prochain sprint. Le but n’étant pas forcément de chiffrer / macro-chiffrer les fonctionnalités présentées mais de communiquer avec la « DevTeam » pour répondre au mieux à la valeur du produit et aux besoins métiers. On débat, on décompose, on soulève les risques techniques et on repasse sur la DOD si besoin pour affiner au maximum l’US. La pratique m’a appris que pendre le temps de groomer, c’est gagner du temps pour tout le reste du processus agile.

Autre rituel dont l’approche est très intéressante et structurante est la préparation des « PI plannings ». Sur ma mission, ils se déroulent tous les trois mois et nécessitent une bonne préparation de la Scrum Team. Cela passe par des poker chiffrages et le recueil d’un maximum d’éléments UX/UI.

Le fait de développer des produits en agilité SaFe m’a appris à anticiper les aléas, les adhérences le plus amont possible de l’incrément de programme.
Chez ACCOR en tant que consultante World of Digits, j’ai eu l’opportunité de travailler sur la partie Brands Premium et Eco-middle (hôtels Pullman, Ibis, Mercure…) du site ALL avec trois PO.

Nous avions des cérémonies ad-hoc entre PO pour prioriser nos tickets en collaboration avec les PPO dont le profil était purement technique mais aussi pour cleaner le backlog ou pour faire un point sur les remontées d’incidents. A contexte particulier, outils particuliers !

Au sein du Crédit du Nord, certains projets sont en full Agile et d’autres à mi-chemin entre le cycle en V et l’agilité. Chez Wolrd of Digits, nous avons su adapter les cérémonies au télétravail, en utilisant des outils collaboratifs comme Miro ou Klaxoon qui fonctionnent bien pour les réunions participatives à distance. »

Quelle est la valeur ajoutée de ces différents rituels  ?

Nombre de ces rituels, au-delà du pilotage projet, viennent aider le PO dans la mise en œuvre de ce qui représente le cœur névralgique de son travail : les Users Stories (US). Pour les plus néophytes, les US sont la retranscription fonctionnelle et écrite du besoin du Métier. Elles respectent un ensemble de règles théoriques importantes. Parmi elles, une US se doit d’être indépendante, de taille minimale, chiffrable, testable et doit avoir un vrai sens client.

Le PO ne doit jamais perdre de vue l’utilisateur final. Il doit être dans une démarche pragmatique et tester son produit en se mettant dans la peau de l’utilisateur. Cette approche « test and learn » lui d’être le garant de la valeur maximisée du produit.

Et ce, en mettant en place des évolutions régulières, en mesurant les impacts à l’aide de KPI et surtout de réajuster le produit si besoin.

On ne le répètera jamais assez mais le PO est le garant du projet et de la qualité qui en découle. L’importance accordée aux US est donc capitale. Une US de qualité permettra de gagner du temps et d’éviter les allers-retours en phase de delivery. Cela limitera donc le nombre d’anomalies et accélérera le “Time To Market” (temps de mise en production).

Témoignage d’Antoine :

« Quelles que soient mes missions ou la nature de mon projet, les US restent le coeur de mon activité. Au travers des Story Mapping ou d’une définition de besoin simple et explicite, je m’efforce de les rendre les plus claires et autoporteuses possibles. Cela m’évite trop d’allers-retours en Grooming ou en chiffrage.

La qualité du produit ou de la fonctionnalité délivrée n’en est que meilleure. Dans la plupart des entreprises que j’ai pu accompagner, j’ai eu pour habitude de travailler avec l’outil JIRA. Que ce soit en Kanban ou en Sprints, JIRA permet de donner une visibilité transverse sur mon activité et de voir en un coup d’oeil l’avancement de la phase de cadrage, de développement, de tests … selon la structure de l’équipe et du projet.

Je m’appuie beaucoup sur la vision de chacun des membres de la Scrum Team pour alimenter mes US. Parfois bien en amont d’un Grooming ou d’un atelier UX / UI. Cela me permet de fluidifier les transitions des US dans les colonnes de mon Kanban et augmenter la Lead Time (ou vélocité) de l’équipe. A la lecture d’une US, je souhaite qu’une personne totalement extérieure au projet puisse la comprendre sans explication. Cette méthode permet, selon moi, de garantir la qualité du travail de chacun. »

En résumé…

Tu l’auras compris, définir le rôle du Product Owner est complexe tant il dépend d’un contexte, d’une mission, d’une équipe. Les acquis et certitudes sont souvent remis en cause et le PO se doit de se renouveler constamment. On te conseille de vraiment voir le PO comme un chef d’orchestre. Un filtre.

Un interlocuteur privilégié. Il endosse beaucoup de responsabilités et se doit de réagir rapidement aux différents aléas que peut rencontrer un projet. Il doit prioriser, se justifier et se faire entendre. Toutes définitions du poste de PO est bonne à prendre. Elles t’apporteront des éléments théoriques sur l’appréhension de ce poste. Mais la réalité peut parfois différer.
Quelles que soient vos expériences.

Qu’est-ce qu’un PO ? Finalement, à chacun sa propre définition 😊

Joins us as a PO

Écrit par Divya et Antoine