Les différents rôles d’une équipe produit sous Scrum

L’agilité est une approche itérative du développement de produits digitaux qui permet de commencer par la réalisation d’un Minimum Viable Product (MVP) pour ensuite l’améliorer de manière incrémentale.

Aujourd’hui, la méthodologie Scrum est la méthode agile la plus utilisée en entreprise (⅔ des praticiens de l’agile) et se base sur une équipe produit qui collabore pour avancer ensemble. Ainsi, au cours de chaque cycle, l’équipe planifie, design, teste, développe et valide de nouvelles fonctionnalités qu’elle peut mettre en ligne à la fin de chaque sprint.

Schématisation de la méthodologie Scrum

Quels rôles se cachent derrière une équipe produit ?

Le Guide Scrum définit une équipe Scrum comme une équipe auto-organisée, pluridisciplinaire, et constituée de 3 rôles principaux au même niveau hiérarchique :

• le Product Owner
• le Scrum Master
• et l’équipe de réalisation

Les 3 rôles principaux d’une équipe produit sous méthodologie Scrum

Le Product Owner

Le Product Owner - aka PO - est le garant du produit. C’est lui qui recueille les besoins utilisateurs, qui les traduit et qui porte la vision du produit final.

Ainsi, le Product Owner est très proche des utilisateurs finaux, dont il doit comprendre les besoins pour ensuite les traduire en termes de fonctionnalités via la rédaction de User Stories.

Une fois le besoin clarifié - et s’il a la chance d’avoir à disposition une équipe UX/UI - il peut être amené à échanger avec le Product designer qui va s’occuper de la production du parcours utilisateur et du maquettage.

Les maquettes en mains, le Product Owner peut enfin commencer à rédiger ses User Stories et les présenter à son équipe de développeurs lors d’un grooming. Cette réunion d’affinage permet au Product Owner de sensibiliser son équipe technique sur le besoin utilisateur, d’échanger de façon exhaustive sur des fonctionnalités futures à développer et d’anticiper de potentielles alertes techniques.

A la suite de ces échanges, il peut être amené à découper des User Stories trop lourdes pour être traitées en une seule itération et de finir des les préparer pour qu'elles soient embarquées dans les prochains sprints.

L’écosystème autour du Product Owner

Au sein de l’équipe produit, le Product Owner a donc pour mission de porter la vision du produit et de la cadrer via sa roadmap. Au quotidien, il alimente son backlog en User Stories qu’il doit ensuite prioriser. La priorisation est un travail indispensable qui permet au Product Owner de savoir quoi engager sur les sprints à venir et d’optimiser le temps de son équipe technique en délivrant un maximum de valeur à l’utilisateur final à l’issue de chaque sprint.

En plus d’une communication régulière avec les rôles précédemment énoncés, le Product Owner échange également avec les équipes de recette - aussi appelées QA pour Quality Analyst ou encore testeurs. Créateur des cas de test via la rédaction de critères d’acceptance, il est donc fréquemment en contact avec les recetteurs afin de garantir la livraison d’un incrément produit de qualité.

L’équipe produit attend du Product Owner une organisation sans faille à la fois pour planifier les futurs développements mais aussi pour suivre les développements en cours. La communication et la transparence sont donc les qualités phares attendues par l’équipe de la part d’un Product Owner performant.

Il a donc un rôle particulièrement important, puisqu’il est le maillon central de l’équipe autour duquel tournent toutes les autres parties prenantes du produit.

Toutefois, bien qu’il donne la direction à suivre à l’équipe sur les évolutions à apporter au produit, le Product Owner n’a pas de pouvoir hiérarchique sur le Scrum Master ou encore sur l’équipe de réalisation.

Le Scrum Master

Le Scrum Master a pour rôle de veiller à l’application et au respect des valeurs et pratiques Scrum tout en veillant à lever les obstacles à la productivité de l’équipe.

Les différents rôles du Scrum Master

Il a pour mission d’aider l’équipe à travailler dans les meilleures conditions possibles. Il doit donc la protéger de toutes les perturbations pouvant provenir de l’extérieur mais également faciliter la communication en interne ainsi que le dialogue avec le Product Owner.

