• Agile Suisse

Les secrets du Product Owner - Partie 2

Il y a quelques semaines, nous étions une vingtaine de personnes à nous réunir à nouveau en ligne lors du Meet Up Agile in Geneva. Maria et Elise d'Agile Suisse, nous proposaient d'aborder "Les secrets du Product Owner", afin d'éclaircir ce rôle qui est souvent mal compris. La diversité des participants nous a permis d'échanger sur le rôle et les responsabilités du Product Owner et a confirmé une nouvelle fois que la compréhension du rôle n'est pas évidente et qu'elle peut varier selon les contextes et la maturité des équipes.

Est-ce que le Product Owner doit tester les users stories ?

L'équipe est responsable de ce qu'elle a livré. Le Product Owner doit partager ses commentaires au sujet de l'incrément à l'équipe et toujours s'assurer de l'alignement avec la vision du produit.

Il ne doit donc pas littéralement tester, mais plutôt valider. Il peut déléguer la validation et s'appuyer sur d'autres membres de l'équipe.

Concernant les tests, il faut au moins une personne dans l'équipe avec cette compétence de test. On peut retrouver généralement dans la "Définition de Terminé" un passage faisant référence aux tests de la story. C'est une bonne chose, mais attention à ne pas cantonner cette partie à une seule personne. C'est l'équipe SCRUM dans son intégralité qui est responsable de tester.

Si les tests sont faits uniquement par le PO ou des personnes spécifiques, on observe généralement un impact sur le burn-down chart car les tests sont faits en bout de chaine et en dernière minute.

Nous avons également discuté le fait que le Product Owner valide les stories uniquement lors de la revue de sprint. Ce n'est pas une obligation mais c'est fortement recommandé de pouvoir le faire tout au long du sprint.

En dehors de participer aux cérémonies de SCRUM c’est quoi le rôle du Product Owner ?

Le Product Owner est la voix de l'utilisateur ou du client. Il a pour mission de remonter les besoins du métier et il détermine les priorités afin d'organiser le Backlog.

C'est certainement le rôle le plus complexe à coacher et sur lequel l'impact est d'autant plus fort. Le Product Owner est un des 3 rôles de l'équipe Scrum et il ne doit pas être sous-estimé. Le rôle de Product Owner, peut selon les contextes, clairement être un rôle à temps plein et il peut généralement difficilement être cumulé avec d'autres missions.

Le Product Owner ne doit pas s'immiscer dans les choix techniques, il doit avant tout porter la vision de son produit et être à l'écoute de l'utilisateur.

Il est également le relai auprès des parties prenantes d'un projet. Il a pour objectif de mesurer la valeur et pouvoir partager les indicateurs de performances à suivre pour s'assurer que l'équipe prend bien la bonne direction.

Le Scrum Master et le Product Owner doivent également se répartir la communication avec les parties prenantes. L'un a pour objectif de promouvoir son produit, et l'autre a pour objectif avant tout d'éviter les blocages et les dépendances.

Dans les grandes organisations, on peut constater l'émergence de nouveaux rôles tels que Business Owner, Product Owner Proxi …. où la cohabitation avec un Product Owner peut s'avérer difficile si le cadre et la répartition des responsabilités ne sont pas clairs.

Quelle est la différence entre un Product Owner et un Business Analyst ?

Il s'agit de deux rôles différents mais ils peuvent collaborer.

Lors de la production d’une vision, le Business Analyst va proposer une solution.

Le Product Owner va recueillir des besoins de la part des utilisateurs.

Le Business Analyst, va ensuite transformer des besoins clients en spécifications.

La Business analyse c’est une compétence importance mais ce n’est pas un rôle à part entière. Dans une petite équipe, la Business Analyse est parfois faite par un Développeur ou par le Product Owner lui-même, et dans de plus grosses équipes, il peut y avoir 2 ou 3 personnes dédiées qu'on appellera alors Business Analystes.

La compétence de Business Analyse doit faire partie de l'équipe SCRUM, après qu'elle soit au sein de l'équipe de Développement ou chez le Product Owner peu importe.

Quels types de parties prenantes distinguez-vous dans un projet ?

Il y a les utilisateurs finaux, les décisionnaires, les autres équipes dépendantes et toutes les équipes qui vont toucher le produit, autant à sa conception qu’à son utilisation finale.

Parmi les parties prenantes, il y a les personnes qui influencent et ceux qui n’influencent pas.

En tant que Product Owner il est important d'avoir une bonne connaissance des parties prenantes et être également capable de les classifier par pouvoir et par intérêt.

Est-ce qu’il y a un Product Owner en Kanban ?

Oui mais il s'appelle "Service Request Manager".

Kanban ne préconise pas de changements dans les rôles.

Globalement c’est la même chose.

Que faire lorsqu'il n’y a pas de Product Owner ?

Le rôle du Product Owner est un des 3 rôles piliers de SCRUM, c'est vraiment difficile de travailler dans un contexte où le rôle ne serait pas incarné. Même l'équipe la plus mature en termes d'auto-organisation aurait des difficultés à suivre la vision du produit.

C’est quoi le lien hiérarchique entre le Product Owner et l'équipe de développement ?

Pas de lien hiérarchique, il faudrait idéalement que l’équipe Scrum ait le même manager.

Travailler sur la culture de l’organisation, avoir des objectifs communs. C'est certainement un des défis majeurs des RH dans les prochaines années.

Est-ce que le Product Owner peut être du côté de l’IT ?

Le fait que le Product Owner ait un background informatique pourrait être intéressant, pour faciliter la compréhension. Mais nous attirons votre attention sur le fait que le rôle du Product Owner est basé sur le besoin et non sur la solution. C'est donc avant tout une dimension fonctionnelle, du métier qu'il doit avoir.

Est-ce que le Product Owner s'intéresse plus au “Quoi”, au “Pourquoi” ou au “Comment” ?

Le Pourquoi c’est la vision et c'est clairement la mission première du Product Owner.

Ensuite le Quoi c’est plus le quotidien, c’est ce qu’il concrétise dans le Backlog du Produit et peut être ce qu’il va déléguer au Business Analyst.

Et le comment en revanche, c’est pour l’équipe de Développement.

C’est quoi les KPIs pour un Product Owner ?

L'un des premiers indicateurs pour le Product Owner pourrait être la Satisfaction des parties prenantes et de l’équipe.

Ensuite il peut facilement identifier selon le contexte et la mission de son produit, des indicateurs tels que l'adoption, les coûts, les revenus, la business value pratique VS business value théorique, le lead time, la fréquence de déploiement en production en comparaison avec le compétiteur…

Pour conclure cet article nous vous proposons cette image de Ron Eringa qui illustre bien l'échelle de maturité du Product Owner. Identifier où nous nous trouvons aujourd'hui dans notre contexte, peut permettre de travailler et identifier les leviers qui pourront nous permettre d'être pleinement un Product Owner "Entrepreneur".




Agile Suisse

Nous croyons que l'Agilité peut aider un grand nombre d'entreprises dans leurs défis. Si tu souhaites participer à cette aventure, nous serons ravis d'en discuter.

Email : agilesuisse@gmail.com

Téléphone : +41 76 788  68 07

IBAN CH1500768300152926307

Abonne-toi

Pour ne rater aucun événement

© 2019 par Agile Suisse Association |  CGV  |   Politique de confidentialité