Ancien développeur devenu Scrum Master, je suis aujourd’hui facilitateur pour une équipe Scrum. Je me suis rendu compte au fur et à mesure de mes expériences que je comprenais  donc logiquement mieux le métier de développeur que celui de Product Owner (PO).

Ce sentiment est aussi partagé pour la plupart des Scrum Masters que j’ai pu croiser sur mes différentes missions.

Même si je savais à quoi correspondait le rôle de Product Owner, j’ai ressenti le besoin de mieux comprendre les tâches et objectifs de ce membre de l’équipe Scrum.

Pour ce faire, j’ai pas mal arpenté les articles et autres billets de blog sur le sujet, jusqu’à arriver sur le blog de Roman Pichler (https://www.romanpichler.com/). La biographie de cet expert en management produit est disponible sur le site pour les plus curieux.

Ayant trouvé ses articles pertinents et accessibles, j’ai poursuivi ma lecture jusqu’à son livre “How to lead in product management”, qui m'a donné une vision plus fine du rôle du PO. Et c’est pourquoi j’ai décidé de partager cet article avec les points importants de ce livre et mes avis sur ceux-ci.

Cet article permettra aux Scrum Masters de mieux comprendre les actions et les interactions d’une personne “gérant un produit”. Il aidera un PO à comprendre et adopter la posture de leader vis à vis de son produit. Il pourra aussi aider l’équipe de développement à mieux comprendre le fonctionnement d’une personne orientée produit dans une équipe Scrum.  
« True leaders understand that leadership is not about them but about those they serve. It is not about exalting themselves but about lifting others up » Sheri L. Dew ("Les vrais leaders comprennent que le leadership n'est pas à leur service mais au service de ceux qu'ils servent. Il ne s'agit pas de s'exalter mais d'élever les autres")

Les interactions du Product Owner

Dans le rôle de PO, avoir de bonnes interactions avec les individus avec qui il travaille est essentiel pour les guider vers la réussite du produit.

1 - Construire la confiance

Lorsque la confiance n’est pas installée entre plusieurs personnes, les interactions ont tendance à être plus superficielles. Sans confiance, on a plus tendance à éviter les débats et les désaccords. Ce qui peut parfois freiner la collaboration ou la rendre compliquée.

Dans le manifeste agile, plusieurs principes sont basés sur l’importance de la collaboration entre les membres de l’équipe (et aussi avec les utilisateurs), ce qui est primordial pour un produit réussi.

Extrait du manifeste agile

De plus, si l’équipe ne fait pas confiance au PO, il sera compliqué pour eux d’adhérer à la vision. Ils n’agiront que par obligation (au mieux), ce qui n’est pas optimal pour le produit non plus.

Il est donc très important qu’il y ait une confiance omniprésente dans l’équipe.

Pour construire une relation de confiance dans l’équipe, R. Pichler donne quelques conseils au PO :

• Interagir avec les personnes de manière authentique et avoir de l’intérêt pour eux.
• Écouter et être ouvert d’esprit : ne pas juger les idées prématurément et être reconnaissant de la contribution de chacun.
• Parler et agir avec intégrité : être transparent, ne pas cacher de vérité. Être prêt à admettre ses erreurs. Ne pas parler mal d’autres personnes.
• Apprendre à connaître les gens et les laisser apprendre à vous connaître.
• Impliquer les individus dans les décisions produits et les encourager à partager leurs idées et inquiétudes. Le PO est un meneur, non un chef.
• Etre solidaire et offrir son aide quand il y en a besoin.

De plus, il est important pour le PO de renforcer son savoir sur le produit : plus il a de connaissances sur le marché, les utilisateurs et le produit, plus il sera facile d’appliquer des bonnes pratiques de gestion de produit (créer une stratégie produit, développer la roadmap produit, valider les idées …). Et cela renforcera la confiance de l’équipe avec son PO. Ces astuces sont à mettre en place et à maintenir dans l’équipe.
Guider l’ensemble des individus vers une relation de confiance permet de travailler efficacement sur le produit. Ainsi l’équipe avancera vers un objectif commun de la meilleure façon possible.

2 - Partenaire du Scrum Master

Pour rappel, selon le Scrum Guide (2020) un Scrum Master est le garant du cadre Scrum. Il est aussi le leader qui sert l’équipe Scrum dans l’organisation.

Pour un PO, avoir de bonnes interactions avec l’équipe de développement et avec les parties prenantes est indubitablement important. Mais une collaboration efficace entre un PO et un Scrum Master est souvent sous-estimée. Le Scrum Master est pourtant un partenaire clé du PO pour faire progresser le produit.

Le Scrum Master doit être vu comme un facilitateur ou un coach, quelqu’un qui aide les autres à comprendre comment créer un produit plein de valeur et à continuellement améliorer la façon de travailler de l’équipe.

Le Scrum Master est, pour le PO, un super partenaire. Ensemble, ils peuvent discuter des processus, réfléchir sur le produit et discuter des interrogations et préoccupations des développeurs ou des parties prenantes.

Ainsi un Scrum Master pourra aider le PO à trouver des techniques pour définir des objectifs efficaces en transmettant des outils pertinents (Ex : Chaîne des Objectifs de R. Pichler, Empathy map, …).Il pourra aussi apporter son aide dans la gestion du Backlog Produit ou encore faire un travail de facilitation dans la collaboration des parties prenantes.
C’est pour cela qu’il y a un réel enjeu à ce que ces deux rôles soient partenaires et qu’ils travaillent ensemble vers un but commun.

3 - Guider les développeurs

Une équipe de développement efficace n’est pas juste chargée de concevoir et implémenter le produit. Ses membres doivent également aider à trouver des nouvelles idées, redéfinir les tâches du backlog produit (recueil de l’ensemble des évolutions à apporter au produit) et prendre les meilleures décisions possibles. Pour arriver à ce stade, le PO doit donner à l’équipe les conseils et le support nécessaire mais aussi les écouter et les traiter comme un partenaire égal.

3.1 Auto-sélection

Il est important de laisser le choix aux développeur·euse·s. Pour choisir les bonnes personnes il faut leur laisser le choix de faire partie de l’équipe ou non.
S'ils choisissent de travailler sur ce produit, ils ont de plus grandes chances d’être motivés.

Il est également préférable de former des équipes stables. Une équipe stable à une meilleure performance qu’une équipe qui doit sans cesse accueillir de nouveaux membres ou laisser partir les plus anciens.

Une équipe s'épanouit s'il y a de la confiance entre les membres. Et cela n’arrive qu’avec de la stabilité (stabilité qui arrive généralement au bout de 2 à 6 mois).

On peut donc par exemple, lors du recrutement, s’assurer que les potentiels membres de l’équipe s’engagent sur un certain laps de temps à rester sur la mission.

Et lors de l’intégration d’un nouveau membre, il est aussi important de le faire travailler en binôme, ce qui améliorera ses liens avec l’équipe et sa montée en compétences. Et cela contribuera à une meilleure stabilité générale.

3.2 Impliquer les développeurs

Le PO et le Scrum Master doivent mettre en place les moyens pour que les développeurs comprennent et s’approprient le produit. Cela leur permettra d’aider le PO à prendre les bonnes décisions.

Que cela soit dans l’écriture ou le découpage des tickets pour que les développeurs les comprennent plus facilement. Ou en aidant le PO à comprendre comment prioriser les tickets d’un sprint en identifiant les adhérences techniques et les potentiels points de blocage futurs.

Une bonne manière de faire est d’inclure les développeurs dans les ateliers dédiés au produit voire même si possible de les inciter à interagir directement avec les utilisateurs.

De plus, les impliquer dans l’élaboration du backlog produit en leur apprenant à formuler ou affiner des tickets d’évolution est important.

Ainsi les développeurs pourront être force de proposition en prévoyant, par exemple, des tickets d’études quand les sujets sont nouveaux techniquement. Ou proposer des améliorations utiles et techniquement moins coûteuses, pas forcément identifiées par le PO.

Cela peut paraître long au début, mais tous ces efforts permettront aux développeurs de comprendre le produit et de se l’approprier. Cela augmentera leur motivation et renforcera leurs engagements.

L’équipe sera plus autonome et plus motivée, donc plus performante.

3.3 Ne pas diriger l’équipe

Un PO doit gérer le produit, mais pas l’équipe. L’équipe de développement a vocation à être auto-organisée.

L’équipe s’organise, sous l’influence du scrum master pour gérer ses tâches.

Il ne faut pas que le PO essaye de micro manager l’équipe.

Un PO qui essaye de manager une équipe n’aide pas les développeurs à devenir auto-organisés. Ainsi leurs proactivité sera obligatoirement brimée. Et ils donneront moins leurs avis (ce qui ne permettra pas d’avoir les bienfaits cités ci dessus).

De plus, le travail d’un PO vis à vis de son produit est déjà chronophage. Il n’a pas de temps à perdre avec le management de l’équipe, ce n’est pas son rôle. Si il le fait, il perdra de vue son produit, ce qui implique une perte de son statut de leader sur le produit. Ainsi il risque d’y avoir des objectifs moins pertinents, une perte de la vision…

Ce qui au final fera perdre de la motivation à l’équipe et à ses membres.

3.4 Avoir des interactions efficaces

Une équipe de développement auto-organisée est un groupe de personnes qui travaillent ensemble, à leur manière, vers un but commun qui est défini en dehors de l’équipe. Ainsi une équipe auto-organisée n’est pas absolument autonome. Les objectifs de l’équipe restent liés au produit et il est primordial que les développeurs et le PO aient une relation rapprochée pour pouvoir les atteindre.

Avoir un backlog produit prêt et choisir l’objectif de Sprint

Pour des interactions efficaces, le PO doit arriver au sprint planning avec un backlog produit prêt. Il ne doit pas oublier de définir un objectif de sprint avec l’équipe de développement. Il est important de co-construire cet objectif avec les développeurs et de ne pas leur imposer.
En fin de sprint planning, l’objectif de sprint doit être significatif, réaliste et toute l’équipe doit être satisfaite de l’objectif choisi.

Déterminer la charge de travail

Laissez les développeurs déterminer librement (avec l’aide du Scrum Master qui facilitera cette capacité de détermination) la charge de travail qu’ils pourront absorber pendant le sprint. Ne leur mettez pas la pression !

Si le PO pousse pour avoir plus de travail que ce que les développeurs ont choisi, il y a de grandes chances pour qu’ils prennent des raccourcis ou qu’ils ne réalisent pas tout.

Ces raccourcis peuvent se traduire par une baisse de qualité (produit moins maintenable, bugs) ou par un manque de documentation ce qui diminue à moyen/long terme la capacité d’évolution du produit.

De plus, en forçant la main, le PO quitte la relation d’égal à égal de l’équipe ou chacun à son domaine d’expertise. Il envoie un message de manque de confiance, voire de hiérarchie dans l’équipe. Ce qui peut impliquer pas mal de choses, dont une grosse perte de motivation.

Être disponible

Tout au long du sprint, il est important pour le PO de se rendre disponible pour les développeurs. Être disponible pour répondre aux questions, pour les aider à progresser sur leurs connaissances produit ou fournir un feedback sur le travail déjà accompli sont des tâches du PO.

Il est indispensable que le PO soit disponible et qu’il participe aux rituels (et ne pas être que spectateur). Il faut que le PO mette tout en œuvre pour ce faire, ce qui peut impliquer l’aide du Scrum Master et le management pour garantir sa disponibilité.

4 - Interagir avec les parties prenantes

Rappel : le travail d’un PO n’est pas de faire plaisir aux parties prenantes. Il doit plutôt les guider de manière proactive pour s’assurer que le produit crée la valeur nécessaire pour les utilisateurs et le business.

Pour les guider de la meilleure manière, il est important de créer une vraie communauté de parties prenantes.
C’est toujours mieux d'interagir avec les parties prenantes de manière collective plutôt que de manière individuelle. En tête à tête, on perd la sagesse et la créativité du groupe (d'où le proverbe “Deux avis valent mieux qu’un”).

