Lors du dernier article nous avons fait la distinction entre la culture de développement dite Projet et celle dite Produit. Nous avons aussi pu introduire le cadre de travail Scrum (l’une des méthodes les plus adaptées pour la gestion de problèmes complexes et changeants). Si l’un de ces termes ne vous est pas familier, n’hésitez pas à revenir à l’article précèdent. Sur cet article nous rentrerons plus en détail dans le rôle du Product Owner en soi, et puis nous finirons la trilogie d’articles par une présentation des outils qui peuvent lui être utiles lors de la réalisation de son travail.
La gestion du produit
Quand une entreprise veut créer un produit, ceci se matérialise au travers de plusieurs niveaux différents. Le tableau ci-dessous nous présente ces niveaux :
| Niveaux de planification |
| Vision de l’entreprise |
| Stratégie de l’entreprise |
| Vision du produit |
| Stratégie produit |
| Release |
| Sprint |
| Quotidien |
Les deux premiers niveaux sont généralement sous la responsabilité du PDG et/ou de l’équipe de direction, qui définissent la vision de l’entreprise à suivre ainsi que la stratégie pour l’accomplir.
Les deux derniers représentent des rituels clés dans toute approche Scrum, l’organisation du travail par Sprint et son suivi quotidien par le Daily meeting. Ces deux niveaux appartiennent aux développeurs, auto-organisés dans leur travail en accord avec les principes agiles.
Entre la vision organisationnelle globale et le travail quotidien de l’équipe, Don McGreal et Ralph Jocham introduisent dans leur livre The Professional Product Owner (2018), le concept du vide de la gestion du produit. Le tableau ci-dessous démontre cette notion et aide à comprendre le rôle du Product Owner.
Dans une entreprise qui suit une culture projet c’est dans ce vide que s’introduisent les activités typiques de la gestion de projets, en faisant de la gestion de tâches et de personnel, ce qui finit par déconnecter le résultat du travail de l’équipe de développement de la vision organisationnelle globale ainsi que du besoin des utilisateurs. Le succès d’un projet étant déterminé par le respect du contrat, avec des critères définis au préalable notamment le respect des coût et des délais, la qualité du produit final finit par être utilisée comme la variable d’ajustement.
Dans l’approche produit, l’objectif est de livrer le plus de valeur possible au client, et donc la qualité à livrer est non négociable. Le succès dans une approche produit étant défini par des métriques fonctionnelles comme l’adoption des nouvelles fonctionnalités par les utilisateurs, les activités liées à cette approche viendront faire ce lien entre la vision d’entreprise et le travail opérationnel au quotidien de l’équipe.
Le tableau ci-dessous montre quelques différences entre les deux modes de gestion :
Le Product Owner et le vide de la gestion de produit
Dans Scrum, c’est le Product Owner qui vient combler ce vide. Voici son impact sur chaque couche :
- La Vision Produit – le Product Owner, en travaillant avec les clients, est responsable de formuler et partager une vision claire et commune du produit à créer. Il lui revient aussi de faire évoluer cette vision avec toutes les parties prenantes (les développeurs, les utilisateurs, les clients).
- La Stratégie Produit – le Product Owner est responsable, avec les développeurs, de gérer l’évolution du produit. Ceci doit être fait pour atteindre les objectifs du client, ainsi que de satisfaire les utilisateurs du produit. Pour définir la stratégie produit, le Product Owner peut utiliser un outil connu comme la roadmap produit. Nous aborderons plus en détail cet outil (parmi d’autres) dans le prochain article de la série. En quelques mots, il peut aider à définir la stratégie produit en permettant de définir une projection à long terme des objectifs business à livrer, au travers d’une distribution de jalons dans un horizon temporel.
- La Gestion des Releases – si d’un côté le Product Owner doit envisager le long terme au travers de la stratégie produit, il coordonne aussi la stratégie de releases du produit à court terme. Ceci est fait en priorisant les objectifs à livrer en tenant compte des avis des différentes parties prenantes. Pour ce faire, il peut utiliser un plan de release. Contrairement à une roadmap produit, le plan de release peut être détaillé et précis, pouvant même définir des dates spécifiques. Cependant, il est important de tenir compte du fait que ce plan doit absolument donner une vision à court terme de ce qui sera fait.
Bien entendu, ce ne sera pas le rôle du Product Owner d’exécuter seul toutes ces tâches. Son travail est fait en forte collaboration avec les développeurs, les clients, les utilisateurs et les sponsors (qui peuvent ou pas être la même personne). Il reste, cependant, le principal responsable des résultats de ces activités.
Le vide de la gestion de produits et les trois V
Le risque du vide de la gestion de produits est qu’on occupe ce temps avec du management de tâches (rappelez-vous de l’importance du changement d’une culture Projet à une culture Produit ou du travail qui ne rajoute pas de la valeur au produit. Sans combler le vide, il est fortement possible d’être occupé sans avoir une direction claire sur où nous voulons aller.
Pour éviter le vide, Don McGreal et Ralph Jocham introduisent le concept des trois V : Vision, Valeur et Validation.
Vision
Le Product Owner doit établir une vision du produit qui représente la voix des clients, ce qu’ils veulent. Cette vision doit être claire, permettant au reste de l’équipe de prendre des décisions de façon autonome sur comment avancer vers elle. Ceci soutient directement l’onzième principe évoqué sur le manifeste Agile, renforçant le pouvoir de l’intelligence collective pour livrer un produit de haute valeur aux clients.
L’auto-organisation de l’équipe dépend non seulement d’une vision claire et partagée, mais aussi d’un cadre clair sur la façon de travailler. Scrum apporte un cadre pour le processus de travail, tandis que la vision est fournie par le Product Owner et un constant effort de communication dans toute l’équipe.
D’après Richard Hackman, ancien professeur de psychologie sociale et organisationnelle de Harvard, 30% de la probabilité de succès d’une équipe dépend de comment elle démarre (Leading Teams: Setting the Stage for Great Performances – Harvard University Press, 2002). Avoir une bonne vision qui a bien été communiquée à toute l’équipe est primordial pour que l’équipe démarre bien son travail. De plus, réussir à faire une connexion entre le travail quotidien et la vision du produit engendre généralement une équipe plus impliquée dans ce qu’elle fait.
Valeur
Dans la dernière version du Scrum Guide datant de novembre 2020, nous avons la définition de l’Objectif du Produit comme « un état futur du produit qui peut servir de cible à la Scrum Team pour planifier ». Avec cette définition, nous pouvons dire que définir la Valeur permet d’avoir des critères d’évaluation du produit. A titre d’exemple, imaginons être perdus sur une ile déserte. Notre Vision serait de survivre jusqu’à ce qu’on puisse être sauvé. La Valeur serait chaque étape à accomplir pour arriver à cette vision. Avoir la vision permet de nous situer sur ce qu’on veut et nous donne une direction à suivre, mais si nous ne faisons rien pour l’achever la valeur n’existera pas.
En continuant sur cette métaphore, l’équipe Scrum serait donc en charge d’identifier les étapes nécessaires pour notre survie, ainsi que de les exécuter. La première étape pourrait être quelque chose de crucial pour le succès de la vision, comme trouver une source d’eau potable, ou bien quelque chose de plus banal, comme trouver une belle place pour pouvoir regarder le coucher du soleil. Toutes les étapes à effectuer constitueront le Product Backlog (la liste ordonnée de ce qui est nécessaire pour améliorer le produit), qui est la source unique du travail accompli par la Scrum Team.
Il est important d’ordonner le Product Backlog en priorisant les tâches qui ajoutent le plus de valeur possible au produit. L’objectif d’une équipe travaillant en Scrum est de toujours être en mesure de livrer de la valeur aux clients à la fin de chaque Sprint. La Scrum Team doit compléter ou abandonner chaque tâche avant de passer à la suivante, d’où l’importance de bien prioriser. Une façon de choisir la priorité est de demander au client : « Si vous ne pouvez avoir qu’un seul livrable, quel serait-il ? ». À partir de là, c’est le rôle du Product Owner de continuer à creuser pour essayer de comprendre le besoin sous-jacent à ce que demande le client, et une fois ayant compris cela il faut définir comment sera manifestée la Valeur ajoutée.
Validation
Le troisième et dernier V des trois est la Validation. Nous pouvons faire un parallèle avec la méthode de gestion de la qualité PDCA (plan-do-check-act), aussi connue comme Roue de Deming :
L’acronyme PDCA est décrit plus en détail comme :
- Plan : planifier, préparer ;
- Do : développer, réaliser, faire ;
- Check : contrôler, vérifier ;
- Act (ou Adjust): agir, ajuster, réagir.
L’étape de vérification consiste ici à valider que ce qui a été planifié et développé répond bien à l’objectif souhaité, et l’étape suivante viendra construire le prochain cycle en ajustant par rapport aux résultats observés.
La Validation consistera donc de vérifier si les idées élaborées apportent vraiment de la valeur ou pas. Un des moments de validation pour une idée dans le Scrum se passe pendant la Revue du Sprint. Dans ce rituel toutes les parties prenantes ont l’opportunité de vérifier l’état actuel du produit et peuvent avoir un aperçu de quelles seront les prochaines étapes. Les retours remontés lors de la revue de sprint seront d’autant plus pertinents si les participants à cette revue sont les utilisateurs du produit et si cette revue est proche de la livraison de l’incrément présenté. Même si dans la Revue du Sprint tout se passe bien et toutes les parties prenantes semblent contentes, la vraie validation n’aura lieu que lorsque le produit sera livré et utilisé en production. Dans Scrum, la définition de Fini veut dire que l’incrément est potentiellement livrable. Cependant, pour avoir la validation ultime, nous avons besoin d’établir une boucle de retour avec la production. Pour cela, il est impératif de livrer aussi souvent que le business est capable de recevoir ces incréments.
Conclusion
La vision de l’entreprise et la stratégie business appartient aux cadres de direction de l’entreprise. L’organisation du travail quotidien en sprints appartient aux développeurs. Entre ces deux champs, en s’appuyant sur les 3 V, intervient le Product Owner. La relation entre la Vision, Valeur et Validation peut être résumée en :
- La Vision produit mène à la création de Valeur.
- La Valeur permet de Valider les hypothèses qui sont derrière les choix de développement du produit.
- La Validation donne l’opportunité de modifier et ajuster la Vision du produit par rapport à la réalité.
J’espère que cet article a pu vous apporter davantage de connaissances sur le rôle de Product Owner. Si c’est un rôle sur lequel vous souhaiteriez avoir une meilleure capacité professionnelle, n’hésitez pas à vous inscrire sur la prochaine formation ici chez Invivoo. Lors du prochain article nous aborderons les outils dont disposent le Product Owner pour réaliser son travail.
Pour toute question ou commentaire relatif à cet article, n’hésitez pas à me laisser un message ci-dessous.
