À la découverte du rôle de Product Owner
PO, acronyme de Product Owner, désigne un rôle au sein de l’organisation d’une équipe Agile utilisant la méthodologie SCRUM. Nous reviendrons dans un premier temps rapidement sur les fondamentaux de l’Agilité et de Scrum avant de présenter en détail le PO, quel est son rôle et quels sont les enjeux de son poste. Nous conclurons par les qualités nécessaires à l’épanouissement dans cette mission.
Agilité, Scrum et petit rappel
Si vous abordez cet article, vous êtes certainement déjà bien rodé sur les notions d’Agilité et de Scrum. Ce court chapitre n’a pas vocation à vous faire découvrir ces concepts, mais à rappeler éventuellement à ceux qui y sont moins familiers quelques bases afin de mieux appréhender ce qui va suivre.
Agilité
On appelle méthodes Agiles un mode de fonctionnement dans le cadre du développement de logiciels informatiques. La vocation de ces méthodes Agiles est de permettre le changement quand il est nécessaire au cours d’un projet en maximisant la flexibilité de l’équipe vis-à-vis du besoin du client. Ceci sans compromettre la qualité du produit final. De nombreux projets au cours de ces dernières années ont vu leurs coûts et leurs délais exploser en raison d’un périmètre variable, remettant en cause les choix architecturaux, le tout se faisant au détriment de la qualité. En conséquence, la maintenance devient très problématique comme peut en témoigner nombre de consultants intervenant sur des missions de M.C.O. (Maintient en Conditions Opérationnelles).
En résumé, les méthodes Agiles cherchent à garantir la flexibilité et la qualité du produit en gardant la maîtrise sur les délais et la communication sans négliger le retour sur investissement. C’est ce dernier aspect, le ROI (Return On Investment, ou Retour Sur Investissement en français, c’est-à-dire le rapport entre ce que coûte le projet et ce qu’il rapporte), qui fait le succès des méthodes Agiles auprès des décideurs et qui doit être le leitmotiv de la pensée du PO.
Scrum
Scrum est une méthode Agile de plus en plus répandue. Cette méthode vise à livrer un produit pleinement fonctionnel, dans un temps plus court, tout en fournissant une valeur métier plus élevée. Scrum s’attache à livrer régulièrement un produit fini afin notamment de vérifier son adéquation avec le besoin. Ces cycles courts sont appelés des Sprints. Un changement de cap ou une mauvaise interprétation de la demande initiale peut ainsi être corrigé dans les plus brefs délais. Ainsi la méthodologie Scrum permet une remise en question de ce qui a été fait pour garder en tête la finalité du produit. Quel service va-t-il rendre ? Qu’est ce qui est le plus judicieux à l’instant T ? Cette segmentation dans la constitution ou l’évolution du produit permet au client de s’exprimer tout au long du parcours.
Dans la méthodologie Scrum, le Product Owner définit les priorités et l’équipe s’organise d’elle-même pour produire les fonctionnalités. En livrant rapidement un produit exploitable, on obtient un ROI plus rapide et garanti par l’adéquation avec la demande formulée peu de temps auparavant. Sur le long terme, le ROI est également garanti par l’interaction permanente entre le client et l’équipe de développement.
« Y a-t-il un PO dans l’équipe ? »
Mais qui est le PO ? Le PO est avant tout une personne. C’est lui qui possède la vision globale du produit, qui priorise les éléments du Product Backlog et détermine l’orientation stratégique du projet.
Son objectif est de donner un maximum de valeur au travail de l’équipe (et non pas de tirer un maximum de bénéfice du travail de l’équipe, nuance).
Le rôle du PO
- CHIFFRAGE : Le PO explique l’User Story (US – Brève description d’une fonctionnalité à développer, typiquement sous la forme d’une phrase de type : “En tant que ***, je souhaiterais ***, pour *** ) dans le cadre des réunions de chiffrage avec l’équipe. Il répond aux questions. Si des difficultés à établir le chiffrage apparaissent, le PO devra réécrire ou découper l’US en question et la soumettre à un chiffrage ultérieur. Le PO ne doit pas interférer dans le chiffrage. Cette responsabilité revient à l’équipe.
- PRIORISATION : Seul le PO priorise les US au sein du Product Backlog. Il s’agit de décider quelle US devra être réalisée en premier, en tenant compte du ROI et de la stratégie. Un ensemble de plusieurs US peut être nécessaire pour permettre la mise en production d’une nouvelle fonctionnalité. De même, il peut être nécessaire de réaliser plusieurs US afin de permettre de dégager le ROI associé. Pour ces raisons, le PO est amené à réaliser des sous-ensembles (MMF – Minimum Marketable Features et MMR – Minimum Marketable Releases) et à les inclure dans sa priorisation.
- SPRINT PLANNING : Sur la base de la vélocité prévue par l’équipe pour le sprint à venir, le PO présente le Product Backlog à l’équipe. A ce stade, les US sont priorisées et chaque US présente le chiffrage donné précédemment par l’équipe. C’est ensuite l’équipe qui va décider quels éléments du Product Backlog seront embarqués, en respectant toutefois la priorisation du PO. C’est-à-dire que l’équipe ne peut pas sélectionner les US qu’elle souhaite n’importe où dans le Product Backlog. Le premier élément est sélectionné. S’il reste des points de vélocité disponibles, on prend le second élément, et ainsi de suite jusqu’à épuisement des points de vélocité. C’est ainsi qu’est constitué le Sprint Backlog. Suite à cela, le PO peut quitter la réunion tandis que l’équipe va créer les tâches à partir des US embarquées dans le sprint. Le PO doit néanmoins rester disponible pour revenir répondre aux éventuelles questions de l’équipe.
- DAILY STAND-UP MEETING : Lors du DSM, la présence du PO est un élément plutôt positif. En effet, bien que sa présence ne soit pas obligatoire, c’est un moment privilégié pour rencontrer l’équipe, échanger, apporter des informations et se tenir au courant de son actualité.
- Pendant le SPRINT : Il convient de déterminer quelques demi-journées (selon la longueur du sprint) où le PO sera présent sur le plateau et à la disposition de l’équipe pour répondre en détail à ses questions et pour apporter des indications sur sa validation aux User Stories du Sprint Backlog.
- DEMO : Lors de la démo, le PO a vocation à éviter l’installation de débats. Il doit prendre des notes sur les questions, les remarques. C’est lors de cette réunion qu’une US est définitivement validée ou rejetée. Même si une faible portion de l’US est manquante, elle ne devra pas être considérée comme validée (d’où l’importance de consulter le PO lors du sprint). Elle sera donc remise dans le Product Backlog. Comme la partie restante à faire sera faible, le ROI de l’US sera mécaniquement très élevé, lui accordant une priorité haute.
- RETROSPECTIVE : Le PO peut assister à la Rétrospective de l’équipe, selon les affinités. D’un côté, on peut considérer que le PO est un membre à part entière de l’équipe et qu’à ce titre il a tout à fait sa place à la Rétrospective. D’un autre côté, on peut considérer que sa présence est un frein à la libre expression des membres de l’équipe et que cela rend donc la Rétrospective contre-productive.
Les enjeux du PO
Le Product Owner est la porte d’entrée du métier (business) dans l’univers technique. Il s’agit d’un point stratégique, à la frontière de ces deux univers où la bonne communication sera un élément clé et déterminant du succès du projet.
Le PO évite de devoir refaire plusieurs fois la même chose, il augmente donc le ROI de l’équipe. Il augmente également l’acceptation du projet par une meilleure adéquation avec le besoin du client.
Le PO aura pour principale tâche la priorisation des US. Prioriser, c’est définir la valeur ajoutée. Cela s’articule autour de 5 facteurs que sont :
- La valeur financière : Elle peut s’exprimer par l’acquisition de nouveaux clients, par de nouvelles ventes, par la fidélisation de clients existants, par la mise en place d’opérations réduisant les coûts futurs ou encore par l’ouverture de nouveaux marchés par exemple. Cette valeur peut s’exprimer de manière absolue, tout simplement en Euros, mais également de manière relative avec une unité abstraite : le Business Value Point. Son établissement est empirique, à la manière des points de complexité chiffrés par les développeurs.
- Le coût de développement : En connaissant le coût de l’équipe et la vélocité moyenne, on peut définir le coût d’un point de complexité. Chaque US possédant une cote en point de complexité, cela nous donne le coût de l’US.
- Le gain de connaissances : Il peut se faire à 2 niveaux, Produit ou Projet. Au niveau Produit, le gain de connaissance s’apparente au test d’une fonctionnalité (POC, proof of concept ; un prototype), ou à la mise en place d’un élément inutile dans le présent mais ouvrant des opportunités futures. Au niveau Projet, il peut s’agir de la capitalisation sur un choix technique, une architecture, une technologie. Cela peut également être l’apprentissage du travail en équipe, la détermination des compétences requises ou l’entraînement à la réalisation de meilleures estimations. Ce peut enfin être la recherche de la simplification du design.
- Le facteur de risque : Assez souvent, une grande valeur ajoutée va de pair avec un grand risque. Une forte valeur ajoutée pour un risque faible représente un très fort intérêt, alors qu’une valeur ajoutée faible pour un risque fort nécessitera une sérieuse remise en question.
- Le désir de cette fonctionnalité auprès du client : Il est intéressant de permettre au client, voire de lui imposer, de catégoriser les US dans 3 catégories :
- Must have: Ce sont les fonctionnalités essentielles dont l’absence remettra en cause la viabilité du projet.
- The more, the better: Il s’agit là des fonctionnalités permettant d’augmenter l’envergure du produit, de lui apporter un plus grand intérêt.
- Nice to have: Avec les fonctionnalités périphériques dont l’intérêt pourrait presque être discutable et dont la considération ne doit venir qu’après la résolution de toutes les autres exigences.
Il convient de noter ici qu’il peut y avoir plusieurs niveaux de priorisation. En effet, le PO doit posséder une vision du projet sur plusieurs échelles. Pour cela, il devra prioriser des Epic Stories (ensemble d’User Stories convergeant vers un but commun) au niveau d’une Release afin de produire dans un livrable des éléments cohérents. À l’inverse, dans le cadre d’un sprint, ce sont les User Stories qu’il devra prioriser.
Le dernier élément de la priorisation est l’interaction entre plusieurs User Stories au sein d’une même Epic Story. Il peut y avoir, au sein d’une Epic, un sous ensemble d’US dont la réalisation intégrale est indispensable à la génération de valeur. Dans ce contexte, même si une de ces US possède un ROI individuel plutôt faible, cette US ne doit pas être écartée car elle conditionne un ROI global. Si toutes les Epics sont complétées à 95% mais qu’aucune ne peut être envoyée en production en l’état, une grosse partie de l’intérêt de l’Agilité est perdue. Il convient de déterminer quelle Epic est la plus intéressante et de la terminer afin de la pousser en production, avant de se pencher sur les suivantes. Un logiciel fonctionnel est la première mesure du progrès apporté.
Quelles qualités pour un bon PO ?
Généralement, le PO est un représentant des utilisateurs du système ou un membre du marketing. Le PO se doit d’avoir une bonne connaissance des utilisateurs finaux du produit, du marché et des futures tendances, bien que cela dépende grandement de la nature de ce qui est développé. L’essentiel est que le PO possède une bonne vision du produit et de ce qu’il doit devenir.
Le PO est bien organisé. Il possède une vision claire et s’engage à ne pas modifier les règles du jeu en cours de route. Durant le sprint, le périmètre ne doit pas varier (dans la mesure du possible) malgré la pression extérieure en provenance du métier. C’est à ce prix que l’équipe peut s’engager à respecter la vélocité convenue.
En parallèle, le PO doit être capable de prendre des décisions pertinentes, mais devra en plus être autonome et responsable de ses prises de position. Un PO sans libre-arbitre et soumis à toutes les décisions de sa hiérarchie ou d’une autre équipe perd tout son intérêt.
Le communication sera également un élément clé à la réussite du PO et conditionnera la réussite du projet. Le PO, en plus d’interagir avec un grand nombre de personnes, devra avoir un impact sur celles-ci. Il devra savoir se faire écouter. Un PO sans charisme et n’inspirant pas confiance ne présente qu’un intérêt limité. Le PO doit être capable de véhiculer des informations différentes à des personnes différentes, à tout moment, en s’adaptant à son interlocuteur.
Le PO, en tant qu’interface entre plusieurs équipes sera très sollicité. En plus d’une disponibilité hors pair, il devra pouvoir répondre à toutes les questions métiers de l’équipe de développement afin de pas la ralentir. À l’inverse, on pourra lui demander des explications / rapports côté métier sur l’état et l’avancement de la réalisation.
Enfin, le PO doit posséder un esprit d’entrepreneur en s’appropriant le produit et en gardant toujours une démarche proactive.
© SOAT
Toute reproduction interdite sans autorisation de l’auteur