Que se passe-t-il avec un PO qui n’est qu’un passe-plat ?

Scrum décrit un rôle de Product Owner (PO). Propriétaire du Produit, en français, le PO est censé représenter la voix des utilisateurs donc, n’est-il qu’un passe-plat ?

Est-ce que son rôle ne se borne qu’à transmettre ce que l’utilisateurs veut vers les développeurs, par des spécifications ? Avant d’entâmer une série d’articles pour aider les PO, il me semble important de comprendre ce rôle.

Tout comme il y a plusieurs types de Scrum Master, il y a plusieurs façons d’approcher le rôle de Product Owner. Je vais vous décrire ici ce que j’ai pu vivre.

La mission du Product Owner

“Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement. La façon de jouer ce rôle peut varier grandement selon les organisations, les équipes Scrum et les individus.

Le Product Owner est le seul responsable de la gestion du Backlog Produit”

Scrum Guide

Comme souvent, il suffit de lire le Scrum Guide pour comprendre le rôle du Product Owner. Le PO est donc responsable du backlog produit (à opposer au backlog de sprint dont la responsabilité est celle de l’équipe de développement).

C’est donc le Product Owner qui choisit les éléments à mettre dans le backlog (ou pas), ainsi que comment les mettre pour générer de la discussion avec l’équipe de développement; il choisit aussi comment les prioriser (nous verrons ça dans un prochain article).

Ce qui fait qu’un Product Owner n’est qu’un passe-plats

Qu’est-ce qui fait qu’un PO ne serait qu’un passe-plats sans intérêt ?

Déjà un PO-Passe-Plats (ou POPP puisqu’on aime bien donner des acronymes aux titres – préparez-vous à voir des certifications POPP !), n’est souvent pas disponible pour l’équipe Scrum.

À mi-temps PO, il ou elle peut aussi être PO de plusieurs équipes, qui n’ont pas ou peu de relations (différents produits par exemple).

Il ou elle peut aussi être multi-casquettes, c’est par exemple une développeuse qui joue aussi le rôle de PO, quand elle a le temps ou quand il faut.

La mission de PO n’est alors pas remplie, un peu comme on voit un Scrum Master comme un chronomètre, on imagine que le travail du PO n’est réduit qu’à écrire des US et remplir un Jira. Or, à l’instar du Scrum Master, le PO doit aller bien plus loin dans le management de son produit. Et ça, aussi incroyable que cela puisse paraître, c’est un job à temps plein !

Oh mais en fait, pas forcément besoin d’inventer un nouvel acronyme pour tout ça, des consultants l’ont déjà fait pour nous : le Proxy-PO (PPO).

Le Proxy-PO a été inventé

Le Proxy-PO (PPO) a sûrement été inventé par un ou une consultant-e qui n’arrivait pas à faire en sorte que la hiérarchie de son client donne le titre de PO à la personne qui réalisait effectivement les tâches de ce rôle.

🦄 Le Proxy-PO n’existe pas dans le Scrum Guide.

Je connais plusieurs type de PPO :

1. Le PPO qui a le pouvoir de priorisation. C’est lui qui crée les éléments du backlog (écrit les User Stories par exemple), il sait les expliquer, peut en retirer et il parle avec les utilisateurs.
   Cette personne a ce titre parce que généralement, quelqu’un de plus haut placé que lui a une érection en se faisant appeler Product Owner et ne veut pas lâcher le titre bien qu’il n’en fasse pas le job. Pour moi ce n’est pas trop grave, tant que ça permet à l’équipe de bosser sereinement. Le PPO est le vrai PO. (même si ça démontre du Cargo Cult au niveau de l’organisation et qu’il va bien falloir s’en occuper un jour).
2. Le PPO qui n’a pas de réel pouvoir de priorisation ou de décision. Il n’est là que pour passer l’info vers et depuis le vrai PO. Il est une nuisance pour l’équipe et n’apporte rien de bon. Il est a dégager.

Mon conseil est bien sûr que l’équipe refuse le rôle de Proxy-PO.

S’il/elle n’a pas l’autorité sur le produit, tel que doit avoir un tel rôle, le ou la Scrum Master doit user de toutes ses capacités pour faire reconnaître un vrai Product Owner et le ou la faire intégrer réellement à l’équipe.

