Quand le Product Owner ne peut pas vraiment décider
Le Guide Scrum est clair au sujet du Product Owner : c'est une seule personne, responsable de maximiser la valeur du produit, qui détient le Product Backlog et son ordonnancement. Pour que cela ait un sens, l'organisation doit respecter les décisions que prend le Product Owner. Quand ce n'est pas le cas — quand le titre existe mais pas l'autorité —, Scrum conserve ses cérémonies et perd son sens. En 2022, avec des budgets comprimés par l'inflation et des équipes partagées entre maison et bureau, un Product Owner incapable de trancher devenait vite l'élément le plus lent de tout le système.
La plupart des défaillances suivent quelques schémas récurrents. Il vaut la peine de les nommer, car chacun a une correction concrète.
Où l'autorité du Product Owner se rompt
Le prête-nom sans mandat. On donne le titre à une personne junior, mais chaque vraie décision remonte à un comité directeur ou à un cadre supérieur. Les Développeurs attendent, le backlog s'enraye, la valeur s'érode. La correction : confier le rôle à quelqu'un en qui l'organisation a confiance pour décider, ou déléguer réellement l'autorité à la personne qui porte le titre.
Le backlog par comité. Quand plusieurs parties prenantes exigent chacune que leurs éléments passent en premier, l'ordonnancement devient un théâtre de négociation. Le Guide Scrum est clair : une seule personne décide de l'ordre. Recueillez largement les avis, mais la séquence finale revient au seul Product Owner.
Le scribe, pas le décideur. Certains Product Owners se contentent de relayer des demandes et de rédiger des tickets. C'est de l'administration, pas de la propriété de produit. Le rôle existe pour arbitrer la valeur — dire non, reporter, choisir. S'ils ne disent jamais non, ils ne portent pas le produit.
Absent au moment crucial. Un Product Owner qui saute la Planification de Sprint, ignore la Revue de Sprint ou reste injoignable pendant le Sprint force les Développeurs à deviner. Les suppositions deviennent des reprises. Le rôle exige une vraie disponibilité, pas une apparition au calendrier.
Aucun Objectif Produit clair. Sans Objectif Produit pour servir de repère, le backlog devient une liste de souhaits et la priorisation tourne à l'arbitraire. Le Product Owner fixe et communique cet objectif pour que chaque décision d'ordonnancement ait une référence.
Rétablir un Product Owner qui peut décider
La solution est rarement une meilleure personne ; c'est le plus souvent un mandat plus clair et la discipline organisationnelle de l'honorer. La direction doit soutenir publiquement les décisions du Product Owner, même impopulaires, et résister à l'envie de les casser d'en haut en plein Sprint.
Désignez un seul Product Owner par produit et accordez-lui de vrais droits de décision, visibles.
Laissez les parties prenantes influencer le backlog par le Product Owner, pas en le contournant.
Fixez un Objectif Produit pour que chaque décision de priorité renvoie à quelque chose de concret.
Protégez le temps du Product Owner afin qu'il soit présent et joignable durant tout le Sprint.
Faites en sorte que la direction défende les décisions du Product Owner au lieu de les renverser discrètement.
Un test utile : le mois dernier, à quoi ce Product Owner a-t-il dit non ? Si la réponse est « rien », l'autorité est décorative. La vraie propriété de produit se manifeste par des arbitrages délibérés qui déplaisent à certains — car choisir ce que l'on construit revient toujours à choisir ce que l'on ne construit pas, et quelqu'un doit assumer ce choix et le défendre.
Si vos Product Owners portent le titre mais pas l'autorité, le conseil en réalisation de programmes et de projets de XNM peut vous aider à instaurer le mandat et la gouvernance qui leur permettent de vraiment décider.