Bien des Business Analysts, lorsqu’ils endossent le rôle de Product Owner après avoir été consultant fonctionnel ou AMOA dans un projet géré en V, se sentent un peu perdus avec leur nouvelles responsabilités.
Parfois (souvent), en tant que prestataire externe, ils sont amenés à assister le Product Owner qui est un collaborateur interne à l’organisation. Beaucoup se demandent quel est leur périmètre réel et leur latitude de travail. Recommander, assister, ou décider ? Pas forcément évident, d’autant plus qu’il n’y a pas de situation universelle (parlons de la vie réelle, et pas uniquement de théorie…).
J’ai été interpellée par la question de Marek, sur laquelle je suis tombée au hasard de mes pérégrinations sur la Toile. En fait, sa question est loin d’être anodine ou unique, car beaucoup de Business Analysts nouvellement promus au poste ou au rôle de Product Owner ont du mal à se positionner dans les projets gérés de manière agile.
>> Lire aussi: Le dilemme des évolutions de poste quand on est Business Analyst
La plupart ont un agenda “réactif” et non “proactif”, et courent d’une sprint review à une autre sans être sûr de leur réelle plus-value au niveau du projet.
Marek est Product Owner, et la problématique qu’il expose ici est liée au fait qu’il n’est pas le seul à ce rôle de PO. Alors : est-ce normal ou est-ce une erreur d’organisation?
La question de Marek
« J’ai une question à vous poser, car après avoir fait des recherches, j’ai trouvé différentes réponses et je ne sais pas laquelle est juste.
Voici le contexte de ma question : dans mon projet actuel, nous sommes 3 Product Owners (PO), chacun positionné à un niveau différent. L’un d’entre nous fait partie de l’équipe de développement, et les deux autres participent aux demos et sprint reviews.
Comme nous sommes en phase de de pré-projet, c’est trop tôt pour déterminer précisément ce que nous allons réellement développer comme solution. Par conséquent, il est aussi compliqué de se répartir les tâches de Product Owner et d’identifier qui est responsable de quoi.
Merci pour votre aide,
Marek »
La réponse du modérateur du Scrum Guide
Un Product Owner par équipe
Marek a posé cette question dans le forum du Scrum Guide, et un des modérateurs lui a donc répondu ceci :
Pour chaque Produit, il ne doit y avoir qu’un seul PO. Le guide SCRUM précise : « Le Product Owner est une seule personne, pas un comité de personnes »
Avoir plus d’un PO impacte la transparence, puisque l’équipe de développement et les parties prenantes pourraient recevoir des messages contradictoires, provenant des différents Product Owners.
Il est préférable d’avoir une seule source d’information qui puisse répondre à toutes les questions de l’équipe de développement de manière cohérente, sans générer de problèmes de communication.
>> Lire aussi: Savez-vous gérer les changements de périmètre de votre projet?
Le guide SCRUM complète: « Dans le Product Backlog, le Product Owner peut représenter les besoins exprimés par un comité de personnes. Cependant, ceux qui veulent modifier la priorité d’un élément inscrit au Product Backlog doivent s’adresser au PO lui-même. »
L’organisation que vous décrivez est donc a priori celle d’un comité de Product Owners.
Plusieurs Product Owners par unité organisationnelle
Nous rencontrons souvent ce genre de situation dans l’entreprise où je travaille actuellement. Il y a un seul et unique PO par équipe. Cependant, tous les PO collaborent au sein de la même unité organisationnelle. Ils discutent, établissent les priorités, coordonnent les éléments qui dépassent les limites de charge de l’équipe ou du périmètre produit et s’assurent que les informations nécessaires au travail des équipes de développement leur parviennent dans les délais prévus. Toutefois, un seul Product Owner assure l’interface avec l’équipe technique dans le cadre de ce rôle de PO.
>> Lire aussi: Où s’arrête le rôle du Business Analyst (et où commence celui de l’équipe technique)
Il est également courant que les Product Owners invitent d’autres PO à participer aux demo et sprint reviews, mais dans ce cas, ceux-ci y participent uniquement en tant que parties prenantes. Ils ont en effet un intérêt aux outputs de l’équipe de développement car cela affecte également le travail que leurs équipes doivent effectuer.
Tant que les Product Owners communiquent bien entre eux au sein de notre organisation, cette manière de procéder fonctionne bien.
Ce qu’en dit le guide Scrum
Définition des rôles et responsabilités du Product Owner
Le guide SCRUM est disponible gratuitement en ligne, donc n’hésitez pas à la consulter si vous avez des doutes sur votre positionnement en tant que Product Owner.
Cela ne lèvera pas toutes les ambiguïtés – notamment quand l’utilisation et l’application de l’approche agile SCRUM est dévoyée (ce qui arrive encore trop souvent !), mais cela pourra très certainement vous aider.
>> Lire aussi : Marre des pseudo-projets agiles!
Revenons aux rôles et responsabilités du Product Owner.
Celui-ci est généralement une personne-clé d’un projet agile. Dans de nombreux cas, il ou elle contrôle le financement du projet et, si ce n’est pas lui, il est en tout cas responsable devant ceux qui le font de la réalisation de leurs visions, de manière à maximiser leur retour sur investissement.
Définir la vision
Le Product Owner est chargé de décomposer les objectifs généraux, qui sont souvent formulés en termes commerciaux et marketing, en une série de sous-objectifs. Il ou elle est responsable de la création du Product Backlog, lequel est une liste hiérarchisée des exigences du produit associée à une estimation du temps nécessaire à leur réalisation.
>> Voir aussi: Modéliser vos exigences métier grâce au Business Data Diagram®
Le Product Backlog est l’une des principales responsabilités du Product Owner, qu’il doit normalement créer et tenir à jour. Néanmoins, il peut déléguer cette tâche à d’autres personnes.
Une équipe de Product Owners peut également être constituée pour accomplir les différentes activités. Dans ce cas, un membre de l’équipe de Product Owners doit être désigné comme représentant de tout le groupe. Ce représentant est la seule personne à qui l’équipe de développement Scrum s’adresse pour obtenir des réponses définitives à ses questions.
Les décisions ne doivent pas être prises par un comité mais par un seul Product Owner.
Responsabilités vis-à-vis de l’équipe de développement
Il est fondamental que le Product Owner partage et implique l’équipe de développement dans la vision exprimée par le client ou l’organisation. Le PO doit répondre à toutes les questions de l’équipe et écouter ses suggestions pour ajouter, supprimer, modifier ou améliorer les objectifs.
>> Lire aussi: Pourquoi le document de cadrage est-il si important ?
Cette démarche est importante car elle contribue à motiver l’équipe et à recueillir le feedback des utilisateurs.
Définir les contraintes
Outre la définition des objectifs du projet, le Product Owner est responsable de la définition des limites ou des contraintes pesant sur l’atteinte des objectifs. Les contraintes sont par exemple les dates d’achèvement, les limites de coûts, de mémoire ou de vitesse de traitement, les exigences non fonctionnelles, etc.
>> Voir aussi : [VIDEO] Définir les Exigences Non Fonctionnelles
Ces limites ou contraintes demandées par le Product Owner doivent être acceptables, réalistes et techniquement possibles à atteindre. La démarche Scrum permet théoriquement la communication et les échanges constants entre les utilisateurs ou leur représentant, et l’équipe de développement. Ainsi, dans le cas où certains objectifs irréalistes sont quand même soumis à l’équipe de développement Scrum, leur détection et l’élaboration d’une feuille de route précoces sont possibles.
La priorisation des tâches
Éviter un «effet tunnel»
Un autre facteur qui affecte la réalisation des objectifs est la hiérarchisation des tâches dans un sprint. L’équipe travaille d’abord sur les segments les plus importants et, une fois ceux-ci terminés, ils peuvent être livrés à l’utilisateur ou au client. Il s’agit généralement de fonctionnalités qui apportent une valeur ajoutée au produit cible et qui favorise un retour sur investissement rapide et positive.
La démarche Scrum permet d’éviter le fameux «effet tunnel» observé sur les projets gérés de manière traditionnelle (cycle en V ou en cascade, par exemple), grâce à la mise en production incrémentale et fréquente des fonctionnalités développées prioritairement lors des sprints.
Encourager le retour utilisateurs
Un autre avantage de cette démarche est que le feedback utilisateurs, qu’il soit bon ou mauvais, revient beaucoup plus précocement que pour les projets gérés de manière traditionnelle. Ce retour d’information signifie généralement qu’il y a des modifications à apporter au « reste à faire » du projet.
>> Lire aussi: Comment éviter un processus de vérification qui s’éternise
La priorisation judicieuse des items du Product Backlog permet ainsi de revoir les objectifs ultérieurs, de les modifier, d’en éliminer certains ou au contraire d’en ajouter de nouveaux. Enfin, comme ces demandes de changements sont intervenues alors que le projet était encore en cours de réalisation, ils seront intégrés à moindre coût que si le projet était déjà terminé.
C’est l’une des grandes différences des approches agiles avec les projets gérés de manière traditionnelle : l’intégration des changements, tôt ou tard, est en effet non seulement attendue mais souhaitée.
Et vous, quelle a été votre première expérience de Business Analyst en tant que Product Owner ?
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