Le PO qui n’en a que le titre a juste un problème d’égo qu’il ou elle cherche à compenser. LÂCHEZ LE TITRE ! SOYEZ PARTIE PRENANTE ! C’est vachement important aussi, les parties prenantes.

Le passe-plats, on peut s’en passer

Du coup, pourquoi un PPO sans pouvoir ?

C’est déjà une bonne étape de se poser la question. Pour y répondre, il faut -encore- lire le Scrum Guide :

“La gestion du Backlog Produit comprend :

L’expression claire des éléments du Backlog produit;
L’ordonnancement des éléments dans le Backlog produit pour mieux réaliser les objectifs et les missions;
L’optimisation de la valeur du travail effectué par l’équipe de développement;”

Pour réaliser la mission telle que décrite ci-dessus, il faut avoir une bonne connaissance du produit bien sûr, mais surtout une compréhension du besoin des sponsors et des utilisateurs. Il faut aussi prendre en compte (et donc connaître) les nécessités techniques que l’équipe transmet.

Donc si le PO n’est pas en constante collaboration avec le reste de l’équipe, comment effectuer ce travail ? La meilleure position pour prendre en compte toute ces variables et ainsi prendre les meilleures décisions possible dans le contexte, est de vivre le produit, dans l’équipe.

N’oubliez pas que la meilleure façon de développer un produit est de réunir “le métier” avec ceux qui réalisent.

Et si “le PO est quand même vachement présent malgré tout, il répond aux questions quand on lui demande”, ben alors, pourquoi y aurait-il un PPO ?! Pour les tâches ingrates ?

Le PO ne va pas s’abaisser aux tâches de scribe, quand même ?!

L’activité que je vois la plus déléguée à un Proxy-PO, c’est l’écriture des User Stories.

Nan mais c’est vrai quoi, c’est compliqué, faut écrire pleins de lettres pour faire tout le temps les mêmes mots : “En tant que … je veux que … afin de …”. On va quand même pas demander à un Product Owner (à lire avec un accent Texan pour appuyer l’extrême importance solennelle du titre) de perdre son temps à écrire ça à chaque fois ! Y’a bien une petite main pour faire ça non ? Le Proxy-PO !

Si le PO estime qu’il a mieux à faire que de “s’assurer que l’équipe de développement comprend adéquatement les éléments du Backlog produit” (pour citer le Scrum Guide), alors c’est qu’il n’a rien à faire dans une équipe Scrum. Pareil s’il pense que quelqu’un le fera mieux qu’elle ou lui. Si on refuse le job, on refuse le titre et on laisse les gens compétents travailler.

On est pas obligé de faire du Scrum !

LA phrase. Bien sûr qu’on est pas obligé de faire du Scrum ! Scrum n’est d’ailleurs pas un but. Par contre, il est intéressant de comprendre les choix qu’on fait (ou qu’on ne fait pas). PO, Proxy-PO, métier, peu importe le nom, l’important est que le responsable du backlog agisse toujours dans le but de livrer le plus de valeur possible, rapidement et durablement (pas de dette technique volontaire, quoi), et pour se faire, la définition du PO de Scrum est pas mal, jusqu’à preuve du contraire.

Du coup, c’est mal un Product Owner-Passe-Plats ?

Ben déjà, c’est pas forcément hyper intéressant comme travail, ni gratifiant. Donc généralement, celui ou celle qui a ce rôle est peu investi.e dans le produit et dans l’équipe.

C’est ingrat, on ne peut d’ailleurs qu’échouer, car même si on fait bien son travail, les lauriers vont certainement retomber sur The Product Owner.

Si vous vous retrouvez dans ce rôle, je ne peux que vous inviter à mettre les choses au point. Vous faites déjà le travail, replacez les étiquettes : Vous = PO; Autres = Parties prenantes.

Et si ça ne fonctionne pas, partez. L’entreprise n’est pas prête et ne vous mérite pas.

Donnez moi votre avis, et vos retours d’expériences.

Voici quelques liens en rapport :

• Pour savoir ce qu’est le Cargo Cult : Dark Agile : Cargo Cult
• A-t-on besoin d’un Product Owner ? Discussion sur Twitter
• Pourquoi le PO n’est pas dans le daily Scrum ?