Il y a peu, je vous présentais mes constations après avoir suivi (à nouveau) la formation de Professional Scrum Product Owner. Comme je l’écrivais, le rôle du Product Owner est celui qui reste le plus flou dans le guide Scrum, car il est très dépendant de l’entreprise dans laquelle celui-ci évolue. On peut y lire : « La façon de jouer ce rôle peut varier grandement selon les organisations, les équipes Scrum et les individus. »

Cependant, le rôle du Product Owner est capital et obligatoire pour réussir l’implémentation du cadre Scrum. Le Product Owner est celui qui insuffle la vision, donne la direction et modifie le cap au besoin. C’est un rôle complexe et les personnes amenées à l’occuper doivent être formées et accompagnées.

Le PO, de son petit nom, croit en son produit et est le mieux placé pour définir ce qui a de la valeur et ce qui est prioritaire. Évidemment, un Product Owner avisé s’appuiera sur les connaissances des clients, des parties prenantes et des membres de l’équipe, mais c’est lui qui aura le dernier mot sur la priorisation de son carnet de produit (Product Backlog).

Pas de Product Owner

Disons en préambule que lorsqu’il n’y a pas de Product Owner dans une équipe Scrum… alors il ne s’agit pas d’une équipe Scrum! Dans une telle situation, l’équipe de développement essaie de faire au mieux selon ses capacités. Cela engendre parfois des transformations dans l’équipe.

  • Le développeur remplaçant

Il arrive souvent qu’un membre de l’équipe de développement s’improvise Product Owner. En principe, il s’agit du développeur ayant la connaissance fonctionnelle la plus poussée. Il joue ce rôle tant bien que mal, mais il navigue à vue et est rarement certain de ses choix.

Le plus important problème que l’on constate est la légitimité du développeur auprès des parties prenantes et également de ses collègues développeurs. Même s’il n’y a pas de relation hiérarchique entre le Product Owner et l’équipe de développement, la définition du rôle de PO indique clairement qu’il a le dernier mot en ce qui concerne la priorisation. Qu’en est-il lorsqu’il s’agit d’un développeur faisant preuve de bonne volonté, mais n’ayant pas été intronisé?

Un Product Owner va accéder aux études de marché, pourra comparer ce que fait la concurrence et récolter le feedback de ses collègues et clients. Comment pensez-vous que ces personnes vont réagir si un inconnu vient leur poser des questions? Comment un développeur peut-il insuffler à l’équipe une vision du produit?

De plus, par expérience, un PO/développeur privilégie sa casquette de développeur lorsqu’il y a des retards ou du stress pour livrer des fonctionnalités. Délaissant ainsi son rôle de PO, toute l’équipe s’en trouve fortement impactée.

  • Le manager remplaçant

Parfois, un supérieur hiérarchique prend le rôle de Product Owner. Même si cela peut être fait en toute bonne foi pour essayer d’aider l’équipe de développement à avancer du mieux possible, la relation hiérarchique va entrer en conflit avec l’auto-organisation de l’équipe. Le dialogue sera faussé et l’équipe pourra avoir des difficultés à se défendre notamment sur le contenu des sprints. Les rétrospectives peuvent également avoir une teinte différente avec un manager dans la salle.

  • Pas de PO du tout

Lorsque personne ne prend le rôle de Product Owner, cela peut même virer au chaos total. Chacun des membres de l’équipe aura son avis sur la fonctionnalité qui doit être développée prioritairement, la vision sera clairement inexistante et la cohésion risque d’être difficilement atteinte. Les développeurs étant naturellement plus orientés sur l’aspect technique, les choix de développement et la priorisation risquent d’être plus orientés dans ce sens que vers le fonctionnel.

Sans Product Owner attitré, nous constatons que l’équipe s’essouffle au bout de quelques semaines en n’ayant pas de direction claire et en ayant le sentiment de ne pas fournir le maximum de valeur possible, tout en étant peu reconnue. Si l’entreprise décide de ne pas dégager du temps pour que quelqu’un d’approprié puisse tenir le rôle de Product Owner, cela signifie-t-il que la solution qui est développée n’est finalement pas si prioritaire que ça? C’est en tout cas l’impression que pourrait avoir l’équipe. L’essoufflement viendra aussi de la perte de temps ainsi engendrée. Chaque validation et chaque choix demandent plus de temps, de discussion voire de négociation.

Un Product Owner et une demi-équipe

Dans certaines compagnies, un PO est bel et bien affecté à un produit, mais l’équipe de produit n’est pas fixe et doit s’occuper de nombreux autres projets/maintenance. Des problèmes récurrents sont alors rencontrés.

La priorisation n’est pas effectuée par une seule personne, il y a d’un côté un flux géré par un PO et de l’autre, des demandes informatiques, de la maintenance, etc. Qui est en mesure de prioriser entre la demande X et la demande Y? Le développeur se retrouve bien souvent à faire l’arbitrage par lui-même, sans savoir vraiment si c’est bien la stratégie de l’entreprise. Dans cette situation, est-il possible de s’assurer que ce qui a le plus de valeur est bien en train d’être développé?

