C’est décidé, vous allez lancer un projet en mode agile. Vous allez mettre en place une équipe qui va travailler en mode itératif, en essayant de « faire du Scrum ». Vous avez un Scrum Master, on vous demande de désigner un PO, un Product Owner. 

En tant que manager, vous ne voyez pas trop quel rôle va jouer ce PO, peut-être un peu celui d’un chef de projet ? Vous vous demandez : « mais pourquoi me dit-on que c’est un rôle à plein temps. En tant que manager, je n’ai personne que je peux déléguer à temps plein sur un projet. Mon équipe est déjà débordée de travail et si c’est pour faire chef de projet, alors où est l’intérêt de passer en mode agile ? »

Avant d’aller plus loin dans ces questionnements du manager, posons quelques éléments du vocabulaire agile.

Parties-prenantes (Stakeholders) : ce sont toutes les personnes qui ont des attentes vis-à-vis du produit ou du projet en cours. Ce sont donc les clients, les utilisateurs, ceux qui vont en assurer le service ou la maintenance. Probablement aussi les donneurs d’ordre, des managers, peut-être la direction de l’entreprise, s’il s’agit d’un produit ou projet stratégique.

Equipe agile : une équipe qui travaille en mode agile, notamment Scrum. L’équipe agile a vocation à être autonome, pluridisciplinaire et auto-organisée. Le manager ne devrait pas gérer une équipe agile comme si c’était une équipe « ordinaire ». 

Management agile : l’agilité, ça se conjugue à tous les niveaux. Dans la direction des entreprises, on parlera de « business agility », pour les managers, on parlera de management 3.0 ou de management agile, dans les équipes opérationnelles on parlera d’outils et de méthodes. Et à tous les niveaux, on parlera d’intelligence collective, d’autonomie responsable, d’engagement, de transparence, de courage…

Product Owner (PO) : ce fameux rôle à plein temps n’est en rien celui d’un chef de projet. Le PO est un rôle spécifique créé pour travailler en mode agile. Le PO est un maximiseur de valeur, son travail sera donc centré sur la valeur, pas sur la technique ni sur l’organisation. Il s’avère que 25% des projets développés ne sont jamais utilisés et que de nombreux projets sont abandonnés en cours de route, après avoir coûté des sommes considérables. Par exemple, le projet Scribe, prévu pour la police française, arrêté en décembre 2021 après plusieurs années de travail et quelques millions d’euros déjà dépensés. Ou, dans un autre registre, le projet de navettes vers la lune, contracté entre la NASA et Boeing et Lockheed Martins, qui a coûté des milliards sans aucun résultat après plusieurs années (le contrat sera probablement dénoncé et un nouveau contrat sera signé avec SpaceX, entreprise agile, mobilisée vers la production de valeur). 

Le rôle du PO est donc de produire ce qui a de la valeur, le plus vite possible et au moindre coût, sans sacrifier la qualité et, bien sûr, d’éviter les échecs monumentaux, grâce à sa vigilance permanente sur l’utilité réelle de tout travail effectué.

Pour gérer les aspects organisationnels, l’équipe aura un Scrum Master (SM) et pour la technique, il y aura une équipe de réalisation. 

La valeur, donc ! Qu’est-ce que la valeur ? Où se trouve-t-elle ? En effet, avant de la « maximiser » encore faut-il l’avoir identifiée, challengée, quantifiée. C’est le premier aspect du rôle du PO.

Le PO va discuter avec les parties prenantes afin de bien cerner leurs besoins. Il va se forger une connaissance fine de ces besoins et des convictions quant à la manière d’y répondre. C’est sur ces bases qu’il va créer une vision et qu’il va la porter au sein de l’équipe agile et de manière plus globale, au sein de l’entreprise. Il va naturellement endosser la responsabilité de dire « qu’est-ce que l’équipe doit faire » pour créer le meilleur produit qui soit, celui qui répondra le mieux aux besoins, et qui apportera le plus de valeur à l’entreprise, au meilleur coût et dans les meilleurs délais.

Cette vision du produit à réaliser, le PO va l’affiner sans cesse. En effet, pendant qu’elle travaille, l’équipe va découvrir des choses, poser des questions, potentiellement remettre en cause certains partis-pris… c’est ainsi, par exemple que l’on peut éviter le “panier” systématique dans un site d’e-commerce grâce à la créativité d’un développeur qui propose une “commande en un 1 clic”.

Les parties-prenantes, de leur côté, en voyant leur produit prendre forme au fil des itérations, vont avoir des nouvelles idées, des envies de modifications, parfois justifiées et parfois moins. Le PO sera alors responsable de faire évoluer son produit afin d’assurer qu’il soit toujours au plus près des attentes des parties-prenantes et que la valeur produite soit toujours maximisée.

Ce travail est permanent. Le PO ne se contente pas d’avoir des idées. Il doit les formaliser sous la forme d’un backlog produit.

Backlog produit : liste priorisée de ce qu’il faut faire pour réaliser le meilleur produit le plus vite possible. Le Backlog produit est de la responsabilité du PO. C’est le PO qui le crée, qui le priorise et qui le met à jour, en permanence et notamment à chaque sprint s’il travaille en mode Scrum. Le backlog sera généralement structuré sous la forme d’éléments de travail de granularité variable. Les plus gros éléments (des grandes fonctionnalités) seront découpés au fil du temps en éléments de plus en plus petits (épics, features…) jusqu’à rédiger des User Stories (US). 