En créant les situations ou les parties prenantes passent du temps ensemble, le PO favorise le développement d’un sentiment d’unité qui va rendre l’établissement d’objectifs communs plus facile. Cela contribuera à renforcer leur sentiment d’engagement.

C’est pour cela que Roman Pichler préconise de créer une communauté de parties prenantes où chaque membre travaille, soutien et a confiance en l’autre. Il est aussi important que chaque personne connaisse sa place et ce qu’on attend de lui dans cette communauté.

La matrice de Mendelow, est un outil que le PO peut utiliser pour identifier et classifier les différentes parties prenantes. Cela lui permet de mieux comprendre leurs rôles, leurs objectifs et l’aide à créer une réelle communauté de parties prenantes.

Il peut aussi organiser des rétrospectives entre parties prenantes pour rechercher l’amélioration continue. Ce qui permettrait à la communauté de prendre du recul et d’identifier ce qu’elle fait bien, mais aussi ce qu’elle fait moins bien pour trouver des actions d’améliorations et être plus efficace.

Toutes ces actions demandent du temps. Mais cela ne veut pas dire qu’il faut laisser le PO être surchargé ou délaisser les tâches de management produit. Le Scrum Master peut aider à identifier et créer cette communauté de parties prenantes.

Conclusion

Cette lecture de “How to lead in product development” m’a appris beaucoup de choses et m’en a rappelé d’autres.

Il met l’accent sur la posture du Product Owner. Il a une posture de leader dans l’équipe pour s’assurer que l’ensemble des membres partage sa Vision produit.

Il a aussi un rôle de leader auprès des parties prenantes pour leur permettre de construire et comprendre au mieux les enjeux du produit.

Le PO n’est donc pas un simple exécutant produit, mais bien un réel leader, qui guide les différents acteurs de la vie du produit au quotidien.

De plus, Roman Pichler donne des outils et des astuces qui peuvent aider le Scrum Master à comprendre le rôle de PO et aider celui-ci de la meilleure des manières.

Il propose des outils qui portent sur différentes thématiques comme la matrice de Mendelow qui peut être utilisée et maîtrisée facilement dans un contexte agile (par le PO ou par le Scrum Master).

C’était donc une lecture intéressante plus axée Produit et rôle du Product Owner. Cela m’a permis de mieux comprendre les spécificités de ce rôle. Je me sens plus prêt à travailler avec le Product Owner mais surtout plus apte à mieux le conseiller afin de l’aider à atteindre son statut de leader produit, que cela soit dans une équipe Scrum ou dans l’organisation.