Le Product Owner vu par les développeurs

Introduction

L’Agilité est un sujet souvent abordé très positivement. Il n’est pas rare, cependant, d’entendre des développeurs entre eux se plaindre de son implémentation, qui, bien appliquée peut être une véritable force pour une équipe de développement. Le product owner, avec son rôle central, est souvent à l’origine de frustrations de l’équipe de développement. Au travers de témoignages recueillis auprès de développeurs, nous mettrons en lumière les raisons de cette divergence de points de vue sur l’Agile et sur le rôle du product owner.

Dans un premier temps le rôle du Product Owner sera présenté dans les grandes lignes afin de mieux le situer dans l’équipe Agile. Puis il sera abordé l’opinion des développeurs sur l’implémentation de l’Agilité et le rôle que le Product Owner a dans cette organisation. Ensuite, seront évoquées les erreurs à éviter et les signaux indiquant un mauvais rapport produit – Product Owner. Enfin, cet article présentera rapidement les aspects positifs du rôle de Product Owner pour une équipe de développement que les développeurs interrogés souhaitaient souligner.

Le but de cet article est double :

• Sensibiliser un jeune Product Owner à ces erreurs et lui donner des clés afin de ne pas les commettre.
• Permettre à un Product Owner travaillant déjà avec des développeurs de mieux comprendre le ressenti de certains d’entre eux et d’initier une conversation avec son équipe pour voir si ces ressentis sont partagés ou non dans le but de s’améliorer.

1.      Le rôle du Product Owner

Au sein d’une équipe Scrum, le Product Owner est chargé de recueillir le besoin auprès du métier pour lequel le produit est développé. Il formalise ce besoin et le priorise dans le Product Backlog afin d’alimenter l’équipe de développement en tâches à réaliser lors des sprints.

Le Product Owner a aussi d’autres tâches, il anime notamment certaines cérémonies telles que les Sprint Plannings. Il est aussi le porteur de la vision du produit.

Product Owner est donc un rôle clé quand il s’agit de donner une direction au produit. Par conséquent, il va être amené à échanger très régulièrement avec l’équipe de développement.

2.      L’Agilité selon les développeurs

2.1.  Les multiples facettes de l’Agile

Beaucoup réduisent l’Agilité à la méthode Scrum, or, d’autres méthodes existent avec des modes d’application différents :

« Il faut voir l’Agilité comme une façon de percevoir l’animation et l’organisation autour d’un produit. »

G.E. – Développeur, 8 ans d’expérience

A titre d’exemple, le fameux sprint n’existe pas avec la méthode Kanban[i], il convient donc de choisir une méthode adaptée au profil de chaque équipe de développement ainsi qu’au produit développé.

« Je pense que la méthodologie Agile n’est pas une méthodologie, mais plutôt un courant de pensée/façon de percevoir l’animation et l’organisation autour d’un produit. »

G.E. – Développeur, 8 ans d’expérience

2.2.  Adapter le cadre de travail en fonction de l’équipe de développement

Chaque équipe est différente. Une équipe de développeurs aguerris n’aura pas nécessairement les mêmes besoins organisationnels qu’une équipe avec une expérience mixte ou complètement junior[ii]. L’application d’une méthode agile devrait se faire de manière naturelle en collaboration avec l’équipe de développement. Si ce n’est pas le cas, certains développeurs perçoivent cette application forcée comme un moyen de surveillance contre-productif. Certains développeurs remontent notamment un recours démesuré à la justification de « l’avancement » au travers de réunions qui donnent lieu à des échanges à faible valeur ajoutée pour eux, ce qui résulte une perte de productivité.

« L’Agilité doit bourgeonner par le bas et non être parachutée par le haut. »

A.S. – Développeuse, 4 ans d’expérience

Les développeurs interrogés semblaient tous hostiles à l’instauration forcée d’une durée de sprint commune à toutes les équipes d’un plateau. Notamment dans le but d’effectuer les sprint reviews le même jour pour tous. Bien que pratique d’un point de vue organisationnel, chaque équipe travaille souvent sur des produits très différents et cette journée est perçue comme une perte de temps par certains. 

En réalité, il est difficile de faire bourgeonner l’Agilité par le bas sans avoir de soutien hiérarchique. Si les développeurs semblent ne pas comprendre l’intérêt d’une cérémonie il peut être utile de faire intervenir le Scrum Master. Ce dernier pourra expliquer les raisons de telle ou telle cérémonie.

2.3.  L’Agile par les développeurs, pour les développeurs ?

Selon certains développeurs interrogés, l’une des raisons pour lesquelles l’application de l’Agile peut poser problème dans certaines équipes est le manque de connaissances en développement des personnes qui animent et mettent en place ce cadre de travail.

