Caractéristiques d'un Product Owner
Auteur : Shane Hastie (@shanehastie)
Source : Product Owner Patterns (InfoQ)
Date : 20/03/2011
Traducteur : Fabrice Aimetti
Date : 27/03/2011
Traduction :
Le rôle du Product Owner est régulièrement débattu dans de nombreux forums et blogs. La diversité des responsabilités et les défis que comportent ce rôle constituent de fréquentes sources de discussions et de prises de position.
Récemment, il y a justement eu quelques discussions sur les aspects fondamentaux du rôle du Product Owner et les actions importantes qu'il réalise dans le cadre d'un projet agile.
Mary Poppendieck a écrit un article sur le sujet "The Product Owner Problem" où elle constate les choses suivantes :
"Découvrir quelles sont les bonnes choses à construire est l'étape la plus importante dans le processus de création d'un bon produit. Si vous ratez cette étape, vous générez 100% de gaspillage. Déléguer à un unique Product Owner les décisions sur ce qu'il y a à construire, c'est externaliser le travail le plus important de l'équipe de développement à une personne qui n'a probablement pas la connaissance ou les compétences suffisantes pour réellement prendre de bonnes décisions. L'inconvénient de la plupart des implémentations du rôle de Product Owner, c'est l'idée qu'il prépare de façon détaillée les stories à développer par l'équipe. Cela ne permet pas aux membres de l'équipe de devenir des partenaires et des collaborateurs sur la conception du produit."
Mary Poppendieck discute ensuite des différents aspects du rôle du Product Owner et de la diversité des responsabilités portées par ce rôle :
"Dans Scrum, le Product Owner est un rôle mais ne devrait pas être un poste de travail dans l'entreprise. Le Product Owner a plusieurs casquettes : Chef Produit, Ingénieur Système, Ergonome, Architecte Logiciel, Analyste Métier, Ingénieur Qualité et même Rédacteur Technique. Nous ferions mieux d'utiliser ces intitulés de poste bien connus plutôt que d'en inventer un nouveau qui soit ambigu et qui, de surcroît, tend à créer un goulot d'étranglement empêchant l'équipe de développement de jouer son rôle principal de concepteur de logiciel."
Dans le même ordre d'idée, John Mansour évoque la confusion entre le rôle de product owner et celui de chef produit. Dans son article intitulé "Agile Product Owner – New Name, Same Old Problem", il précise que l'équipe doit assurer deux rôles importants :
"1. Le rôle du "quoi et pourquoi" : la responsabilité pour déterminer "quelles" fonctionnalités devraient être mises en œuvre dans le produit et "pourquoi" d'un point de vue métier et marché concurrentiel. Ce rôle du "quoi et pourquoi" pilote tous les aspects internes et externes. Ce rôle a pour objectif primordial d'aligner le produit avec la dynamique du marché et les besoins des clients. La responsabilité du "quoi et pourquoi" est typiquement du ressort du Chef Produit. Que la démarche soit traditionnelle ou Agile, ce rôle est nécessaire quelle que soit la personne, son titre ou la manière d'y arriver.
2. Le rôle du "comment" : la responsabilité pour déterminer "comment" les fonctionnalités du produit doivent fonctionner pour que les utilisateurs puissent travailler. Dans sa forme la plus simple, ce rôle est délégué à un utilisateur pour expliquer sous forme orale, écrite et illustrée ce que les utilisateurs font, comment ils le font et comment le logiciel devrait "fonctionnellement" travailler pour aider les utilisateurs. Evidemment, les personnes les mieux placées pour ce rôle sont d'anciens utilisateurs ou celles qui ont travaillé aux côtés de nombreux utilisateurs dans de nombreux contextes."
John Mansour précise que de nombreuses équipes agiles font l'erreur de combiner les deux rôles pour le product owner, ce qui produit une direction floue et de la confusion.
"A mon humble avis, la confusion repose sur deux choses. Premièrement, les sociétés logicielles ont essayé de combiner les responsabilités de Chef Produit et de Concepteur fonctionnel du produit pendant des années et c'est à chaque fois un cauchemar, du moins pour ce que j'en ai vu... et j'en ai vu. La crise d'identité est la même entre le chef produit et le product owner dans le monde agile.
Quelle que soit la méthode de développement, combiner ces rôles conduit immanquablement à l'échec puisque les compétences et profils requis sont complètement distincts, sans parler du niveau de disponibilité exigé lorsqu'ils sont combinés, le résultat final ressemble à la bonne fonctionnalité mais peu utilisable ou des fonctionnalités très utilisables mais qui n'intéressent personne. Dilemme que l'on peut résumer par la formule "souhaitez-vous perdre un bras ou une jambe aujourd'hui ?".
Vous trouverez d'autres commentaires, avis, suggestions et idées pour tirer le meilleur du rôle du product owner. Monica Yap a commencé à publier une série d'articles sur le sujet "Product Owner Anti-patterns". Elle a identifié les anti-patterns suivants :
- le Product Owner absent
- copier le dernier Product Owner
- le Backlog change tout le temps
- la longue Définition du Fini qui ne veut rien dire
- le Product Owner n'est pas unique
- pas assez de parties prenantes
Jack Milunsky a identifié les 10 principales activités d'un product owner :
1. Crée et MAINTIENT le Backlog du produit.
2. Priorise et trie le Backlog en fonction de la valeur métier ou du ROI.
3. Aide à élaborer les Epics, Thèmes et Features et les découper en stories utilisateurs de granularité assez fine pour être traité dans un sprint.
4. Porte la Vision et les Objectifs de chaque Version et Sprint.
5. Représente le Client et s'engage pour lui.
6. Participe aux mêlées quotidiennes, aux réunions de planification de sprint, aux revues de sprint et aux rétrospectives.
7. Inspecte l'avancement du produit à la fin de chaque sprint et a toute latitude pour accepter ou rejeter le travail réalisé.
8. Peut changer le cours du projet à la fin de chaque Sprint.
9. Communique sur l'état d'avancement autour de lui.
10. Termine le sprint courant si un changement radical est nécessaire.
