L'organisation

Le Product Owner

Dans Scrum, une seule personne décide de l'ordre dans lequel le produit sera construit et répond de la valeur qu'il apporte : le Product Owner. Quatre patterns d'A Scrum Book expliquent pourquoi cette responsabilité ne se partage pas, comment le Product Owner se fait aider quand le produit grossit, d'où vient la fierté du produit et ce qui change quand l'équipe travaille pour un client extérieur.

Un comité qui ne tranche pas

Une petite entreprise édite un logiciel de prise de rendez-vous pour les cabinets de kinésithérapie. Le premier lundi de chaque mois, cinq responsables se réunissent pour fixer les priorités des développeurs.

La directrice commerciale ouvre la séance : « Il nous faut l'export comptable avant la fin du trimestre, deux gros clients l'attendent. » Le responsable du support n'est pas d'accord : « Mes conseillers passent leurs journées sur les erreurs de synchronisation des agendas. L'urgence est là. »

Après deux heures, le comité produit une liste de quatorze demandes, toutes classées « priorité 1 ». Les semaines suivantes, chacun passe voir les développeurs pour faire avancer la sienne. Trois mois plus tard, l'export comptable est à moitié fait, la synchronisation échoue toujours et personne ne sait dire qui a décidé quoi.

Le gérant confie alors la liste à Claire, une ancienne kinésithérapeute qui forme les clients depuis six ans. Chacun peut lui proposer une demande, mais elle seule en fixe l'ordre, et elle explique ses choix. Scrum appelle cette liste le Product Backlog (la liste ordonnée de tout ce qui pourrait améliorer le produit) et la personne qui en répond le Product Owner.

Le pattern Product Owner : une personne et une liste ordonnée

A Scrum Book (2019) présente Scrum sous forme de patterns : chacun décrit un problème récurrent, les forces qui s'opposent et une solution tirée de l'expérience. Le pattern Product Owner (« propriétaire du produit ») y porte deux étoiles, la note que les auteurs donnent aux solutions dont ils pensent qu'une équipe Scrum finira par avoir besoin.

Le problème. Les membres de l'équipe ont besoin d'une liste unique et ordonnée pour concentrer leur travail sur ce qui a de la valeur. Sans elle, l'équipe risque de construire des fonctions que personne n'utilisera et qu'il faudra pourtant maintenir, de livrer au mauvais moment ou de ne rien livrer. Quelqu'un doit donc répondre de cette liste, avec assez de connaissance du métier et assez d'autorité pour la classer.

Les forces. La première tentation est le comité, comme dans la scène précédente. Croiser plusieurs points de vue est utile, mais le livre observe que ces comités représentent surtout les services internes de l'entreprise, loin du marché où se trouve la valeur. Ils manquent souvent d'autorité, les discussions tournent à la négociation entre services et la liste finale est un compromis peu cohérent qui arrive tard.

La seconde tentation est de nommer un chef de projet. Le livre lui adresse deux reproches. L'entreprise construit un produit et non un projet : quand le projet s'arrête, le produit continue de vivre chez ses utilisateurs. De plus, le chef de projet est jugé sur le délai et le budget et répond rarement de la valeur produite, ce qui l'incite à des décisions de court terme.

La solution. L'organisation se dote d'un Product Owner qui ordonne le Product Backlog et prend la responsabilité de la vision du produit et de la valeur obtenue en la réalisant. Il a le dernier mot sur le contenu du produit et sur l'ordre de livraison, et il devient l'interlocuteur unique pour ces questions. Le livre lui demande de répondre du retour sur investissement, c'est-à-dire du rapport entre ce que le produit rapporte et ce qu'il coûte.

Tout le monde peut proposer un élément pour le Product Backlog, mais c'est le Product Owner qui le place dans la liste. Les développeurs renvoient vers lui toute personne qui voudrait modifier leurs priorités. Il représente l'ensemble des parties prenantes, clients compris : le livre note que Scrum n'a pas de rôle « client » distinct. Quand plusieurs équipes travaillent sur le même produit, il n'y a toujours qu'un seul Product Owner et un seul Product Backlog.

Ce que dit le Guide Scrum 2020