Dans les témoignages reçus, la différence entre un Scrum master ou Product Owner qui a été développeur (et avec un background en informatique) et un autre non se fait ressentir. Le travail semble beaucoup plus mis en valeur et respecté par le premier que par le second. Les contraintes de temps, les explications et l’accompagnement paraissent aussi bien meilleurs du fait d’une expérience de développeur.

« Un Product Owner technique est moins sceptique, mais aussi plus exigeant et selon moi tire le produit vers le haut. »

A.S. – Développeuse, 4 ans d’expérience

Malgré tout, même sans expérience en développement, il est possible d’être un bon atout dans une équipe Agile[iii]. Il est conseillé de faire preuve de curiosité. Le Product Owner ne doit pas hésiter à demander des précisions sur le fonctionnement technique du produit. De nombreuses ressources existent en ligne pour permettre à un consultant de comprendre la logique derrière un code. Ces connaissances peuvent faire la différence lorsqu’il s’agit de prendre des décisions sur un produit en développement.

« Le Product Owner ne doit pas avoir peur de mettre les mains dans le cambouis quand c’est urgent. Faire une requête SQL, donner un coup de main lors des tests. »

L.M. – Développeur, 2 ans d’expérience

3.      Les erreurs que le Product Owner doit éviter de commettre

3.1. Les erreurs à éviter selon les développeurs

Si en tant que Product Owner il vous semble difficile de briser la glace avec l’équipe de développement, peut-être que commettez-vous l’une des erreurs ci-dessous.

a.       Vision du produit :

• Rédaction de User Stories incomplètes. Dans une User Story, les développeurs ne peuvent pas se contenter d’une capture d’écran d’une maquette d’une page à développer. Un bon Product Owner doit veiller à bien décrire le fonctionnement souhaité et détailler les règles qui permettent d’articuler la page.
• Manque d’intérêt pour le produit. Pour maximiser la valeur d’un produit, il est préférable d’avoir un réel intérêt dans ce dernier.
• Peu d’interaction avec les développeurs dans le but d’améliorer le produit. Les développeurs sont souvent de bonnes sources de suggestions sur l’amélioration du produit puisqu’ils le voient sous un autre angle et ceci permet d’avoir une vision plus large des possibilités du produit. Il faut leur laisser du temps pour les tâches techniques. Ceci permettra, sur le long terme de garder un produit facilement évolutif. Ces tâches peuvent être : de la refactorisation de code, des mises à jour de librairies ou d’environnements…
• Incapacité à « mettre les mains dans le cambouis », pour des tests, l’exécution d’une requête SQL ou encore l’analyse d’une réponse API. Le Product Owner a tout intérêt à être capable (ou au moins curieux) de fouiller le produit afin de mieux se l’approprier et d’analyser/d’anticiper d’éventuels bugs.
• Ne pas connaître les avantages et inconvénients de son produit. Lorsqu’il s’agira de décider de l’orientation du produit, le Product Owner doit être au clair sur les forces et faiblesses de son produit. Il cherchera alors à y pallier ou lui fera pas prendre une direction qui accentuerait ses faiblesses.
• Ne pas réfléchir aux conséquences d’un besoin donné sur le produit à moyen terme. Comment une fonctionnalité B peut impacter une fonctionnalité A déjà développée qui rendrait celle-ci obsolète.

b.       Lien avec l’équipe de développement :

• Ne pas demander aux développeurs leur expertise lors du découpage des User Stories en tâches. Au final, une User Story est destinée à un développeur, il est donc important de s’appuyer sur eux pour le découpage.
• Ne pas transmettre une expression du besoin claire, plus particulièrement dans les situations où le développeur doit développer des prototypes d’un produit et qu’il n’y a pas de designer. Une expression du besoin qui manque de clarté va forcément avoir un impact négatif sur l’efficacité de l’équipe.
• Ne pas donner de priorité claire aux tickets. Le développeur n’aura pas nécessairement le temps d’avoir une vision claire des priorités si elle n’est pas indiquée dans les User Stories, il est donc important d’indiquer ces priorités dans le backlog.
• Ne pas avoir confiance en les estimations des développeurs. Les équipes de développement sont en charge de faire des estimations en suivant différentes méthodes (poker planning, taille de t-shirt…). Lors de l’estimation, l’équipe se met d’accord. Remettre en cause cette estimation, en tant que Product Owner n’enverrait pas un bon signal à l’équipe de développement. Si les estimations vous semblent inadaptées, il convient de poser des questions pour comprendre pourquoi plutôt que de les rejeter.
• Trop solliciter l’équipe de développement sur l’avancement des développements. Il vaut mieux utiliser les outils en place pour suivre le traitement des User Stories (Jira, Trello…).
• Ne pas protéger les développeurs d’une ambiance anxiogène. Afin de développer de manière fiable et efficace, il est préférable que les développeurs soient protégés de toute pression qui pourrait avoir pour conséquence un travail fait trop rapidement et peu fiable.

