J’ai commencé à écrire ce qui suit en tant que réponse à un article publié sur UX Planet intitulé Pourquoi l’Agilité ne fonctionne pas!

L’article était plutôt intéressant et pointait des travers souvent rencontrés des équipes Agiles, comme la mauvaise hiérarchisation des fonctionnalités et le saucissonnage des développements, souvent guidés par la facilité de développement plutôt que par leur intérêt. Sur le fond, cet article pointait plutôt sur la criticité du rôle du Product Owner dans la conception du produit.

Non, le rôle du Product Owner n’est pas d’être une sorte de manager. Il devrait être le Champion de l’utilisateur, dans le sens chevaleresque du terme. C’est le garant de la vision, celui qui voit le paysage et oriente les développement en prenant en compte les objectifs futurs. Il ne doit jamais oublier ou réside la valeur et c’est ce qui doit demander à l’équipe de développement. C’est lui qui pousse le gros Domino qui fera tomber tous les autres.

 Il est tristement vrait que ce rôle est probablement le plus mal compris et souvent le moins bien tenu dans de nombreuses équipes Agiles. Trop de Product Owner croient que leur rôle concerne la gestion de l’équipe, perdant au passage ce que l’agilité leur avait donné: la capacité à rester focalisé sur la vision et faire confiance à l’équipe pour en faire une réalité.

Un PO est particulièrement mauvais s’il se focalise sur les Story Points souvent utilisés pour mesurer la velocité d’une équipe. Du point de vue d’un utilisateur les Story Points représentent le prix de la fonctionnalité. Il est symptomatique de notre époque que le réflexe de nombreux consommateurs consiste à acheter n’importe quoi, pourvu que ce ne soit pas cher… Je ne prétends d’ailleurs pas non plus l’inverse. Ce n’est pas parce qu’une fonctionnalité est coûteuse à développer qu’elle aura plus de valeur.

La véritable tâche d’un Product Owner devrait consister à s’interroger sur la valeur pour l’utilisateur de chaque User Story. Le seul intérêt du prix c’est de disposer d’une approximation grossière de la date de livraison ou de l’effort nécessaire. Et si ce prix est trop élevé la bonne option pourrait être d’opter pour une évolution complètement différente du produit, et sans doute de revoir sa copie et de reconsidérer les User Stories envisagées plutôt que de foncer dans le noir. Les développeurs parlent de tunnel pour ces développements ambitieux mais dont on ne voit pas le bout et beaucoup de projets finissent écrasés dans ces tunnels.

Un bon Product Owner est une ressource rare et précieuse et apporte une valeur déterminante, c’est d’ailleurs vrai qu’il fasse ou non partie d’une équipe Agile.Toute équipe de développement – Agile ou non – devrait disposer d’un visionnaire capable d’imaginer le produit en cours de création. L’aspect agréable dans les organisations Agiles c’est qu’il s’agit d’un rôle dédié, ce qui est plutôt rare dans les équipes non Agiles.

Si celà permet à certains de mieux mesure l’importance critique que peut prendre un Product Owner, il me semble qu’être un excellent Product Owner était l’une des qualités premières de Steve Jobs. C’est clairement son coté visionnaire qui a fait le succès d’Apple. Même s’il ne se désignait pas lui-même comme Product Owner, cela montre l’importance du rôle.

Il est vraiment dommage que ce poste soit si souvent négligé.