Est-il temps d’en finir avec les Product Owners?

Parmi les rôles agiles, celui de Product Owner est peut-être celui qui est le plus mal compris. Il est temps de remettre les pendules à l’heure. Cela passe sans doute par un solide dépoussiérage de la définition de ce rôle.

Revenons-en aux fondamentaux: le Product Owner a la responsabilité de constituer et d’ordonner une longue liste de desiderata formulés par les utilisateurs du produit. Cette liste est appelée backlog. D’après le Scrum Guide (Scrum étant, de loin, la méthodologie agile la plus utilisée), le rôle de Product Owner est assumé par une personne (pas par un comité) et elle/il est (je cite) “responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement”. Retenez ce bout de phrase: “responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement”. C’est là que c’est peut-être parti en vrille. Mais bon, à l’époque où Scrum a été imaginé (fin des années 90, début des années 2000), pas de souci: on est dans le cadre de projets digitaux, Agile, c’est pour les développeurs et, ma foi, ça fonctionne plutôt pas mal.

Pourtant, aujourd’hui, 20 ans plus tard (ça file!), cette définition a (très) mal vieilli. Elle est au minimum mal formulée, et au pire mal comprise (et donc mal appliquée). Voyons pourquoi.

D’abord, il y a le mot “Product”

Aujourd’hui, l’agilité est quasiment devenue un “way of life“. Ce sont des pans entiers du périmètre entrepreneurial qui sont gérés à la sauce agile: la politique commerciale, le marketing, l’administration, la production… Même le département légal et la finance se mettent à l’heure agile. Cela a-t-il encore du sens de considérer que le rôle de Product Owner se limite à une vision “produit”?

Bien-sûr, on pourrait remplacer “product” par “project”, mais ce serait encore pire… Vous imaginez? Il y aurait donc un “project owner”? Le remède serait pire que le mal. L’agilité, aujourd’hui, transcende toute vision cloisonnée qui se focaliserait sur un produit et/ou sur un projet. Elle est de facto devenue un mode de mise en mouvement durable, organique, qui trouve sa source à l’intérieur de l’organisation et qui a pour vocation de s’installer de manière très transversale. L’agilité transcende la gestion de projets en déployant dans les organisations un processus d’amélioration continue auto-géré et durable. Ce mouvement tend d’ailleurs à converger largement avec les principes de la gouvernance participative et de l’intelligence collective. Clairement, cela n’a plus rien à voir avec une vision “produit”.

Bien-sûr, l’agilité peut également se pratiquer en vase clos, dans une bulle se limitant à un projet ou à un produit. C’est d’ailleurs souvent comme cela que commencent les premières expérimentations, et il n’y a pas de mal à cela! Simplement, croyez-en mon expérience, quelques mois plus tard (et pour autant que l’organisation ne multiple pas les niveaux hiérarchiques), c’est souvent l’entreprise dans son ensemble qui s’inspire de ce mode de fonctionnement. Alors, produit ou projet, peu importe, tout le monde va être concerné. Autant le savoir. Inutile donc de s’accrocher à cette croyance qui consisterait à dire que l’agilité, ça sert à développer des produits.

Ensuite il y a “Owner”.

La question se pose: propriétaire de quoi? La réponse est évidente: de rien du tout… La responsabilité de livrer des solutions pertinentes revient à l’équipe. Après tout, c’est elle qui produit de la business value. S’il y a quelque part un “propriétaire du produit”, c’est donc davantage à l’équipe que revient ce titre, plutôt qu’à un soi-disant “product owner”.

La responsabilité fondamentale du Product Owner, c’est la pertinence du backlog. Ce n’est certainement pas la qualité du produit livré par l’équipe (comme Scrum.org pourrait avoir tendance à le faire croire). Cette pertinence est basée sur deux qualités fondamentales. D’abord le backlog doit refléter fidèlement et clairement les attentes des clients. Ensuite le backlog doit être ordonné, classé, il doit faire émerger (et idéalement transcender) la systémique de l’organisation (ou du projet, ou du produit). Quand ces deux qualités sont réunies, il devient alors exploitable, manipulable, actionnable. Et la mise en action peut dès lors se faire dans de bonnes conditions. Au travers de ce processus, de quoi le Product Owner est-il réellement “owner”? De pas grand chose, à part sa capacité à tendre l’oreille, à poser de bonnes questions, à laisser son intuition guider les interviews, à reformuler fidèlement et clairement et enfin à classer et structurer l’ensemble des desiderata qu’il aura collectés…

