[ScrumDay 2013] Session Le Proxy Product Owner – Superman, j’ai la Patate

Logo-Scrum-Day-2013Le 11 avril prenait place chez IBM le ScrumDay, évènement annuel organisé par le FSUG. J’ai eu l’occasion de participer à une session “table ronde” animée par Eve Vinclair-Berkemeier, sur le thème du Proxy Product Owner.

Le Product Owner

Pour ceux qui ne seraient pas familiers avec Scrum, cette méthodologie définit trois rôles:

  • L’équipe de développement : responsable des développements et des livraisons. C’est une équipe pluri-disciplinaire et auto-organisée ;
  • Le Scrum Master : protecteur de l’équipe et facilitateur de la méthodologie, son rôle est d’assurer que la méthodologie est bien appliquée et de protéger l’équipe des perturbations extérieures, lui permettant ainsi de se concentrer sur le travail à faire ;
  • Le Product Owner : il représente le ou les clients et parle en leurs noms. Il écrit les user stories et les priorise, formant le product backlog.

Le Proxy Product Owner ou PPO

Comme on peut le remarquer, la méthodologie Scrum ne définit aucun rôle de “Proxy Product Owner”. D’où vient donc cette notion ?

Théorie et pratique, le choc des titans

Tout le monde est d’accord sur un point, le Proxy Product Owner n’est pas un rôle défini dans Scrum. Cependant, ce nouveau rôle correspond à des besoins réels que nous allons explorer.

po

La Scrum Alliance, référence en ce qui concerne Scrum, fait la remarque suivante:

“One Product Owner is ideal but not always possible or practical. Product Owners tend to be stretched too thin. Some strategies that are being used are:

  • Proxy Product Owner
  • Chief Product Owner (Overall road map) Technical Product Owners (Detail or team level product owner)
  • Direct team interaction with end users with oversight by Product Owner”

Les différents témoignages pendant la session ont mis en avant différents problèmes rencontrés par le PO qui justifiait la présence d’un PPO :

  • Manque de temps
  • Nombre de projets à gérer
  • Faible accessibilité
  • Délocalisation

Ces problématiques, bien que réelles, sont-elles une raison suffisante pour ajouter un rôle ?

ppo

Essayons d’imaginer un cas d’exemple basé sur un schéma classique que beaucoup ont rencontré. Prenons une entreprise établie sur Paris et sur Lyon. La décision a été prise de développer une application pour les utilisateurs de Lyon et on a nommé un Product Owner sur place. L’équipe de développement, quant à elle, se trouve à Paris.

Après quelques itérations, on se rend compte que la qualité du backlog est en baisse. Les user stories sont moins claires, le PO plus difficilement joignable. Tant bien que mal le sprint se termine et, lors de la rétrospective, le PO déclare qu’il n’a pas le temps.

Une fois le problème clairement identifié, il suffit de trouver une solution, de prendre une décision. Après concertation entre les différents acteurs, deux solutions se présentent :

  • Nommons un PPO
  • Changeons de PO

Le PO actuel connaît bien les utilisateurs et a une vision claire du projet, on décide donc  de nommer un PPO car trouver un autre PO pourrait être long et donc coûteux. Il reste maintenant à définir les responsabilités du PPO et celles du PO :

Proxy Product Owner Product Owner
User Stories Ecriture Validation
Product Backlog Priorisation
Prise de décision Selon la décision Selon la décision

N’oublions pas que le PO répond également aux interrogations de l’équipe. Il faut donc que cette personne ait une connaissance du métier et une vision suffisante pour cela. Difficile de quantifier cette connaissance. En effet, beaucoup argumenterons avec raison que si le PPO connait aussi bien le sujet, peut-être devrait-il juste être PO à la place du PO.

Un autre problème se pose lorsqu’on décrit ainsi les responsabilités. On voit que  la prise de décision par le PPO dépend de la décision à prendre, du contexte. Le PPO peut-il prendre cette décision ? S’il était PO, ce serait sans équivoque, mais dans ce cas nous sommes dans le flou.

Ce flou est source de frustration pour le PPO, qui voudrait pouvoir prendre une décision rapide mais qui ne le peut pas, il n’en a pas le pouvoir. Ce qui introduit la problématique du pouvoir.

Pouvoir et hiérarchie : la légitimité

Dans la plupart des organisations, le pouvoir est lié à la hiérarchie, raison pour laquelle les PO sont généralement hiérarchiquement plus élevés que le scrum master ou l’équipe de développement. Cela lui donne le pouvoir de prendre certaines décisions.

Dans le cas du PPO, il faut donc définir clairement jusqu’où s’étend sa responsabilité, jusqu’à quel point il peut prendre des décisions. Ce qui est recherché c’est le niveau de délégation voulu qui déterminera le pouvoir du PPO.

Subjectivement parlant…

Je vais maintenant exposer mon avis, qui n’engage que moi. Je ne crois pas en Scrum by the Book. C’est un outil parmi d’autres, que l’on doit adapter au besoin. Tant que les valeurs sont respectées, que les principes agiles sont appliqués, on fait de l’agilité.

PO ou PPO, parfois on ne pourra pas choisir entre proximité avec les utilisateurs et proximité avec l’équipe et le PPO se présentera comme une solution viable. Je pense que la problématique autour de l’existence des Proxy Product Owner vient généralement d’un manque de clarté quant à ses responsabilités, quant à la définition même du PPO.

On l’a vu, le rôle de Product Owner peut être rempli par une personne ou par une équipe. La méthodologie n’empêche pas au PO d’avoir des assistants, même si on admet que ce n’est pas idéal. Rarement un projet informatique est idéal, faut-il le rappeler. Par conséquent il faut s’adapter, cela fait partie de l’agilité.

Pour conclure

BFp8I66CIAAXdcXL’agilité évolue naturellement, et l’apparition des rôles est une réponse naturelle lorsque de nouvelles problématiques apparaissent. Peut-être que lorsque les organisations seront réellement agiles le PPO sera obsolète, et on pourra oublier son existence. En revanche, due à la complexité des entreprises aujourd’hui, il est clair que le PPO a sa place dans Scrum.

Merci à Eve pour avoir mis en place cette table ronde et à tout les participants pour avoir partager leur différentes expériences.

Pour aller plus loin

Nombre de vue : 179

COMMENTAIRES 2 commentaires

  1. […] Retrouvez l’article au complet sur le blog de Soat: http://blog-rec.soat.fr/2013/04/scrumday-2013-session-le-proxy-product-owner-superman-jai-la-patate/ […]

AJOUTER UN COMMENTAIRE