Mais que fait mon Product Owner ?
“Ma PO* est toujours en réunion”, “Moi j’ai 3 POs et ils ne sont jamais d’accord”, “Je ne sais pas à qui m’adresser quand j’ai une question, ma PO, mon Business Analyst ?”, “Il y a une PO dans mon équipe mais franchement je ne sais pas à quoi elle sert et ce qu’elle fait”, etc.
Ce constat, issu de mes collègues développeurs, semble partagé de façon assez générale : le rôle de Product Owner (PO) est pour beaucoup très flou, oserais-je dire mystérieux…
Dans cet article, je vous propose de vous partager le constat de la réalité “client”, pourquoi nous en sommes là (selon moi, à cet instant) et des outils concrets pour s’en sortir quand on est face à ce genre de situation.
Note: un bréviaire est à votre disposition en fin d’article
Le constat
Lors de nos missions, nous rencontrons de multiples organisations, souvent complexes, avec de nombreux titres, rôles, casquettes.
On peut avoir des chefs de projets, des Product Managers, des Product Owners, des Proxy Product Owners ou des co-Product Owners et parfois même des rôles spécifiques au client comme des “fonctionnels”.
Ils travailleront peut-être avec des formateurs et des équipes de conduite de changement, des business analysts, des recetteurs et QA* (responsable qualité), des designers UX-UI*.
Quant aux parties prenantes, vous pouvez avoir des sponsors, des représentants métiers, des key users…
Bref, cela en fait du monde, et je ne parle même pas de la partie dev ou de l’accompagnement agile ou organisationnel!
Ces rôles/personnes sont associés de diverses manières. Quelques exemples rencontrés par mes collègues Zenika:
- pas de PO
- autant de PO que de développeurs
- 1 PO, 1 manager plus ou moins aussi PM* et scrum master
- 1 PO issu du métier, ancien Key User
- 1 PO, un recetteur, un admin fonctionnel, un analyseur de bugs, une personne en charge de la conduite du changement et un scrum master
Dans cette organisation complexe il est parfois difficile de s’y retrouver et de comprendre qui :
- Priorise le travail à faire ?
- Connait le besoin ?
- Valide les fonctionnalités développées par l’équipe de dev ?
- Explique le métier au dev ?
- Explique la vision ?
- A qui l’équipe doit-elle remonter les alertes?
- Identifie la valeur ?
- Rédige les stories ?
- Découpe les fonctionnalités ?
- Répond aux questions de l’équipe sur les Users Stories ?
- Explique au métier que ce n’est pas un bug ?
- …
Vous me direz qu’il suffit de prendre la définition de chaque rôle pour savoir qui fait quoi ? Trop simple, faut-il déjà qu’une définition existe pour le contexte dans lequel on opère !
Pourquoi ?
“Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team.
La manière de procéder peut varier considérablement selon les organisations, les Scrum Teams et les individus.
Le Product Owner est également redevable de la gestion efficace du Product Backlog. Ce qui inclut :
- Formuler 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 compris.
Le Product Owner peut effectuer le travail ci-dessus ou peut déléguer ce travail à d’autres. Quoi qu’il en soit, le Product Owner en demeure redevable.
Pour que les Product Owners réussissent, toute l’organisation doit respecter leurs décisions. Ces décisions sont visibles dans le contenu et dans l’ordre du Product Backlog et, via un Increment inspectable lors de la Sprint Review.
Le Product Owner est une personne et non un comité. Le Product Owner peut représenter les besoins de nombreuses parties prenantes dans le Product Backlog. Ceux qui souhaitent modifier le Product Backlog peuvent le faire en essayant de convaincre le Product Owner.” (Scrum Guide 2020)
La définition de ses activités n’est pas exhaustive (quid du lien avec l’utilisateur?) et si l’équipe n’utilise pas Scrum, comment faisons-nous?
L’agilité, et Scrum en l’occurrence, ne se résume pas une recette de cuisine à suivre à la lettre.
Ainsi, le rôle de PO se retrouve progressivement dans les équipes, qu’elles utilisent Scrum ou non, souvent dès lors que l’agilité se met en place. Car oui, l’agilité étant à la mode, il arrive que certains pensent qu’il suffit de dire “PO” à la place de “Chef de projet” pour être agile. Je l’ai constaté il y a quelques années en changeant d’entreprise, les fiches de poste de “Product Owner” décrivaient en réalité les missions d’un chef de projet. On le voit aussi en formation, où des chefs de projets “doivent” maintenant être PO sans savoir à quoi ce rôle correspond.
Dans l’organisation en V / waterfall, le chef de projet à une liste assez longue de responsabilités (le planning, le budget, la priorisation, la relation client, le RH, l’adéquation de la solution aux spécifications…). Il est parfois aidé d’un AMOA*/Business analyst qui spécifie la solution et d’un recetteur/QA* qui teste la solution.
Une première configuration que l’on peut rencontrer est donc de simplement renommer le chef de projet en “PO” en gardant les mêmes activités.
Comme le PO est censé rédiger les User Stories, et parfois aussi les valider, on peut se dédouaner de l’AMOA et de la recette, c’est le PO qui s’en charge. Notre chef de projet / PO se retrouve donc à faire tout ce qu’il faisait avant et, en plus, à rédiger les stories et à faire la recette.
On se retrouve alors avec un PO débordé qui n’a pas le temps d’être disponible pour l’équipe.
Face à cette charge massive de travail, certaines organisations introduisent le Proxy PO, qui récupère alors une partie de la casquette du PO, en particulier le lien avec l’équipe. D’autres choisissent de soutenir le PO en basculant sur du co-PO, voire une équipe de PO, qui se répartissent le travail ou le périmètre.
Dans cette organisation en équipe, dur de savoir qui a le dernier mot en cas de désaccord…
Le manque de gouvernance pointant son nez, un PM est recruté pour aller chapeauter cette armée de PO. Les PO n’ont plus qu’à exécuter et “pondre” les US*!
Vous l’aurez compris, ce flou artistique révèle une transition en cours, du cycle en V vers l’agilité, parfois de la culture projet vers la culture produit, avec beaucoup de belles idées et d’initiatives et parfois de la difficulté à s’y retrouver.
L’organisation cible
La notion de “bonne organisation” est tout à fait relative à chacun d’entre nous, nos caractères et nos vécus. Chacune des organisations citées juste avant peut donc être la bonne. Ceci dit, je pense qu’elles doivent tout de même répondre à quelques critères clés.
La “bonne” organisation est celle qui, entre-autre :
- Est partagée entre tous ses acteurs : tout le monde sait qui fait quoi
- Répond aux différents besoins du groupe : pas de questions sans réponse faute de responsabilité, pas de blocage faute de gouvernance
- Est stable et rend les personnes sereines : pas de burn-out ou de bore-out
L’organisation dépend complètement du contexte client et produit.
Un petit produit, pas en PROD*, en mode POC* (expérimentation), n’a pas les mêmes besoins d’organisation qu’un produit déjà utilisé par 15 000 personnes dans le monde entier et en perpétuelle évolution!
Seules les petites équipes peuvent prétendre être proches du Scrum guide en termes d’organisation. Même si le Scrum Guide recommande des équipes de 11 personnes maximum (incluant le PO et le scrum master), dès lors que l’équipe de développement dépasse les 8 personnes, la question de couper l’équipe en deux, et donc d’initier une mise à l’échelle se pose.
La mise à l’échelle peut également se faire au niveau PO dès lors que la charge de travail est trop importante (discovery important, tests de non-régression, manuels lourds, etc)
Quelques idées d’organisations à plusieurs PO qui peuvent marcher (là encore, de mon expérience):
Pour les grandes équipes de développement (+ 8 devs) ou si la charge de travail est importante:
2 co-PO, qui se partagent le travail: par tâches selon les affinités, soit par périmètre métier.
Clé de succès:
- La communication “excessive” et la transparence, la bonne entente et la maturité. Ne fonctionnera pas si l’un des PO est en recherche de pouvoir ou de lumière
- Un des PO est reconnu comme ayant le pouvoir d’arbitrage en cas d’incapacité à se mettre d’accord, pour ne pas rester bloqué (peut se définir par fonctionnalité, périmètre également). Fonctionnera si ce pouvoir est utilisé avec beaucoup de parcimonie et qu’il n’y a pas de rapport hiérarchique entre eux.
Plusieurs équipes de développement :
Un PO par équipe, comme le décrit le Scrum guide.
La nuance se porte sur le rôle du PM, qui coordonne l’ensemble des PO et vérifie que chaque brique métier sur laquelle travaille chaque PO reste en cohérence avec la vision produit, la roadmap macro, etc.
C’est bien chaque PO qui, en autonomie, va gérer son périmètre et son backlog.
Clé de succès:
- Le PM n’a pas de lien hiérarchique avec les PO, il est le lead, celui qui s’assure que tous les PO vont dans le même sens, celui de la vision produit et de la valeur. Cette posture est primordiale. Il a aussi le pouvoir d’arbitrage en cas de désaccords.
- Une bonne communication et de la transparence entre les PO et le PM est nécessaire.
- Des rituels réguliers de synchronisation PO/PM pour maintenir une cohérence du produit
Et concrètement, je fais quoi si ça ne va pas ?
Que l’on soit côté développement ou côté PO, lorsque nous démarrons une nouvelle mission, le cadre n’est pas toujours clair et il n’est pas forcément évident de savoir “où on va tomber”. Parfois, il nous faut un peu plus de temps pour nous rendre compte qu’en fait, c’est le bazar, et il arrive parfois que, suite à des réorganisations ou des départs, une “bonne” situation devienne floue et obscure.
Dans tous les cas, il n’est jamais trop tard pour agir !
Ceci dit, nous n’avons pas forcément le mandat (ou l’envie !), en mission, pour tout révolutionner.
Je vous propose dans cette section différents outils à mettre en place ou à proposer, selon le niveau d’ouverture de votre contexte mission.
Identifier les rôles et les responsabilités
Quand : Dès que nécessaire et particulièrement lorsque l’équipe évolue (renforts, réorganisation…)
Objectif : Pour chaque rôle de l’équipe ou de l’organisation, avoir une définition claire, partagée et assumée de ses responsabilités envers les autres
Participants : L’ensemble de l’équipe (attention, pas de représentants)
Durée : 2h
Facilitation : Si possible une personne neutre extérieure à l’équipe.
Comment : Voir le prochain article sur le sujet !
Identifier les activités et les relations
Quand : Lorsqu’il n’est pas possible d’organiser un atelier rôle et responsabilité, ou si le flou ne concerne que certains rôles ou certaines personnes
Objectif : Identifier ce que fait chaque personne, indépendamment de son rôle
Participants : L’ensemble des personnes occupant le même rôle
Facilitation : Soi-même si possible
Comment : Demandez à chaque personne de lister l’exhaustivité de ses activités. Si c’est en atelier, demandez-leur de faire une restitution et d’identifier ce qu’elles font en commun, ce qui diffère et d’établir une représentation de leurs interactions avec les autres rôles de l’organisation. Si des zones sont floues, par exemple qui arbitre en cas de désaccord, demandez un éclaircissement
Si l’organisation le permet, faites profiter le reste de l’équipe de cet apprentissage
Et sinon…
- Dès l’entretien (avant de démarrer), identifier les rôles et responsabilités et le fonctionnement de l’équipe
- A l’arrivée sur une mission, demandez que l’on vous présente l’organisation, les activités de chacun au delà de son rôle, la matrice rôle et responsabilités si elle existe
- Faites vous présenter les parties prenantes du projet
- Faites un rapport d’étonnement auprès du responsable de l’équipe, après quelques semaines sur la mission, pour mettre en lumière un éventuel flou
- Il n’est jamais trop tard pour demander / re-demander, vous pouvez aussi profiter d’une rétrospective pour en parler
- En cas de doute, demandez / mettez les pieds dans le plat (“Ah je pensais que c’était Bob qui priorisait le backlog, il fait quoi Bob du coup?”)
- En cas de ping-pong (“Va voir Patrick c’est lui qui décide” “Non non va voir Bob c’est lui l’expert métier”), rassemblez les joueurs (“Bob, j’aimerais faire un point avec Patrick et toi sur ce sujet”)
Abréviations
AMOA : Assistance à Maîtrise d’Ouvrage Appliqué
BA : Business Analyst
coPO : co-Product Owner
CP : Chef de Projet
Dev : Développeurs
PM : Product Manager
PO : Product Owner
POC : Proof Of Concept
PPO : Proxy Product Owner
PROD : production
QA : Quality Assurance
US : User Story
UX/UI : User eXperience / User Interface