Et donc, le “Product Owner” ne s’occupe pas d’un produit, et il n’en est certainement pas propriétaire. Et donc on fait quoi?

Product Owner, un rôle à réinventer et à rebaptiser

Faut-il jeter le Product Owner avec l’eau du bain? Peut-être. Et pour commencer, jetons sans scrupule cette appellation anachronique, pour ainsi entamer la re-définition de ce rôle. Désolé, je n’ai pas d’appellation de rechange à proposer pour l’instant, mais par contre, pour ce qui est de la re-définition, je suggère de commencer d’une façon toute simple: il suffit de prendre à contre-pied la règle qui veut que le rôle de Product Owner revienne à une seule personne (alors Scrum.org le préconise pourtant explicitement).

Je propose tout simplement l’inverse: confions ce rôle à un comité. Dès lors, la figure du Product Owner “super héros” s’en trouvera déboulonnée. L’équipe qui le remplace sera chargée de collecter les besoins de manière très large. Ne nous y trompons pas: cela n’a rien à voir avec le fait d’être porteur d’une “vision produit”. En effet, plus la vision est puissante, moins la capacité à écouter les besoins est grande. Désolé de ressortir cet acronyme, mais dans un monde VUCA, les enjeux ne permettent plus de confier la “vision” à une seule personne. Vous alliez me parler de Steve Jobs? Il en est mort… La vision, c’est devenu un exercice many-to-many (many questionneurs de sens qui dialoguent avec many rêveurs du futur). Les outils pour de tels dialogues collégiaux existent déjà, leur pratique s’installe. Allez voir du côté de l’intelligence collective, de la sociocratie, du co-dev etc. C’est là que cela se passe. Il serait dommage que les agilistes, engoncés dans leur méthodologie, passent à côté d’outils tellement riches et puissants.

Autre bénéfice collatéral: puisqu’il s’agira d’une équipe, ce groupe de personnes fera également appel aux capacités de coaching du scrummaster. Et donc cette équipe va, elle aussi, se mettre à rétrospecter sur son propre fonctionnement. Ce qui l’amènera sans doute à la réflexion que sa Definition of Ready n’est rien d’autre qu’un “méta-backlog” sur lequel il est également possible d’itérer.

Bref, il s’agit de mettre un peu d’intelligence collective dans ce rôle, de cesser de croire qu’un PO providentiel est indispensable, de cesser de croire que la vision est quelque chose qui doit venir d’une personne inspirée. En somme, il s’agit tout simplement d’entamer enfin un mouvement convergent entre l’agilité et les techniques de facilitation inspirées par l’intelligence collective.

En remplaçant le Product Owner par une équipe de Product Owners, la balance s’équilibre: Product Owners et Team Members sont à pied d’égalité, et l’agilité gagne peut-être en élégance. Nous avons d’une part une équipe de PO qui développe sa capacité à écouter, à clarifier et à transcrire les besoins des utilisateurs. Leur enjeu est d’être compris par les Team Members. Et puis nous avons par ailleurs une équipe de Team Members qui développe sa capacité à fournir des solutions efficaces et pertinentes. Leur enjeu est d’être compris par les utilisateurs. Une équipe focalisée sur la compréhension des besoins, une équipe focalisée sur la mise en oeuvre des solutions. C’est élégant. Cela permet une réelle dynamique, une “tension constructive” entre ces deux équipes. Cela évite de constater le grand retour du “project manager” déguisé en “product owner”.

Je crois que l’agilité a tout à y gagner. Et vous, qu’en pensez-vous?

Envie de réagir?
Contactez-moi.

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search