User stories (US) : Les user stories sont des petites fonctionnalités ou parties de fonctionnalités, qui sont décrites du point de vue de l’utilisateur (avec une rédaction sous forme de « user voice » : en tant que xxx, je veux xxx, afin de xxx). Chaque US contiendra aussi des critères d’acceptation, qui serviront de base de tests pour les développeurs. Les US sont rédigées par le PO, avec l’aide des développeurs, notamment pour les critères d’acceptation. 

Exemple d’US simplifiée

Le PO sera également responsable de veiller à ce que tous les développements fournis par l’équipe de développements soient bien conformes aux exigences fonctionnelles. Notamment, il va tester tout ce qui sera développé lors de chaque itération (ou sprint) et c’est lui qui validera le travail réalisé. A défaut, il demandera les corrections et autres ajustements nécessaires avant de valider. Les tests du PO sont des tests fonctionnels, pas des tests techniques, qui ont sont totalement de la responsabilité de l’équipe de développement.

Tout ce travail effectué par le PO, en amont du projet et pendant son déroulement, exige du temps. 

Le rôle du PO est clé dans la réussite d’un projet. Il incombe donc au manager de comprendre ce rôle et de donner au PO la légitimité de l’assurer et le temps nécessaire pour l’effectuer concrètement. Dans beaucoup de cas, le PO seul, même à plein temps, ne pourra pas effectuer toutes les tâches qui lui incombent. Le manager veillera alors à lui donner les moyens de réussir, notamment en lui apportant le soutien d’une ou plusieurs autres personnes.

Que peut donc faire le manager pour le PO ?

1. Comprendre le rôle et lui accorder la légitimité requise. Le PO doit notamment disposer du pouvoir de dire NON. Et aussi du pouvoir de dire OUI. Le PO est ainsi responsable de tenir le budget et c’est lui, en arbitrant le backlog et en gérant les priorités, qui décide comment ce budget sera utilisé.
2. Donner au PO les moyens de réussir : du temps et de l’aide si nécessaire.
3. Soutenir le PO en montrant de l’intérêt pour son travail. Cela se manifeste notamment par la présence du manager aux « sprint reviews », à la fin de chaque sprint, le moment où le PO et l’équipe agile partagent avec les parties-prenantes le résultat du travail effectué pendant le sprint. Ce sont des moments de convivialité où l’équipe montre le travail effectué (démo) et les parties-prenantes discutent librement avec le PO et l’équipe, amènent du feed-back sur le produit et parlent des itérations à venir.

Que peut faire le PO pour le manager ?

Le PO dispose d’un indicateur précieux qui va à la fois rendre visible le travail effectué par l’équipe et l’intérêt de son rôle : le burn-up. Le burn-up (les lignes courbes dans le schéma ci-dessous) suit l’avancée vers la cible (les lignes brisées en haut du schéma).

 Le PO peut créer différents types de burn-up, basés sur le travail effectué, exprimé en temps ou en effort. Ce type de burn-up (courbes bleue et verte) ressemble à un suivi de projet traditionnel. Les courbes sont presque linéaires car elles montrent juste l’effort produit, ce qui permet de voir que le travail avance au fil du temps, ce qui, finalement, n’a pas beaucoup d’intérêt. 

Le burn-up agile vraiment pertinent est celui qui suit la création de valeur (courbe rouge du schéma).

Il se présente sous la forme d’une courbe et d’une cible. Plus la valeur produite est forte au début du projet, plus la courbe sera prononcée en avançant vite vers la cible, comme le dessin d’une colline. Lorsque la courbe commence à s’aplatir, la question se pose : faut-il continuer ou arrêter le travail. En effet, une grande partie de la valeur a déjà été produite et livrée. Est-il intéressant de fournir beaucoup d’effort (de temps, de budget…) pour produire le peu de valeur qui reste ? Ceci est une décision du PO, en accord avec ses parties-prenantes.

Sans PO totalement impliqué, il n’y a pas de maximisation de la valeur et l’intérêt de l’agilité est très réduit. Les PO qui n’ont pas le temps ne produisent pas de burn-up sur la valeur. La capacité à produire cette jolie courbe en forme de colline est d’ailleurs un des indicateurs du niveau d’agilité d’une équipe.

Puisque le rôle du PO est de créer le plus de valeur le plus vite possible, ce burn-up est un indicateur très précieux, aussi bien pour le PO que pour le manager. En suivant la courbe du burn-up, le manager aura une idée très précise sur l’avancement des travaux, sur la base de la réalité et pas de la théorie. Il sera également rassuré sur la capacité de son PO à bien jouer son rôle, maximiser la valeur. 

Ce que l’on gagne en travaillant de cette manière :

• Satisfaction du client : Un projet réalisé en mode agile répondra mieux aux besoins des clients et des utilisateurs, grâce à l’implication du PO. 
• Economie de temps et de moyens : le PO va prioriser au plus vite ce qui apporte le plus de valeur. Il n’y a plus d’injonction de « tout faire », au contraire, l’injonction est de faire ce qui en vaut la peine. Ce travail de priorisation et de tri incombe au PO.
• Relations fluides : le PO joue son rôle au sein de l’équipe agile et le manager joue son rôle de manager en lui déléguant les responsabilités liées à ce rôle (et les moyens lui permettant de réussir). Le PO invite le manager aux revues de sprint et communique sur l’avancement des travaux via le burn-up.

Articles associés :

Le rôle clé du client dans un projet agile

Histoires de PO

Pour en savoir plus sur le rôle du PO, le burn-up et la relation entre le PO et le manager, contactez-nous…