C’est également lui qui veille à ce que les différentes cérémonies agiles (daily meeting, grooming, sprint planning, rétrospective...) aient bien lieu et qui s’assure de la bonne compréhension de ces dernières par tous les membres de l'équipe. On peut donc voir le rôle de Scrum Master comme un facilitateur au sein d’une équipe produit.

L’équipe de réalisation

L’équipe de réalisation est une équipe pluridisciplinaire qui travaille de façon incrémentale pour livrer une partie du produit final utilisable et testable à la fin de chaque sprint ou itération.

Elle est idéalement composée de 3 à 8 personnes réunissant :

• majoritairement des développeurs responsables de la réalisation technique des User Stories et des arbitrages techniques à prendre,
• d’un Product Designer qui réfléchit à la conception du produit à l’aide de sa user research
• d’un Quality Analyst (recetteur / testeur) dont le rôle est de tester chaque ticket et de valider leur bon fonctionnement

Les développeurs au sein de l’équipe de réalisation

A partir d’une User Story, les développeurs vont créer des tâches pour préparer en amont le bon développement de cette dernière. Cette phase d’analyse permet aux développeurs de chiffrer / scorer les US (via des techniques comme le poker planning, les tailles de t-shirts…) et d’aider l’équipe à se projeter vis à vis de sa vélocité et à s'aligner sur le travail à accomplir.

Une fois les tickets embarqués dans le sprint, l’équipe technique s’auto-organise sur la répartition des tâches entre chaque développeur et suivant les compétences techniques de chacun (développeur front / back / fullstack).

Chaque membre de l’équipe de développement est donc en charge de plusieurs tâches tout en étant garant de la bonne réalisation et de la qualité de ce qu’il livre. En effet, une fois les règles de gestion développées, l’équipe technique passe en revue les critères d’acceptance afin de vérifier l’attendu fonctionnel et réalise des tests unitaires poussés pour livrer un code de qualité avec le moins de dette technique possible.

Une fois la User Story développée, elle peut ensuite passer dans les mains du Quality Analyst qui va s’assurer de la bonne conformité fonctionnelle des tickets suivant différents cas de tests. En cas d’anomalies détectées, les développeurs ont pour mission de les analyser et d’apporter les corrections et / ou évolutions nécessaires.

Enfin, en plus du développement technique des User Stories, les développeurs doivent également documenter leur code (afin de permettre à n’importe quel nouveau développeur de l’équipe de reprendre le code aisément) et de produire de la documentation technique. Cette étape est essentielle pour assurer la maintenabilité du produit et limiter les risques en cas de turnover.

Le Product Designer au sein de l’équipe de réalisation

Le Product Designer est très proche des utilisateurs finaux. C’est lui qui va à leur rencontre, qui mène la recherche utilisateur et qui conçoit le parcours le plus ergonomique possible. La proximité qu’il entretient avec les utilisateurs lui permet de récolter un maximum de feedbacks et d’améliorer sa proposition de façon continue.

Sa double casquette UX/UI lui permet à la fois de répondre aux problématiques ergonomiques du produit à travers la proposition d’un parcours sans couture, mais aussi de répondre aux problématiques d’interfaces à travers la mise en place d’éléments graphiques permettant de guider l’utilisateur sur le produit.

Le Product Designer échange donc régulièrement avec le Product Owner une fois le besoin clarifié mais il n’est pas rare que certains développeurs, notamment les développeurs front, se tournent vers lui pour valider ensemble le comportement attendu de certains composants graphiques.

L’équipe de recette au sein de l’équipe de réalisation

Les testeurs sont les derniers maillons de la chaîne avant de pouvoir livrer l’incrément produit d’un sprint en production. C’est eux qui testent toutes les fonctionnalités développées lors d’un sprint et qui les valident ou les invalident. Les testeurs réalisent leurs cas de test via les critères d’acceptance rédigés par le Product Owner et peuvent parfois échanger avec ce dernier s’ils ont des doutes sur des tests à réaliser.

Si un test réalisé n’est pas conforme aux spécifications de la User Story, le testeur créé une anomalie qu’il assigne au développeur responsable. Cela permet au développeur de vérifier son code et d’y apporter les corrections nécessaires.

Une fois tous les tickets du sprint passés en revue, les testeurs lancent des tests de non régression - ou TNR - afin de vérifier que l’incrément produit en cours n’ait pas engendré d’effets de bord pouvant dégrader le produit par rapport à la version précédente. Ces TNR sont souvent automatisés afin de limiter le temps de traitement de chaque version.

