Le rôle de Product Owner
Une nouvelle façon de présenter le portrait du PO idéal
C’est le 5 décembre 2006 que j’ai écrit le premier article de description du rôle de Product Owner. En 2022, j’ai publié l’édition 6 de mon livre Scrum en réécrivant le chapitre qui lui est dédié.
L’occasion de voir ce qui a évolué dans le rôle et dans la façon de le présenter.
Évolutions
Le nom
Mon article de 2006 avait pour titre : Le rôle de directeur de produit.
Eh oui, je ne disais pas Product Owner. J’utilisais directeur de produit depuis la lecture d’un excellent article de Brian Marick, dont je vous conseille la lecture (pdf), il est toujours très pertinent.
Malheureusement, c’est Product Owner qui est resté…
Le chapitre
En 2009, un chapitre de mon premier livre Scrum s’appelait donc Product Owner, c’est d’ailleurs le premier que j’ai écrit. Il faut dire qu’à l’époque je tenais ce rôle pour l’outil iceScrum, ça me donnait de la confiance pour en parler.
Au fil des éditions, il a évolué tout en gardant la même structure. Dans l’édition 5, j’ai ajouté deux nouvelles rubriques :
- la journée typique d’un PO,
- les antipatterns.
Nouvelle grille
La structure du chapitre a changé dans l’édition 6 suite à la lecture de l’excellent livre de Luc de Brabandère :
Petite philosophie des arguments fallacieux
Dans son chapitre L’instant critique il décrit le penseur critique en termes d’attitude, de compétences, de capacités et d’exigences. Ça m’a donné envie d’utiliser cette grille pour les rôles Scrum.
Le portrait d’un Product Owner idéal
La carte heuristique associée à l’article donne la vue d’ensemble. Je suis parti de l’édition 5, plus précisément des traits présentés dans les § 4.2 à 4.4 que j’ai essayé de mettre au bon endroit (attitude, compétence, capacité ou exigence).
Attitude
Luc de Brabandère définit l’attitude comme l’état d’esprit. C’est une prédisposition mentale qui désigne une intention et n’est donc pas directement observable.
Pour moi, un Product Owner devrait avoir cet état d’esprit :
- Envie de changer le monde
Ne serait-ce qu’un tout petit peu, comme dit Jeff Patton.
- Ouvert au feedback des utilisateurs
Le PO pense — vraiment — que les retours des utilisateurs sont les bienvenus et il en tient compte.
- À l’écoute des idées de ses coéquipiers
Il est normal qu’un Product Owner ne connaisse pas aussi bien que ses coéquipiers les aspects techniques des solutions pour arriver à un résultat. Ceux-ci, en faisant, font émerger de nouvelles idées qui peuvent améliorer le produit. Il est important que le PO s’y intéresse et fasse confiance à ses coéquipiers.
Compétences
Une compétence est une connaissance approfondie, reconnue qui confère le droit de juger ou de décider.
On demande au Product Owner des compétences sur :
- Son domaine métier
Bien sûr, c’est son Product. Il ne sait pas tout mais sait s’appuyer sur ceux qui savent.
- Scrum et l’agilité
Un Product Owner doit connaitre Scrum et les techniques de définition de produit.
Capacités
Une capacité est une possibilité de réussite et de mise en œuvre de compétences dans l’accomplissement d’une activité.
Voici quelques capacités utiles à un Product Owner :
- Percevoir la valeur
Le Product Owner décide des priorités en s’efforçant de maximiser la valeur. Le travail du PO c’est décider ce qui doit être fait, ce qui ne sera pas fait et assumer la responsabilité de ses choix. Grâce à lui, du travail inutile sera évité.
- Prendre les décisions concernant le résultat
Dans une équipe qui démarre, l’auto-organisation concerne le comment. Sur le quoi, le Product Owner décide. Cependant il sait expliquer ses décisions.
- Détailler au bon moment
Le Product Owner pratique l’affinage du backlog. Il a la capacité de décomposer au bon moment, pas trop tôt ni trop tard.
- Trier le feedback
Il y a toujours plus d’idées que de capacité à faire par l’équipe. Le Product Owner ne peut pas dire oui à tout.
- Garder le cap
Si l’on ne demande pas à un Product Owner d’être un grand visionnaire comme Steve Jobs , il doit cependant avoir une bonne vision du produit et être capable de la communiquer. Tout le monde devrait partager cette vision, et c’est au PO de s’assurer que l’équipe garde le cap. Il ne faut pas comprendre l’ouverture au changement proposée par le Manifeste agile comme le droit de changer d’avis à tout moment. Un Product Owner garde le cap : la vision ne varie pas fondamentalement et, à court terme, c’est lui qui porte l’objectif du sprint. Bien qu’ouvert au changement, il n’est pas une girouette.
Exigences
Une exigence est une contrainte à laquelle une activité doit satisfaire ou un impératif que l’on s’impose à soi-même.
Voici 4 traits qui me paraissent être des exigences pour un Product Owner.
- Donner de son temps à l’équipe
La disponibilité pour le rôle est une condition sine qua non. Par opposition à ce qui se passe pour un projet classique, où l’intervention du client (ou de son représentant) est importante au début et à la fin mais pas entre les deux, l’implication du PO est constante sur tous les sprints.
- Pratiquer l’art de la conversation
Pour un Product Owner qui a l’habitude de l’écrit, il s’agit de passer à l’oral. Une story ça se raconte.
- Dire non aux demandes en violation avec la mission de l’équipe
Un PO peut être soumis à des demandes spéciales venant du sponsor ou d’une partie prenante importante. Si la demande est en contradiction avec l’engagement qui a été pris par l’équipe lors de l’alignement du prélude, celle-ci se sentira trompée et vivra mal ce décalage. Dans sa capacité à dire non, le PO poussera à une discussion sur le sujet.
- Défendre l’équipe auprès des parties prenantes
Il est dans l’équipe, il la soutient, même si à la fin d’un sprint il aurait aimé avoir plus de valeur dans le résultat.
Compléments de lecture
- Vous trouverez sur la page des Traducteurs Agiles le mini-livre d’Anna Fors : Confessions d’un serial Product Owner.
- L’article Impact sur le vivant pour définir les priorités montre l’importance du rôle.