Le Guide Scrum de Ken Schwaber et Jeff Sutherland, dans son édition de 2020, va dans le même sens avec moins de détails. Le Product Owner y est redevable (il doit en rendre compte) de la maximisation de la valeur du produit issu du travail de la Scrum Team, l'équipe complète. Il l'est aussi de la gestion du Product Backlog : formuler le Product Goal (l'objectif de produit), créer et expliquer les éléments de la liste, les ordonner et s'assurer qu'elle est visible et comprise. Il peut déléguer ce travail, mais il en reste redevable.

Le Guide ajoute que le Product Owner est une seule personne et non un comité, et que toute l'organisation doit respecter ses décisions. Celui qui veut changer le Product Backlog doit donc le convaincre.

Trois écarts séparent le livre du Guide de 2020. Le livre, paru en 2019, dit encore « Development Team » et « ScrumMaster », quand le Guide écrit « Developers » et « Scrum Master ». Le livre s'appuie sur la Vision du produit, tandis que le Guide introduit en 2020 le Product Goal. Enfin, le livre confie au Product Owner le retour sur investissement, la feuille de route et le plan de livraison, que le Guide ne mentionne pas.

Product Owner Team : se faire aider sans devenir un comité

Au bout d'un an, Claire n'y arrive plus seule. Elle doit rencontrer les cabinets, suivre les concurrents, répondre aux développeurs et préparer les éléments des prochains Sprints (les périodes de travail de durée fixe, d'un mois au plus, qui rythment Scrum). Les éléments arrivent mal préparés et les développeurs perdent du temps à deviner ce qui est attendu.

Le problème que traite le pattern Product Owner Team (« équipe du Product Owner », une étoile, soit une bonne solution qui n'est pas forcément la seule) est exactement celui-là : le Product Owner a plus de travail qu'une personne ne peut en faire correctement.

Les forces. Demander aux développeurs de faire ce travail déplace la charge et réduit leur capacité de production. Recruter des spécialistes autour du Product Owner crée des passages de relais où la compréhension du client se perd. Il faut pourtant garder un point unique de responsabilité, sans quoi le comité revient.

La solution. Plusieurs personnes forment une Product Owner Team dirigée par un Chief Product Owner, qui garde l'autorité finale sur l'ordre du Product Backlog. Les autres membres l'aident à préparer les éléments et à les découper avec les développeurs. Le livre insiste sur un point : ces membres ne « possèdent » rien, et le Chief Product Owner reste le seul Product Owner. Il recommande aussi que cette petite équipe travaille au même endroit.

Claire s'entoure ainsi d'une conceptrice d'interfaces et d'un conseiller du support, présents deux jours par semaine. Ils préparent les éléments avec elle, et l'ordre de la liste reste sa décision. Le Guide Scrum ignore le titre de Chief Product Owner, mais il autorise la délégation tant que le Product Owner reste redevable du résultat.

Product Pride : la fierté du produit

Le pattern Product Pride (« fierté du produit », une étoile) s'ouvre sur une histoire connue. Un passant demande à trois ouvriers d'un chantier ce qu'ils font. Le premier répond qu'il pose des briques, le deuxième qu'il monte un mur et le troisième qu'il bâtit une cathédrale.

Le problème. Les membres d'une équipe ont besoin de savoir que leur travail compte et d'avoir leur mot à dire sur la façon de le faire.

Les forces. La pression du marché ou de la hiérarchie pousse à livrer vite. L'équipe prend alors des raccourcis, la qualité baisse et le travail à reprendre s'accumule. Une équipe qui livre en dessous de ses propres exigences perd la fierté de ce qu'elle fait. Le Product Owner peut aussi être en cause : s'il n'a pas de contact direct avec les clients ou pas d'autorité pour décider, la Vision devient floue et l'équipe réserve son énergie à des projets annexes.

La solution. Le livre demande de créer un climat qui rend possibles l'autonomie, la maîtrise et le sens, les trois sources de motivation décrites par Daniel Pink dans Drive (2009). Il précise que personne ne peut imposer ni décerner cette fierté, et qu'elle apparaît quand ces conditions sont réunies. Concrètement, l'équipe participe à la définition de l'objectif de chaque Sprint, réunit les compétences nécessaires pour finir son travail et reçoit les retours du marché sur ce qu'elle a livré. Le Product Owner est le premier porteur de cet enthousiasme, et le rendre communicatif fait partie de son travail.

Development Partnership : quand l'équipe travaille pour un client

Le pattern Development Partnership (« partenariat de développement », une étoile) traite le cas où une organisation confie le développement de son produit à une autre, qu'il s'agisse d'un prestataire ou d'un autre service de la même entreprise.

Le problème. Les frontières entre organisations ne correspondent pas à la façon dont le produit se construit. Chacun garde ses procédures, les exigences passent de main en main, les développeurs sont partagés entre leur employeur et leur client, et la méfiance conduit à des contrats au périmètre figé qui laissent presque toujours un mécontent.

Les forces. La question centrale est de savoir qui emploie le Product Owner. Le client connaît le métier et doit garder la main sur le contenu, et le prestataire veut maîtriser sa rentabilité. La réponse habituelle place chez le prestataire un Product Owner « par procuration » (proxy), qui répond aux questions à la place du vrai. Le livre juge ce montage coûteux : le dialogue se transforme en deux monologues, et ce représentant ne peut rien trancher.

La solution. Le client et le prestataire concluent un partenariat qui abaisse les murs entre eux. L'accord initial fixe les règles : travailler au même endroit autant que possible, partager équitablement les risques, ajuster en continu la définition de ce qui sera livré et viser une relation longue. Le Product Owner travaille chez le client, parce qu'il doit être au plus près de la valeur. L'équipe s'installe idéalement dans les locaux du client. À défaut, le Product Owner passe une grande partie de son temps avec elle : le livre cite comme arrangements réussis au moins six heures par jour quatre jours par semaine, ou quatre heures chaque jour, et il écarte la simple participation à une réunion téléphonique quotidienne.

Limites et pièges

Le piège le plus courant est le Product Owner sans autorité. Si chaque décision doit remonter à un comité de direction, la personne qui porte le titre transmet des messages, et le comité de la première scène existe toujours sous un autre nom.

Le deuxième piège est le Product Owner absent. Une personne qui cumule ce rôle avec un poste de direction ne répond pas à temps, et les développeurs devinent ou attendent.

Le troisième est l'excès inverse : un Product Owner qui décide seul, sans écouter les développeurs. Le livre précise que le Product Backlog reflète idéalement un consensus, en particulier avec l'équipe, et que le dernier mot du Product Owner vient conclure cette discussion.

La solution elle-même a une fragilité : tout repose sur une personne qui doit connaître le métier, comprendre la technique, avoir l'autorité de décider et rester disponible. Ce profil est rare, et les auteurs l'admettent. Par ailleurs, le retour sur investissement est un critère commode pour un produit vendu, mais il convient mal à une école, à un hôpital ou à une association. Le Guide Scrum parle d'ailleurs de valeur sans la réduire à un chiffre.

Enfin, ces patterns viennent de l'expérience de praticiens. Les étoiles expriment la confiance des auteurs, sans mesure à l'appui. L'article Critiques et état des preuves fait le point sur ce que l'on sait de l'efficacité de Scrum.