c.       Lien avec les autres équipes :

• Laisser les personnes (développeurs ou non) extérieures à l’équipe Agile estimer à la place des développeurs dans l’équipe de développement. Il est très difficile d’estimer la complexité et la taille d’une User Story sans savoir comment est construit le code, il est donc important que les développeurs qui réalisent l’estimation soient familiers avec la structure du produit.
• Laisser des membres de l’entreprise « bypasser » le process d’entrée dans le backlog et de priorisation. Il peut être difficile de refuser au PDG de son entreprise de faire des demandes « express » aux développeurs. Il est cependant important de lui faire prendre conscience que les demandes « express » n’existent pas. En effet, chaque fonctionnalité développée entre dans un cycle de vérification et validation par les développeurs. Pour respecter la charge de travail, en fonction de la méthode choisie, il est important que le Product Owner soit autant que possible le seul point d’entrée et de priorisation.
• Trop peu d’interaction directe avec le métier pour transmettre des retours positifs ou négatifs aux développeurs. Ces retours leur permettront de se situer dans l’attendu et dans la qualité de leurs livraisons.
• Empêcher les rencontres entre développeurs et métier. Certaines équipes de développement sont très éloignées du métier. Par conséquent, les développeurs ne peuvent pas présenter leur travail aux futurs utilisateurs. Ceci baissera souvent l’engagement des développeurs dans la réussite du produit.

4.      Les aspects positifs d’un Product Owner pour une équipe de développement

Les développeurs interrogés ont tout de même souligné l’importance d’un Product Owner dans un projet. Ils tenaient à partager ces points qui font du Product Owner un atout de taille dans le développement d’un produit.

• Le Product Owner est le meilleur allié du développeur. Sa présence permet aux développeurs de développer de nouvelles fonctionnalités en se basant sur des instructions précises. Le Product Owner pourra répondre aux questions des développeurs ou saura où trouver les éléments de réponses.
• Le Product Owner sert aussi de « bouclier » face à des demandes métier qui peuvent parfois manquer de structures. Ceci permet aux développeurs de se concentrer pleinement sur leurs tâches dans un environnement le plus stable possible.
• Le Product Owner est source de motivation pour les développeurs, plus particulièrement si le Product Owner aime son produit. C’est lui qui aura la vision et les échanges avec le Product Owner aideront les développeurs à trouver leur place dans l’équipe de développement et à s’approprier le produit.

Le rôle de Product Owner est clé dans le développement d’un produit. Il est bénéfique de chercher à avoir les meilleurs rapports possibles avec l’équipe de développement. Scrum, par exemple, ne reconnait pas de hiérarchie entre le Product Owner et l’équipe de développement. Ils forment une seule équipe avec pour but commun la réussite de leur produit.

En fonction du produit développé et de l’équipe de développement, le rôle de Product Owner peut parfois paraître compliqué. Bien que les développeurs interrogés semblent préférer un Product Owner technique, il est tout à fait possible selon eux d’être bon dans ce rôle sans être technique. Le Product Owner doit savoir faire preuve de curiosité sur la manière dont fonctionne son produit dans les coulisses.

Si la relation entre le Product Owner et l’équipe de développement ne semble pas fonctionner, cet article peut être une bonne base pour analyser et repérer les points bloquants. Le but étant d’enclencher une réflexion et un échange avec les équipes pour mettre en place des actions d’amélioration.

Chez HeadMind Partners, il nous tient à cœur d’avoir des consultants qui travaillent main dans la main avec des développeurs pour nos clients. Dans ce sens, nous proposons des formations et certifications à nos consultants pour les préparer au rôle de Product Owner.

Article écrit par Mehdi Abdellaoui, Associate Consultant HeadMind Partners, membre du Lab Agilité.

Sources

Cet article est basé sur des échanges avec cinq développeurs travaillant dans différents domaines (retail, gouvernement, transport). Ils ont une expérience professionnelle comprise entre 2 ans et 8 ans.

[i] Différences entre Scrum, Kanban et Scrumban (anglais) : https://medium.com/agileinsider/comparison-of-scrum-vs-scrumban-vs-kanban-1d1d2b9a9fd5

[ii] Scrum, Kanban, Scrumban : quelle méthode Agile choisir ? :  https://www.blogdumoderateur.com/scrum-kanban-scrumban-methode/

[iii] Comment devenir Product Owner : https://www.leproductowner.com/carriere/comment-devenir-product-owner