L’indispensable Product Owner

Dans ce troisième billet je vous propose d’explorer le rôle du Product Owner, qui reste, à mon sens, le moins bien compris des 3 rôles que propose Scrum.

Ce que dit le guide

Commençons par revoir ce que dit le guide Scrum (dans son édition 2013) sur ce rôle :

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Disons que c’est un bon début, mais cette définition n’aide pas les personnes qui endossent le rôle de Product Owner à comprendre toute la dimension de ce rôle. Ces personnes finissent par se limiter à gérer le contenu du fameux Product Backlog.

Mais nous allons voir que le rôle de Product Owner va bien au-delà de la gestion du Product Backlog.

Un entrepreneur

Dans son excellent livre “Agile Product Management with Scrum : Creating Products that Customer Love”, Roman Pichler présente le Product Owner comme un entrepreneur (voir un intrapreneur).

Pour Roman Pichler, le Product Owner devrait avoir les caractéristiques suivantes :

• Être un visionnaire et être capable de mettre en place sa vision
• Être un leader et un équipier
• Être un communicateur et un négociateur
• Être habilité et engagé
• Disponible et qualifié

Tel un entrepreneur, un Product Owner croit en son produit, il est capable de le vendre à ses clients, à ses supérieurs hiérarchiques, à son équipe de développement ainsi qu’à toutes les parties prenantes. Il bouscule ses clients et ses utilisateurs pour aller chercher le vrai besoin. Il négocie avec ses clients pour construire son plan et sa stratégie de livraison.

Mais le Product Owner ne peut offrir tout son potentiel que si sa hiérarchie lui accorde l’autorité dont il a besoin pour effectuer sa mission avec succès. C’est le seul responsable du succès du produit.

Le rôle de Product Owner est à rôle à temps plein et exigent! No pain, no gain!

Mais qui est le Product Owner?

Bien souvent on prend le terme « Product Owner » (Propriétaire du produit) de façon trop littérale, ce qui conduit à prendre le client pour endosser le rôle du Product Owner.

Voyez-vous le problème? Dans mon précédent billet nous avons vu que le client a du mal à exprimer son besoin. Et vous voulez lui donner le rôle de Product Owner?

Ce choix de prendre le client comme Product Owner sous-entend une vision projet de ce qui doit être livré, avec une portée,  des coûts et une durée qui seront fixes. Ce n’est pas ce que l’on pourrait appeler une approche Agile, et on pourrait tout aussi parler de Project Owner plutôt que de Product Owner.

Pour ma part, je pense qu’il faut voir le Product Owner comme le propriétaire moral du produit dont il a la charge. Il est le garant de l’orientation du produit ainsi que de son succès.

Je vous propose donc une petite comparaison de ces deux approches :

Le Product Owner comme client (une vision projet)
	Risque	À considérer
Connaissance du domaine	Nul.	Une personne avec un profil d’utilisateur expérimenté pourrait être un plus.
Disponibilité	Élevé. La personne désignée occupe sûrement déjà une fonction dans son organisation. Éloigné de l’équipe de développement.	Informer le client que son PO doit être dédié à 100 % au projet.
Stratégie de livraison	Élevé.	N’entre pas forcément dans le champ de compétences de la personne désignée.
Priorisation et valorisation	Modéré.	Peut-être difficile d’introduire des besoins n’appartenant pas aux clients.

Le Product Owner en tant que propriétaire moral (vision produit)
	Risque	À considérer
Connaissance du domaine	Modéré.	Le PO peut avoir des connaissances limitées au début du projet mais celles-ci vont augmenter tout au long du projet.
Disponibilité	Faible.	Son gestionnaire l’a dédié à 100 %.
Stratégie de livraison	Faible.	Son gestionnaire l’a nommé PO pour cette compétence.
Priorisation et valorisation	Modéré. Certaines parties prenantes peuvent lui imposer des choix.	Il reste le seul responsable de la priorisation et de la valorisation des besoins, mais il doit être soutenu par sa gestion dans ses décisions.

Dans mon prochain billet nous verrons comment le Product Owner s’y prend pour comprendre le vrai besoin de ses clients.