Avec la meilleure volonté du monde, les objectifs de sprint du Product Owner sont rarement atteints car il est difficile de savoir en début de sprint combien de temps l’équipe aura vraiment à disposition pour le produit. La partie négociation avec le Product Owner qui devrait avoir lieu dans le cadre de tout projet Scrum est ici biaisée, car il lui est impossible d’avoir un avis sur des produits qui ne le concerne pas.

Enfin, ne parlons pas de la perte de temps liée au manque de concentration et au task switching

Un Product Owner passe-plats et une équipe

Le Product Owner que j’appelle « passe-plats » est souvent une personne qui a été parachutée dans ce poste, mais qui n’a pas la connaissance nécessaire ou le « pouvoir » pour remplir ce rôle.

Par exemple, il pourrait s’agir d’une personne qui a de vagues connaissances sur le produit et qui vient d’arriver dans l’entreprise. Dans cette situation, un effet passe-plat va se produire car le Product Owner ne pourra jamais répondre formellement à une question et devra toujours demander une validation ailleurs. Les réponses seront généralement du type : « Oui, je crois que c’est ça, mais attendez, je vais faire valider auprès de X ou Y. »

Cette situation peut être acceptable si on sait que le Product Owner est présent à long terme, qu’il est en train de monter en compétence et en connaissances. Au fur et à mesure, il devrait pouvoir s’affirmer de plus en plus et acquérir les connaissances nécessaires. À l’inverse, s’il s’agit d’une personne qui n’est pas investie, qui ne dispose pas du temps nécessaire pour monter en compétence, qui occupe le rôle de manière transitoire à court terme, cela générera, comme dans les autres situations, des lenteurs, de la frustration et peut-être aussi un incrément qui a peu de valeur à la fin de chaque sprint.

Deux Product Owners

N’oublions pas que le travail du Product Owner est complexe, exigeant et lui demande bien souvent 100% de son temps. C’est pourquoi il peut être tentant de définir deux Product Owners plutôt qu’un seul pour un même produit afin de répartir la charge de travail. Je vais immédiatement casser le suspense : ce n’est pas une bonne idée! Et ce n’est pas Scrum…

À nouveau, dans un contexte pareil, nous faisons face à des problèmes de priorisation et de vision. Le Product Owner A va prioriser d’une certaine manière et le Product Owner B d’une autre : qui a raison? Qui faut-il écouter? Même si l’équipe doit être ouverte au changement, la perte de temps engendrée par les revirements et les changements de décisions ne sont bénéfiques à personne.

En parallèle, une question peut parfois se poser lorsque deux Product Owners sont assignés au même produit, mais en se répartissant les domaines : ne s’agit-il pas par hasard de deux produits différents? Si c’est le cas, il pourrait être bon d’avoir une équipe dédiée pour chacun des produits.

Par contre, un Product Owner peut très bien être aidé par des personnes, par exemple des analystes d’affaires. Il ne s’agit pas d’une équipe de Product Owners, le Product Owner est toujours responsable du carnet et de sa priorisation. Un analyste peut par exemple aider pour rédiger les scénarios utilisateurs (user stories) et recueillir le besoin auprès de ceux-ci. Dans ce cas, il faut faire attention à ce que le Product Owner ne remette pas systématiquement en cause des informations transmises par l’analyste.

Le match parfait : un Product Owner et une équipe de produit dédiée

A-t-on besoin d’expliciter encore? Ce n’est qu’en ayant des membres avec des rôles clairs qu’une équipe Scrum peut être vraiment efficace. Par rôle clair, nous entendons :

  • Un Product Owner engagé, visionnaire et au clair avec ses priorités. Il peut être aidé par d’autres personnes dans la définition et l’écriture des scénarios utilisateurs pour autant qu’il soit toujours maître de son produit et suffisamment impliqué au sein de l’équipe
  • Un Scrum Master
  • Une équipe de développement pluridisciplinaire

Ces conditions sont un bon début pour pouvoir déclarer : « Nous utilisons Scrum » mais encore faut-il que l’équipe Scrum soit organisée autour d’un produit…

Billet précédent

Comment l’auto-organisation se produit … et pourquoi y croire

Billet suivant

Professional Scrum Master II

Sabrina Ferlisi

En 2014, après un master d’ingénieur en informatique et des années dans le développement logiciel et la gestion de projet, Sabrina tombe dans la marmite de l’Agilité en tant que Scrum Master et découvre un nouveau monde. Depuis, elle est passionnée par tout ce qui touche aux interactions humaines, à la communication et à l’amélioration continue.

Énergique, intuitive et organisée, elle met son savoir-faire au service des équipes et des organisations en donnant à la fois un cadre et de la souplesse aux environnements complexes.

1 Commentaire

  1. taniagobeil@gmail.com'
    Tania Gobeil
    06/02/2019 at 12:38 — Répondre

    Je trouve votre analyse fort intéressante et elle résonne avec beaucoup d’expériences réelles que j’ai vécues! Il y a un scénario qui me perplexe encore par contre, c’est celui où il y a plusieurs équipes scrum pour le même produit, avec un seul product owner. Dans ce cas, avoir un PO impliqué avec toutes les équipes au niveau reccomandé est pratiquement impossible. C’est à ce moment là qu’on se retrouve avec des PO “passe plats” qui doivent se référer au vrai PO, avec tous les désavantages que vous présentez ci-haut. Je suis curieuse de savoir si vous auriez une meilleure solution à proposer pour ce scénario? Merci!

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.