Le rôle du Product Owner au sein d’un projet Agile Scrum

Avant de découvrir le rôle que doit avoir un Product Owner au sein d’un projet Agile Scrum, je vous invite vivement à lire mon article sur la présentation de la Méthode Agile Scrum. Sans comprendre les fondements de cette méthodologie vous ne saisirez pas pleinement l’importance du rôle que doit avoir un Product Owner dans un projet.

Définition du rôle de Product Owner

J’entends souvent les réflexions suivantes : « Mais en fait le PO, c’est un chef de projet ? », « Mais Scrum et PO c’est un peu kiff kiff non ? »

La réponse est claire, c’est non. Il est l’heure que nous revoyons un peu la théorie ensemble.

Le Product Owner est le garant de la valeur du produit résultant du travail de l’équipe de développement (comme son nom l’indique il « Own » le produit). Son but est de maximiser cette valeur produit et pour se faire il est tourné vers :

• La team et l’opérationnel, la production, l’intra-entreprise,
• Le client, les parties prenantes (stakeholders), la concurrence, le marché,
• Le métier, maîtrise des techniques de définition de produit.

Afin d’identifier, mesurer et maximiser cette valeur produit, le PO doit gérer le backlog produit et la communication entre les parties prenantes. Je vous propose que nous nous penchions sur ces deux points.

La gestion du backlog produit 

Dans un premier temps, il est important de mentionner que le backlog produit représente l’ensemble des fonctionnalités que doit rassembler le produit final. Pour mener à bien cet objectif de création de backlog, il est nécessaire que le PO puisse gérer cela convenablement. Pour ce faire, voici les différentes tâches qui lui incombent :

• L’expression claire des éléments du backlog produit (nous parlons ici d’Epics, de features, de user stories),
• La priorisation des éléments dans le backlog produit pour mieux réaliser les objectifs et les missions,
• L’optimisation de la valeur du travail effectué par l’équipe de développement,
• L’assurance que le backlog produit est visible, transparent et clair pour tous,
• L’assurance que l’équipe de développement comprend adéquatement les éléments du backlog produit.

Finalement, le product owner est le seul maître à bord de son backlog !

Ainsi, toute l’organisation se doit de respecter ses décisions. Seul le product owner peut changer la priorisation de son backlog produit et nul ne peut forcer l’équipe de réalisation à travailler sur un autre backlog que celui porté par le PO.

Dire « non » se révèle aussi être une des tâches importantes du PO, car il ne faut pas oublier que c’est lui qui est garant de la vision produit. Les raisons peuvent être multiples et sont toujours justifiées : pas dans la vision, pas faisable, etc.

Le PO doit avoir au quotidien des conversations constructives avec l’équipe de développement notamment pour s’assurer que l’équipe partage ait une compréhension commune et juste de :

• ce qu’il y a à délivrer,
• la valeur apportée par chaque élément,
• du niveau de qualité attendu,
• l’adéquation des solutions aux besoins.

La communication auprès des parties prenantes

Afin de créer son backlog produit, le product owner est le réceptacle des besoins qui feront la valeur du produit. Avec l’aide de l’équipe Scrum il analyse et transforme les besoins recueillis auprès des parties prenantes en user stories. Ces dernières constitueront ensuite le backlog produit. Pour faire simple, il est le relais principal entre l’organisation et l’équipe de développement.

Il tient également le rôle de communicant sur le projet. A lui de faire rayonner son produit auprès des parties prenantes, en amont comme en aval des développements. Le PO a pour ambition d’obtenir un consensus, ou au moins le consentement, de tous les acteurs concernés de l’entreprise, quant aux priorités listées par le backlog produit et donc quant aux livrables qui seront réalisés.

Voici un joli schéma récapitulatif : « La roue du Product Owner ».

Product Owner, Proxy Product Owner, Product Manager, même combat ?

Avant que le combat ne commence, rappelons-nous les 3 seuls rôles existants au sein de l’approche Agile Scrum :

• Product Owner
• Scrum Master
• Equipe de réalisation (« development team »)

Mettons-nous bien d’accord, il n’y a pas écrit « Chef de projet » ou « Chef de produit ».

Il est tout de moment important de préciser que le rôle de Product Owner, peut varier grandement selon les organisations, les équipes Scrum et les individus.

Afin d’éclaircir les idées que nous nous faisons sur tous les termes que nous entendons et que nous mettons à tort dans le même sac, je vous invite à chacun de leurs duels pour enfin mettre un point final à vos interrogations.

Product Owner VS Proxy Product Owner