La validation des tests est parfois documentée par la remise d’un Procès Verbal de recette - ou PV de recette - document validant la livraison du produit et autorisant l’équipe technique à pousser l’incrément produit en production.

La livraison en production réalisée, l’équipe de recette peut ensuite passer un tour de clé pour vérifier que tout est en ordre et en informer toute l’équipe.

Le cas échéant, plusieurs allers-retours s’opèrent entre les développeurs et les testeurs afin de trouver rapidement la source des bugs rencontrés. Une fois les bugs identifiés par les développeurs, ces derniers les corrigent, les testeurs s’assurent à nouveau de leur bonne conformité avant de donner leur go concernant la livraison d’un hotfix (système d’écrasé / remplacé) en production.

Il serait erroné de penser qu’une équipe produit n'interagit qu’entre 3 corps de métiers : le Product Owner, le Scrum Master et l’équipe de réalisation. En effet, une équipe agile est en contact permanent avec d’autres parties prenantes essentielles au succès d’un produit.

Les autres rôles qui gravitent autour d’une équipe produit Scrum

Product Owner, Scrum Master et l'équipe de réalisation interagissent bien évidemment avec d’autres corps de métiers indispensables au bon développement du produit. En voici un aperçu non exhaustif.

Le Coach Agile / Produit

Le rôle de Coach Agile / Produit n’est pas assuré dans toutes les équipes produit ou même de façon générale dans une organisation produit, mais il n’est pas rare que les équipes soient amenées à travailler avec l’un d’entre eux.

Le rôle du Coach n’est pas d’entrer dans le fonctionnel mais d’apporter son expertise sur les méthodologies agiles et produit. Il peut être prescriptif sur les méthodologies employées tant au niveau de l’équipe que sur l’organisation et les process et peut également être en contact aussi bien avec le métier qu’avec la direction.

Il accompagne toutes les parties prenantes de l’équipe : le Product Owner, le Scrum Master et l’équipe de réalisation et les conduit à prendre les meilleures décisions concernant son organisation.

L’écoute est son point fort et sa philosophie positive permet à l’équipe d’évoluer dans une atmosphère vertueuse maximisant la productivité.

Le Business Analyst

De la même façon que le Coach, le Business Analyst n’est pas un rôle assuré dans toutes les organisations mais quand il y en a un, il est l’allié numéro 1 du Product Owner. En effet, ce dernier se rapproche régulièrement du Business Analyst afin de disposer de données, de KPIs et d’études quantitatives / qualitatives l’aidant à prendre des décisions sur le développement du produit. Il peut aussi avoir un regard d’expert sur certaines parties du processus de l’entreprise et fournir des informations précieuses au Product Owner.

Les commerciaux

Les commerciaux sont les meilleurs connaisseurs des utilisateurs puisqu’ils sont en permanence à leur contact. En effet, c’est eux qui vendent le produit, produit dont ils appréhendent tous les contours.

Proches des utilisateurs ils sont souvent en première ligne pour recueillir des feedbacks utilisateurs et sont à l’initiative de nombreuses demandes d’évolutions auprès du Product Owner.

Riche de nouvelles remontées, ce dernier doit savoir évaluer la valeur de chaque demande et argumenter de façon factuelle auprès du pôle commercial lorsqu’une idée d’évolution n’est pas priorisée dans le backlog.

Attention toutefois aux organisations pilotées par les commerciaux qui vendent des fonctionnalités qui n’existent pas. Dans ce cadre, la relation peut être compliquée et peut engendrer des conflits sur la vision du produit.

Les autres rôles techniques

L’équipe pourra aussi être amenée à interagir avec d’autres rôles techniques de l’organisation, par exemple un architecte, qui sans travailler au jour le jour sur le produit, sera garant de la cohérence des choix techniques de l’équipe avec la stratégie du SI.

Ainsi, les trois rôles prévus par Scrum sont enrichis par les échanges avec les autres corps de métiers de l’entreprise pour construire un produit toujours meilleur. Les approches agiles mettent l’accent sur les individus et les interactions, une bonne équipe produit saura se reposer sur les compétences de chacun pour alimenter sa vision !