Dans le cadre de la méthode Agile, le Product Owner (Chef de projet digital) est la personne chargée d’optimiser la valeur d’un projet. Le Product Owner doit avoir une vision extrêmement claire afin de guider la conception d’un produit, mobiliser les parties prenantes, tirer parti des opportunités offertes par les nouvelles technologies, prendre en compte les retours d’expérience – du marché et des clients – ou encore concevoir de nouvelles fonctionnalités pour cibler de nouveaux publics. Dans une configuration idéale, il agit comme un véritable chef d’entreprise, avec la responsabilité de devoir prendre des décisions parfois difficiles. Cependant, la pratique révèle que les entreprises ne laissent pas toujours la liberté d’action suffisante aux Products Owners pour la bonne réalisation de leur travail
C’est pourquoi il est important de comprendre les freins, relatifs à différents contextes organisationnels, afin de faciliter le travail des Product Owners et de garantir une transition réussie vers davantage d’agilité.
Les 5 erreurs à éviter
1. La lourdeur hiérarchique
Certaines entreprises ont un fonctionnement très cloisonné. Les directions commerciale et informatique ne communiquent pas et ne collaborent pas efficacement. La transition vers un nouveau modèle économique et/ou une méthode Agile a pu être imposée, mais a finalement déçu toutes les parties prenantes. Plutôt que de constituer de véritables référents, les Product Owners courent alors le risque de devenir des intermédiaires de plus : un nouvel échelon entre équipes et directions opérationnelles, embourbés eux aussi dans des procédures et des tâches administratives.
Dans ces conditions, il convient de faciliter et d’améliorer la communication entre les collaborateurs, de façon à favoriser le partage en termes de responsabilités et de métiers. Les Product Owners ont besoin de bénéficier d’un mandat clair pour agir de façon indépendante et surmonter les obstacles organisationnels. Ils peuvent résoudre l’écueil de la lourdeur hiérarchique en s’alliant à un Scrum Master. Leur collaboration permettra au Product Owner de procéder, dans un premier temps, à un certain nombre de changements à son niveau et ainsi d’acquérir l’autorité nécessaire pour prendre, dans un second temps, des décisions plus importantes et faire reconnaître les bénéfices de la méthode Agile.
2. Une impasse
Imaginons une entreprise qui soit dans une situation économique délicate : un chiffre d’affaires faible, une concurrence exacerbée, des discussions internes sans fin et sans l’ombre d’un consensus sur les solutions à mettre en œuvre. Les ressources qui devraient être mises en commun sont au contraire éparpillées, avec comme conséquence une vraie difficulté pour l’entreprise à atteindre ses objectifs opérationnels.
Un Product Owner entrepreneur peut optimiser le processus de remontée d’informations du marché et des prospects en développant, par exemple, un MVP (Produit Minimum Viable) pour solliciter l’avis des publics cibles. Le MVP permet d’intégrer les retours du marché dans le développement d’un nouveau produit. Le Product Owner devient ainsi l’ambassadeur privilégié chargé d’impliquer l’ensemble des parties prenantes.
3. La paralysie du modèle opérationnel
Une entreprise bénéficie de retours émanant de l’interne et du marché sur un projet, mais ne parvient cependant pas à tirer profit de ces éléments; pour remettre en question, par exemple, son modèle économique ou changer d’approche. Les intérêts personnels, les contrats à long terme et, plus généralement, la peur du changement peuvent empêcher la remise en cause d’un modèle de développement jadis fructueux, mais aujourd’hui en déliquescence .
Un Product Owner doit apporter son pouvoir disruptif: tester des hypothèses, révéler les points faibles de l’activité de l’entreprise, remettre en cause la valeur ajoutée du travail des équipes. Casser l’immobilisme organisationnel suppose que le Product Owner travaille avec différentes parties prenantes, à l’intérieur et à l’extérieur de l’entreprise, et qu’il fasse preuve d’une volonté forte de tester et d’évaluer différents modèles économiques (études de marché, publication d’un MVP…).
4. L’inexpérience
Prenons le cas d’une entreprise relativement novice en matière de méthode Agile : elle doit tout d’abord convaincre chacun de ses collaborateurs du bien-fondé de cette démarche. Certains considéreront, par exemple, que l’agilité est avant tout une problématique informatique, liée à la nécessité de mises à jour fréquentes et à l’impératif de flexibilité afin de satisfaire les clients. On pourrait en effet penser que l’agilité ne concerne pas tout le monde et que la plupart des directions peuvent continuer à appliquer les mêmes méthodes éprouvées sans que cela n’ait de conséquence sur leur activité.
En réalité, la méthode Agile concerne toute l’entreprise et non une seule direction. Les Product Owners doivent surmonter les barrières entre directions opérationnelles et domaines d’expertise afin d’associer intimement l’activité économique et l’informatique. Il s’agit d’harmoniser les stratégies de la gestion de projet et de la gestion de programmes, grâce au mode de pensée agile et en donnant la priorité aux produits. De cette façon, on mobilise à la fois les responsables projets et les responsables produits afin qu’aucun ne se sente exclus de la démarche.
5. Cupidité et intérêts personnels
Certains Product Owners peuvent se montrer impitoyables dans la poursuite de leurs intérêts personnels et agir selon l’adage « la cupidité est une bonne chose ». Ils nuisent alors à la création de valeur et fragilisent l’entreprise La transition de l’entreprise vers l’agilité peut elle-même en être affectée.
Être un véritable entrepreneur signifie répondre à l’environnement extérieur en lui étant ouvert. Poursuivre des intérêts personnels contraires à l’intérêt de l’entreprise s’apparente, en revanche, à du pillage.
Conclusion : les meilleures pratiques
S’engager sur la voie de l’agilité eut être difficile. Voici une sélection de bonnes pratiques pour aider les entreprises dans cette transition vers plus d’efficacité et de rentabilité :
- Recruter de bons profils: si la transition vers la méthodologie/méthode Agile n’est pas soigneusement pensée, les collaborateurs occupant un nouveau poste comme celui de Product Owner peuvent ne pas avoir le profil et les qualités requis.
- Embaucher un Product Owner extérieur : les entreprises qui se reconnaissent dans les scénarios 1 (« La lourdeur hiérarchique ») et 4 (« L’inexpérience ») peuvent être tentées par le recrutement d’un Product Owner extérieur. Celui-ci, tel un arbitre indépendant, facilitera le processus de transition en créant un consensus interne et en accompagnant les autres Product Owners de l’entreprise.
- Avoir une vision claire des produits à développer et s’attacher à tester leur viabilité, au moyen notamment d’un MVP
- Former des équipes pluridisciplinaires, flexibles, créatives et très performantes pour faire la différence.
- Identifier les parties prenantes décisionnaires et les impliquer dans un dialogue constructif De cette façon, la sphère d’influence des Product Owners s’élargira.
- Co-créer les éléments du product backlog (carnet du produit) et les objectifs du projet en faisant intervenir tous les niveaux de l’entreprise.
- Favoriser et animer la collaboration entre les équipes Scrum et les parties prenantes internes et externes.
- Echouer plusieurs fois: accepter le fait que délivrer tôt et souvent est la voie de la réussite, même si cela peut parfois être douloureux.
