Dans de nombreuses organisations, le rôle de Proxy Product Owner est couramment rencontré.
Mais quelles sont ses responsabilités habituelles ?
- Représentation du Product Owner : Un Proxy Product Owner agit en tant que représentant du Product Owner. Cela peut être nécessaire lorsque le Product Owner lui-même n’est pas disponible en permanence en raison d’autres engagements ou de contraintes de temps.
- Prise de décision : Le Proxy Product Owner est autorisé à prendre certaines décisions au nom du Product Owner en son absence. Cependant, il doit toujours aligner ses décisions avec la vision et les priorités définies par le Product Owner.
- Gestion du product backlog : Le Proxy Product Owner peut être responsable de la gestion quotidienne du backlog, de la priorisation des fonctionnalités et de la communication directe avec l’équipe de développement, tout en s’assurant que les décisions importantes sont référées au Product Owner.
Soyons clairs, le Proxy Product Owner n’existe pas dans le Scrum Guide.
Son émergence dans certaines organisations s’explique par diverses raisons. Par exemple, le Product Owner n’a pas le temps de tout faire ce qui est décrit dans le Guide Scrum car il est débordé par ses multiples rôles ou produits à gérer, ou bien il peut ne pas souhaiter assumer pleinement ses responsabilités.
Que dit le Scrum Guide ?
Le Product Owner est redevable de maximiser la valeur du produit résultant du travail de la Scrum Team. La manière de procéder peut varier considérablement selon les organisations, les Scrum Teams et les individus.
Scrum Guide, v2020 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf
Le Product Owner est également redevable de la gestion efficace du Product Backlog. Ce qui inclut :
– Formuler et communiquer explicitement l’Objectif de Produit ;
– Créer et communiquer clairement les éléments du Product Backlog ;
– Ordonner les éléments dans le Product Backlog ; et
– S’assurer que le Product Backlog est transparent, visible et compris.
Le Product Owner peut effectuer le travail ci‐dessus ou peut déléguer ce travail à d’autres. Quoi qu’il en soit, le Product Owner en demeure redevable.
Pour que les Product Owners réussissent, toute l’organisation doit respecter leurs décisions. Ces décisions sont visibles dans le contenu et dans l’ordre du Product Backlog et, via un Increment inspectable lors de la Sprint Review.
Le Product Owner est une personne et non un comité. Le Product Owner peut représenter les besoins de nombreuses parties prenantes dans le Product Backlog. Ceux qui souhaitent modifier le Product Backlog peuvent le faire en essayant de convaincre le Product Owner.
Fausse bonne idée ?
Le Product Owner est le SEUL responsable de la gestion du backlog produit. Cependant, dans certaines circonstances, il peut déléguer certaines tâches tout en conservant la responsabilité finale. Le Product Owner est une personne qui prend les décisions et les assume.
Si le proxy PO n’a pas accès aux utilisateurs ou n’a pas l’autorité pour définir les priorités… Il devra consulter le PO. Est-ce que cela ne reviendrait pas à ajouter un intermédiaire entre le Product Owner et l’équipe de développement ? Cette situation ne risque-t-elle pas de complexifier la communication en augmentant les risques d’incompréhensions conduisant à des réalisations inappropriées ?
Le rôle de Proxy Product Owner est souvent mis en place comme une phase transitoire lors de transformations organisationnelles, en comparaison avec les modèles Maîtrise d’Ouvrage/Maîtrise d’Œuvre.
En résumé
Si nous essayons de prendre du recul par rapport à toutes ces informations, ce Proxy Product Owner qui est responsable de la gestion du backlog produit, de prioriser les éléments du Product Backlog, de l’objectif de produit… Ne devrions-nous pas le considérer comme le véritable Product Owner ? Et le « faux » Product Owner, en fait, n’étant qu’une partie prenante ou un sponsor.
N’hésitez pas à partager votre vision dans les commentaires.