Le « Proxy Product Owner » est souvent évoqué au sein des projets Agile, même si ce dernier n’est pas un rôle « officiel » de l’approche Scrum. Finalement, il est très souvent présenté comme le bras droit du Product Owner, notamment lorsque celui-ci ne peut pas réaliser toutes ses tâches par manque de disponibilité. Pour faire simple, il forme un binôme avec le PO.

Product Owner VS Chef de projet (ou MOA)

Certaines tâches du PO peuvent correspondre avec celles d’un Chef de projet (ou Project Manager) mais ne les confondons pas ! Le chef de projet rédige des « Spécifications techniques » ou un « Cahier des charges », alors que le PO rédige des « User Stories ». Ce n’est pas qu’une question de mots mais surtout de méthodologie utilisée dans la gestion de projet qui est mené. En effet, le chef de projet s’inscrit dans une méthodologie de gestion de projet en V ou en cascade mais pas en Agile. Le rôle du « chef de projet » indique aussi une hiérarchie verticale, complètement en contradiction avec les valeurs de l’Agilité et le sens même de « Scrum team ».

Le PO n’est pas du côté de la Maîtrise d’Ouvrage (aussi appelé MOA) : il s’assure que tout le monde partage la vision produit. Il n’est pas la juste pour livrer des User Stories, mais pour échanger de manière constructive avec l’équipe sur la vision et la priorisation à donner sur le projet.

Product Owner VS Scrum Master

Le PO n’est pas un Scrum Master, ces deux rôles sont très différents. Le Scrum master, n’intervient pas dans le backlog produit, il ne rentre d’ailleurs pas dans le détail technique ou fonctionnel. La priorité du Scrum Master est l’organisation de l’équipe et la façon d’optimiser cette dernière. C’est un facilitateur.

Néanmoins, le Product Owner peut s’appuyer sur le Scrum Master concernant les tâches suivantes :

• S’assurer que les objectifs, le périmètre et le domaine du produit sont compris par tous les membres de l’équipe Scrum de la meilleure façon possible,
• Trouver des techniques pour une gestion efficace du Backlog produit,
• Aider l’équipe Scrum à comprendre le besoin de clarté et concision des éléments du Backlog produit,
• Comprendre la planification de produits dans un contexte empirique,
• S’assurer que le Product Owner sait comment organiser le Backlog produit pour maximiser la valeur,
• Comprendre et mettre en œuvre l’agilité,
• Faciliter les événements Scrum, en cas de demande ou nécessité.

Product Owner VS Chef de produit

Parlons maintenant du « Chef de produit » (ou Product Manager). Ce rôle n’existe pas à proprement dit dans l’approche Agile Scrum. En revanche il peut rejoindre le rôle du PO sur certains aspects, leurs compétences peuvent se révéler être complémentaires. Dans un contexte ou les charges opérationnelles (US, cérémonies, recette, etc) sont importantes, la présence d’un Product Manager peut être avantageuse. En effet, il peut aider le PO à identifier les besoins métiers, à communiquer avec les stakeholders, à réaliser les recherches utilisateurs, etc.

Mais attention : dans ce cas, il sera plus complexe pour le PO de réellement garder la main sur la vision produit et sur son Product Backlog ! Ainsi, je préconiserai plutôt de se faire aider par un Proxy Product Owner, ce qui permettra au PO de dégager du temps (mais ce n’est que mon avis !).

Autre exemple, dans le cas de larges projets ou on retrouve plusieurs Scrum Teams travaillant sur un même produit, il faudra un Product Owner pour chaque Scrum Team. Dans ce contexte, un « PO Master » ou à défaut, un « Product Manager » sera nécessaire afin d’assurer une vision commune entre les différentes équipes.

Quels conseils pour être un bon PO ?

Il n’y a évidemment pas de recette miracle pour être un bon PO. C’est un rôle très riche, qui requiert des compétences diverses, pour cela je pense qu’il faut :

• être ouvert d’esprit et empathique,
• savoir communiquer comme écouter,
• avoir une vision précise de l’avancement de son projet, tout en ayant le recul nécessaire,
• savoir dire non et prendre des décisions rapidement,
• valoriser et protéger son équipe,
• savoir anticiper,
• être réactif et force de proposition
• etc.

Même si vous avez toutes ces qualités (et je n’en doute pas !), n’oubliez pas que la première des conditions reste évidemment celle d’avoir une équipe engagée ! Un PO n’est rien sans sa Dream Team ! #DedicaceDreamTeamMobileStudioCellenza

Cette thématique vous intéresse ? Plongez au coeur du métier de Product Owner en découvrant deux de nos articles de blog qui présentent les outils du PO : la création du persona et l’Empathy Map.