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.

Une mêlée quotidienne bien difficile

Cela fait maintenant presque un an et demi que je suis le Scrum Master de la même équipe, et durant cette période la composition de cette dernière a bien changé. Elle est maintenant composée d’un noyau de 4 personnes travaillant ensemble depuis plus de 2 ans auquel ce sont ajoutés 3 nouveaux membres (externes) durant les 6 derniers mois.

Avec ces changements j’ai dû enseigner aux nouveaux membres les valeurs de Scrum et de l’agilité afin de les aider à s’intégrer à l’équipe. Et pendant quelques itérations il m’a fallu rappeler les objectifs de la mêlée quotidienne afin que celle-ci ne déborde pas.

Mais il y a quelques jours de cela j’ai vécu la mêlée la plus difficile depuis que je suis le Scrum Master de cette équipe, j’ai été confronté à un vrai manque de discipline de la part de certains de mes coéquipiers. Certains se permettaient de discuter entre eux pendant qu’un de leurs coéquipiers répondait aux 3 questions, et il m’a été difficile d’obtenir leur attention sans monter le ton. Mais le meilleur m’a été réservé pour la fin de la mêlée lorsque l’un des derniers externes à avoir intégré l’équipe s’est mis à donner des ordres/tâches à un autre membre, je suis malheureusement resté sans voix…

Les limites du rôle de Scrum Master

Pour rappel, le Scrum Master n’est pas un chef d’équipe mais plutôt un facilitateur, un guide, voir un coach pour l’équipe. Il est là pour accompagner l’équipe dans son apprentissage de Scrum. Il est là pour conseiller l’équipe et l’aider à s’améliorer dans ses pratiques de développement. Il est là pour retirer les obstacles qui empêchent l’équipe d’être efficace. Mais en aucun cas il peut donner des ordres à l’équipe.

Dans ce contexte j’ai 2 possibilités qui s’offrent à moi :

  • notifier la gestion sur le problème de discipline dans l’équipe,
  • réexpliquer une énième fois les principes de la mêlée quotidienne lors de la prochaine mêlée.

Personnellement je vais privilégier la seconde approche et garder la première pour les situations extrêmes. En effet, je trouve que la première solution a un côté infantilisant et qu’elle risque, d’une certaine manière, de briser la confiance que les membres de l’équipe ont en moi.

Que ce soit dans le guide Scrum ou dans les 12 principes agiles il est fait mention d’équipes auto-organisées. Mais pour avoir une équipe auto-organisée il nécessaire, à mon avis, d’avoir des membres auto-disciplinés et respectueux de leurs coéquipiers.