Qu’est-ce qu’un product owner
Voici la définition donnée par le Guide Scrum :
« Le product owner est chargé de maximiser la valeur du produit résultat du travail de l’équipe de développement. La manière dont cela est fait peut largement varier selon les organisations, les équipes Scrum et les individus eux-mêmes. »
Presque toutes les équipes agiles ont une personne qui joue le rôle de product owner. Mais qu’est-ce exactement qu’un product owner, et quels sont les défis les plus courants auxquels il est confronté ? Cet article apporte des éléments sur ce rôle clé en répondant aux questions suivantes :
- Est-ce que seules les équipes scrum ont un product owner ?
- Comment un product owner peut-il mesurer la valeur du produit développé par l’équipe ?
- Quelles sont les responsabilités exactes du product owner ?
- Quelles compétences et expertise un product owner doit-il avoir ?
- Quels sont les devoirs du product owner ?
- Qu’est-ce que la gestion du backlog produits ?
- Quels paramètres sont utilisés pour mesurer la valeur des bénéfices fournis par le produit ?
- Quels défis le product owner est-il censé surmonter ?
- Conclusion
Est-ce que seules les équipes scrum ont un product owner ?
Le rôle de product owner prend ses origines dans la méthode Scrum. Cependant, de nombreuses équipes agiles ont quelqu’un qui s’occupe des tâches associées – même si elles n’utilisent pas la méthodologie Scrum.
Dans la programmation extrême (une autre approche agile en dehors de Scrum), par exemple, il y a le rôle appelé « client sur site » ou « mandataire du client ». Bien que cette personne fasse partie de l’équipe de développement du produit, son rôle est de représenter le client vis-à-vis des développeurs.
On comprend vite pourquoi ce rôle est nécessaire : La plupart des équipes agiles travaillent avec des solutions innovantes. Elles assument souvent l’entière responsabilité de « leur » produit, depuis le développement jusqu’à son remplacement éventuel, en passant par l’amélioration et la maintenance. Naturellement, l’équipe a besoin qu’une personne prenne la responsabilité de s’assurer que ce travail va dans la bonne direction dès le départ. Cette personne peut être le product owner.
Que fait un product owner ?
La personne occupant le rôle de product owner s’assure que le produit :
- Sert le marché et offre des solutions pour répondre à la demande existante ou nouvelle.
- Fournit à ses collègues des solutions vraiment sensées et utiles, moyennant un effort raisonnable (s’applique au développement interne de produits pour les autres départements de l’organisation).
- Répond aux exigences convenues par les parties prenantes dès que possible et que l’équipe de développement comprend ces exigences. Idéalement, toutes les parties concernées doivent pouvoir s’identifier à la solution.
- Peut atteindre un stade de développement avancé dans un délai donné, éventuellement par incréments sous la forme de résultats intermédiaires convenus.
- Fournit des gains rapides afin de garantir les liquidités nécessaires à la poursuite du développement.
- Répond aux attentes internes et externes en matière de qualité.
- Permet de satisfaire les parties prenantes – surtout les clients – moyennant un effort et un coût raisonnables, sans que la liste des exigences ne devienne interminable.
- Conserve sa position concurrentielle ou, mieux encore, est en avance sur la concurrence.
Quelles sont les responsabilités exactes du product owner ?
Dans le triangle ouvert et contraire de l’environnement agile, c’est le product owner qui porte la responsabilité première d’équilibrer et de prioriser le périmètre, le coût et le planning du produit.
Avec l’équipe de mise en œuvre, le product owner est également en charge de s’assurer que les exigences de qualité sont respectées. Certains des modèles triangulaires considèrent qu’il s’agit d’une dimension supplémentaire à prendre en compte.
On peut donc dire que les product owners assument une grande partie des tâches traditionnellement gérées par les chefs de projet.
Cependant, les chefs de projet sont également responsables de la création de l’équipe projet, de l’attribution des tâches aux membres de l’équipe projet et du suivi de leur travail. Ils peuvent également être impliqués dans le lancement du projet, par exemple en sélectionnant les projets ou en réalisant des études de faisabilité.
C’est généralement différent pour les product owners :
- Une perspective de produit axée sur les solutions
- Les product owners agiles s’occupent d’une perspective de produit axée sur les solutions tout au long du cycle de vie de leur produit. Ils réfléchissent à leur produit et à ses utilisateurs, y compris aux processus opérationnels après le développement initial. Ce faisant, ils se détachent de la réflexion purement orientée projet.
- Backlog initial
- L’une des premières tâches du product owner est typiquement la création du backlog initial (la liste de toutes les exigences du produit) en collaboration avec les parties prenantes, et parfois avec l’équipe de développement elle-même ou son représentant.
- Mise en œuvre détaillée du produit
- L’entreprise du projet a déjà été décidée par exemple par la direction du produit, qui dans un contexte agile, a une perspective supérieure du portefeuille. Le product owner, en revanche, se consacre à la mise en œuvre dans le détail d’un produit.
- Soutien des coaches agiles
- Le développement de l’équipe, la résolution des conflits, la conception des processus et des règles pour la coopération sont du ressort des coachs agiles (ou des Scrum Masters dans la méthodologie Scrum). Ils assistent également les product owners dans leurs tâches.
- Consultation / coordination avec l’équipe développement
- L’équipe de développement qui est en auto-organisation est responsable de la répartition des tâches. Elle assume également, dans une large mesure, la responsabilité de la qualité des itérations. Cependant, l’équipe doit souvent se coordonner avec le product owner pour s’assurer qu’elle ne s’écarte pas des objectifs, des exigences et des réalités du marché.
- Responsabilité partagée avec l’équipe développement
- Au lieu de faire des rapports, les développeurs montrent où ils en sont par le biais de démonstrations régulières des résultats de leur travail (par exemple, les nouvelles fonctionnalités du produit). Lors de la revue du produit pour les parties prenantes, à la fin de l’itération, le product owner et l’équipe de développement recommencent tout cela ensemble pour tous ceux qui ne font pas partie de l’équipe de produit agile. Ensemble, ils assument la responsabilité de leurs propres résultats.
Quelles compétences et expertise un product owner doit-il avoir ?
Les responsabilités principales du product owner sont d’évaluer et d’équilibrer différents facteurs tels que :
- Le coût, la profitabilité, et le retour financier du développement du produit, la satisfaction client et le potentiel de commercialisation,
- La liste souvent sans fin des souhaits et exigences clients et la capacité de l’équipe de développement,
- La productivité de l’équipe, la qualité et les bénéfices des résultats,
- Mesures proactives (analyse des risques, développement de nouvelles fonctionnalités, intégration), mesures réactives (tests, résolution de bugs, maintenance).
Idéalement, le product owner peut trouver un bon équilibre entre ces facteurs souvent divergents. Mais ce n’est pas une tâche facile. Pour vraiment comprendre ces facteurs, la personne qui occupe ce poste doit posséder et utiliser les connaissances et les compétences exigées des chefs de projet y compris les connaissances et compétences suivantes :
- Calculs de profitabilité
- La capacité à garantir que la solution développée propose les avantages attendus (ingénierie des bénéfices)
- Méthodes d’analyses des risques
- Analyse des exigences et techniques de priorisation pour gérer le backlog produit
- Analyse des parties prenantes et une aptitude pour traiter avec ces personnes
- Confiance en soi et bonnes capacités de négociation
- Une sensibilisation à l’innovation
- Compétences humaines, y compris dans les relations avec l’équipe de développement.
Quels sont les devoirs du product owner ?
Les principaux devoirs du product owner sont les suivants :
1) Fixer les objectifs et définir la vision
- Fixer les objectifs et faire en sorte de les réaliser
Les product owners doivent fixer les objectifs généraux et les suivre sur le long terme. Les développeurs en revanche, doivent réaliser le travail technique pour réaliser ces objectifs, étape par étape. - Développer une vision pour le produit
Les parties prenantes collaborent avec l’équipe développement pour développer la vision du produit, qui guide ensuite les efforts pour la suite. Un exemple : L’application « BestDoc » est une plateforme permettant de trouver un médecin, de consulter des avis et de faire un rendez-vous. Elle est utilisée par les individus pour chercher les meilleurs praticiens dans leur région. Mais cette formule peut aussi être vue comme un slogan ou une phrase inspirante ou motivante).
2) Impliquer les parties prenantes tôt et souvent
Pour comprendre les intérêts des parties prenantes, le product owner doit également comprendre les parties prenantes elles-mêmes. Il est du devoir du product owner de tenir compte de ces intérêts et, si nécessaire, de les filtrer pour l’équipe développement.
3) Gérer la planification à haut niveau
- Planifier les itérations en avance
Préparer bien en avance le contenu des 1 à 3 prochaines itérations et présenter le plan global à l’équipe pour atteindre ces objectifs. - Planifier les packs de version
Fixer les objectifs généraux et développer un planning efficace : par exemple quelle fonctionnalité sortira et quand.
4) Mesurer le succès et les bénéfices
Définir des paramètres qui peuvent être utilisés pour mesurer de manière réactive les avantages réels du produit et sa valeur ajoutée.
5) Créer et maintenir un backlog produit
Gardez toujours cette vue d’ensemble à jour et affinez-la, ou assurez-vous que quelqu’un d’autre la crée pour le product owner.
6) Préparer les revues de sprint
Quelles sont les principales parties prenantes qui seront invitées et qu’est-ce qui leur sera montré ? Quel retour d’information souhaitez-vous obtenir de leur part ? Quels membres de l’équipe sont disponibles et quelles fonctionnalités peuvent-ils montrer dans la démo ?
7) Participer activement aux rétrospectives
Quels sont les progrès réalisés par notre équipe ? Disposons-nous des bons outils et processus ? Comment pouvons-nous nous améliorer ? Le product owner ainsi que les membres de l’équipe poursuivent les efforts internes de l’équipe pour promouvoir l’amélioration continue.
Qu’est-ce que la gestion du backlog produits ?
Le guide scrum guide donne des informations sur ce point, disant que le backlog produit comprend les aspects suivants :
- Documenter de façon claire et concise toutes les entrées dans le backlog produit,
- Trier les entrées du backlog produit de manière à faire progresser de façon optimale les objectifs,
- Optimiser la valeur du travail réalisé par l’équipe développement,
- Veiller à ce que le backlog produit soit visible, transparent, clair pour tout le monde et qu’il montre ce sur quoi l’équipe scrum travaillera ensuite,
- Veiller à ce que l’équipe développement ait la compréhension nécessaire des entrées du backlog produit.
Bien entendu, même cette liste issue du guide Scrum ne couvre pas la totalité des choses rencontrées dans la pratique. Mais elle n’avait pas pour objectif d’être exhaustive. Un bon product owner est quelqu’un qui sait gérer l’ingénierie des exigences dans un contexte agile.
Affiner le backlog produit implique des activités telles que :
- Prendre des décisions sur le contenu du backlog
- Que doit-on inclure dans le backlog et que doit-on en exclure ? Savoir dire « non » aux parties prenantes pour des demandes qui sont inadaptées ou pas réalistes à ce stade. Une organisation doit respecter les décisions du product owner même si cela est parfois difficile. Il faut aussi ici ajouter de nouvelles entrées dès que c’est nécessaire et supprimer celles devenues superflues.
- Prendre des décisions sur le type d’entrées
- Descriptions fonctionnelles, spécifications, résolutions de bugs, exigences non fonctionnelles telles que la sécurité, l’évolutivité, la maintenabilité ? Ou bien la description de la solution axée sur les résultats du point de vue du client (témoignages d’utilisateurs) en une phrase courte ? Une combinaison des deux est logique car aucun de ces types d’entrées seules ne répond entièrement aux exigences d’un produit.
- Prendre des décisions sur les exigences et le calendrier
- Quelles sont les exigences pour quelle itération et version ? Plus précisément, cela relève de la responsabilité de toute l’équipe lors de la planification des itérations. La plupart des parties prenantes veulent aussi avoir leur mot à dire à ce sujet. Une cartographie des témoignages utilisateurs peut être utile.
- Préparer les estimations de coûts
- Obtenir de l’équipe des estimations approximatives de l’effort à réaliser. Parce qu’au niveau du backlog produit, les exigences sont principalement formulées du point de vue de l’utilisateur. La décomposition en tâches n’est effectuée que lors de la planification des itérations. Les tâches sont ensuite intégrées dans le backlog de l’itération.
- Prioriser les entrées
- Normalement ceci est juste une liste linéaire dans le backlog produit. Cela signifie que la priorité vient de l’ordre des items de la liste. Les items les plus en haut de la liste doivent être mis en œuvre plus tôt que les entrées qui se trouvent plus bas dans la liste.
Notre astuce : Concentrez-vous uniquement sur les entrées les plus en haut de la liste quand vous formulez et évaluez les entrées. Les entrées en bas de liste sont moins importantes car elles peuvent encore changer voire même disparaître.
Cette stratégie en ligne avec le principe du « juste à temps » vous permet d’éviter de gaspiller votre énergie sur des besoins qui ne sont pas immédiats. Elle utilise les critères DEEP. Cela vous aide à garantir que lorsque vous travaillez avec des backlogs produits, vous suivez des principes agiles et pas seulement un planning en cascade sous un nouveau nom.
Notre astuce : Si l’utilisation d’une stratégie plate et linéaire pour prioriser les entrées du backlog n’est pas suffisante, vous pouvez également utiliser la méthode du User Story Mapping (cartographie des témoignages utilisateurs) pour une gestion multidimensionnelle du backlog.
Quels paramètres sont utilisés pour mesurer la valeur des bénéfices fournis par le produit ?
Cette question ou quelque chose d’assez semblable, est une question qui revient souvent dans les examens de certification tels que ceux de Scrum.org. Au départ, cela semble être une question difficile. Comment pouvons-nous, en tant qu’équipe, mesurer la valeur de notre produit ? Certainement pas basé uniquement sur notre productivité. Celle-ci peut être élevée mais si les résultats sont faux, cela n’est pas très utile.
Par contre, le management basé sur les preuves (“Evidence-based management“), définit plusieurs paramètres, dont certains ne sont pas très connus. Mais les product owners peuvent les trouver plutôt utiles.
Le management basé sur les preuves reconnaît quatre catégories principales pour les paramètres individuels :
- Valeurs actuelles :
Mesure l’acceptation et l’utilisation du produit par le marché. On prend également en compte le moral de l’équipe qui le développe. Quel est le degré de satisfaction des investisseurs potentiels ?
Exemples de mesures : Cette catégorie comprend, par exemple, les indices de satisfaction des clients (tels que ceux fournis par les enquêtes et les commentaires sur le produit), des mesures indiquant la relation entre l’utilité des différentes fonctions et le degré de satisfaction des clients à l’égard de ces fonctions particulières.
- Time-to-Market
Cette mesure indique le temps qui s’écoule entre le moment où une nouvelle exigence est formulée initialement et celui où l’auteur reçoit la solution. À quelle vitesse pouvons-nous traiter de nouvelles informations et les utiliser ?
Exemples de mesures : Fréquence de publication des versions, fréquence d’intégration, temps de traitement des entrées dans le backlog et délai de livraison.
- Capacité à innover
Cette mesure indique à quel point le processus de recherche d’une solution est innovant. Quel est le degré d’innovation du produit et de sa fonctionnalité ? Cette question doit également être posée lors de la poursuite du développement d’un système mature dans une grande entreprise.
Exemples de mesures : Avantages des différentes fonctions par rapport aux autres, efforts ou dépenses associés à de nouveaux développements (en pourcentage) par rapport à des activités telles que la maintenance, et temps que l’équipe consacre effectivement au produit (par rapport à d’autres tâches).
- Valeur non réalisée
Cette mesure tient compte du potentiel (encore) non réalisé. Cela vaut-il la peine d’y regarder de plus près ?
Exemples de mesures : Parts de marché, attentes des utilisateurs par rapport à ce qu’ils ont reçu.
Notre astuce : Ces mesures sont particulièrement utiles quand elles sont suivies sur une période longue car les développements et tendances sont alors plus visibles.
Quels défis le product owner est-il censé surmonter ?
Jusqu’à présent, nous avons examiné de près le rôle du product owner et quelques-uns de ses outils principaux et ses tâches. Nous allons maintenant nos pencher sur les défis auxquels les product owners sont confrontés dans leur travail quotidien
Les enquêtes menées auprès des product owners et des développeurs par les coachs agiles ont montré que les principaux défis sont les suivants :
- La pression du temps
- Problèmes possibles – Le rôle n’est peut-être pas pourvu à plein temps mais doit quand même être réalisé en plus du travail opérationnel. Trop de produits et d’équipes doivent être gérés simultanément. L’équilibre entre temps consacré aux parties prenantes et temps consacré aux équipes est difficile à trouver.
Solution possible – Analyse de la cause : Quelle est la véritable raison pour les problèmes de temps ? Que peut-on changer ? Y a-t-il des méthodes de gestion du temps qui pourraient s’appliquer et aider ? Peut-être faut-il revoir les priorités des projets et des besoins ?
- Manque de connaissances sur les tâches
- Problèmes possibles – Le product owner en sait trop peu sur son propre rôle et sur le développement agile. Le rôle est souvent attribué sans plus d’explication ou de formation.
Solution possible – Plus de formation, accès à des ouvrages tels que le livre très reconnu « Professional Product Owner » de Don McGreal et Ralph Jocham.
- Manque d’expertise outil
- Problèmes possibles – Le product owner ne connaît pas les outils, les documents, les mesures nécessaires à son travail.
Solution possible – Discussion sur les outils pour créer des visions et des feuilles de routes pour les produits, pour définir les stratégies de planification des versions, outils de management basé sur les preuves et enfin les outils d’analyse des parties prenantes.
- Manque de pouvoir de décision
- Problèmes possibles – Le product owner n’est pas autorisé à prendre de décisions. Les voies hiérarchiques sont trop compliquées et longues.
Solution possible – Escalade et discussion de ces problèmes avec la direction
- Problèmes impliquant les parties prenantes
- Problèmes possibles – Manque de participation et d’intérêt de la part des parties prenantes, conflits entre les parties prenantes sur les priorités à donner, trop de parties prenantes.
Solution possible – Analyse des parties prenantes, apprendre et appliquer des techniques de modération, analyse des besoins réalisée conjointement avec les parties prenantes, implication de coachs agiles.
- Problèmes avec la structure organisationnelle
- Problèmes possibles – Complexité organisationnelle élevée et problèmes symptomatiques de « silos ».
Solution possible – Raccourcir les boucles des retours de commentaires avec l’aide de coachs agiles. - Des projets trop complexes
- Problèmes possibles – Projets faisant intervenir de nombreuses entreprises différentes. Le product owner et les développeurs ne font pas partie de la même entreprise.
Solution possible – Ceci ne doit pas forcément être un problème, mais c’est un sujet dont il faut s’occuper consciencieusement. La mise en place de contrats et d’accords entre les équipes aide dans ce sens.
- Environments très régulés
- Problèmes possibles – L’environnement/l’industrie rend les méthodes de travail “légères” difficiles en raison de superstructures de processus.
Solution possible – Intelligence situationnelle, concentration sur une bonne culture de l’erreur et un apprentissage aussi rapide que possible face aux circonstances extérieures.
Les products owners ne peuvent pas, et ne doivent pas, résoudre tous ces problèmes seuls. Il faut habituellement la participation de la direction et de toutes les personnes impliquées ainsi qu’un bon accompagnement/coaching.
Notre astuce : Si vous rencontrez l’un de ces problèmes dans votre organisation, il est conseillé de les traiter le plus rapidement possible en les signalant à la personne ou le bureau en charge.
Conclusion
Dans cet article nous avons abordé les thématiques suivantes :
- Les devoirs du Product Owner
- Les défis que le Product Owner doit relever
- Les paramètres pour mesurer les bénéfices d’un produit
- Ce que la gestion du backlog produit comprend
Pour résumer : Un bon product owner peut apporter une contribution précieuse au succès de l’entreprise sur le marché. Cette personne occupe un poste très intéressant et influent offrant de nombreuses possibilités. Toutefois, la personne qui occupe ce poste peut également être confrontée à des défis difficiles.
Si vous êtes (ou souhaitez devenir) product owner, soyez prêt à un apprentissage continu des méthodologies, outils, et des relations humaines.
L’aventure vous tente ?
Si la réponse est oui, alors explorez l’utilisation des méthodes agiles dans vos équipes et vos projets. Si vous souhaitez en savoir plus et approfondir vos connaissances, envisagez de suivre une formation de développement professionnel pour devenir Professional Scrum Master (PSM I) ou PMI Agile Certified Practitioner (PMI-ACP).
Les méthodes agiles sont-elles adaptées à votre environnement de travail ? Nous sommes curieux de vos retours. Laissez-nous un commentaire !
Antje Lehmann-Benz (PMP, PMI-ACP, PSM expert / formatrice en Méthodologie Agile) – Antje Lehmann-Benz, PMP, enseigne la gestion de projet et se concentre particulièrement sur des séminaires sur les questions Agiles et Scrum. Elle a également de l’expérience dans la formation aux logiciels (JIRA et Confluence) et en consulting. En plus d’enseigner les cadres et la théorie, elle est également expérimentée dans l’utilisation de jeux et d’exercices pratiques Agiles pour renforcer les connaissances acquises.
