Atelier de réflexion autour du rôle de PO

Le rôle de PO amène à beaucoup de questionnements dans les transformations basées sur Scrum. En effet, cela change beaucoup plus de choses dans une organisation qu’on pourrait le croire. Allier ces nouvelles responsabilités avec les anciennes peut parfois générer frustrations, craintes et incompréhensions.

Dans le cadre d’une mission, on m’a demandé d’animer une formation PO afin d’expliquer en quoi ce rôle consistait. Cependant, dans ce contexte déjà sensibilisé à Scrum, j’ai préféré opter pour une démarche plus participative, similaire à cet article. L’idée étant de limiter les débats stériles et générer les bonnes conversations.

Voici comment cela s’est passé.

Conception

Contexte

Pour démarrer cette conception, prenons tout d’abord quelques éléments du contexte.

1. Un rôle déjà en place à la DSI

Cela fait près d’un an que la DSI s’est mis à l’Agilité et les équipes sont composées d’un Product Owner et de Développeurs.

On peut donc considérer que ces personnes ont une notion de ce qu’est ce rôle vu que c’est la casquette qu’ils portent aujourd’hui.

Cependant, il est assez récurrent de donner des étiquettes aux personnes sans pour autant prendre le temps de bien leur expliquer les contour de cette nouvelle responsabilité. En d’autres termes, cela arrive souvent que cela soit plus du renommage qu’un véritable changement.

De plus, de par les diversité des personnes, il est fortement probable que chacun ait sa propre manière d’appréhender son rôle. Cela dépend bien évidemment du contexte de chacun, des besoins et de la structure de l’équipe.

Il peut donc être intéressant de faire émerger des éléments directement des participants. Cela rendra visible les différences d’interprétation et de mise en oeuvre sur le terrain. Pour cela, on pourra utiliser un Consensus Workshop.

2. Un écosystème non cohérent à la théorie

Scrum se base sur le tryptique : Scrum Master / Product Owner / Développeurs.

Aujourd’hui, l’organisation n’a pas de Scrum Master dédié dans chaque équipe. Les Scrum Masters présents interviennent au niveau de l’organisation, des métiers et s’occupent d’un certain nombre d’équipes ponctuellement.

La structure organisationnelle ne part pas avec les recommandations initiales de Scrum. Ce n’est pas un problème en soi, mais je ne sais pas si les personnes en sont conscientes.

Il m’apparait alors important de rappeler d’où vient ce mode d’organisation et l’intérêt de la structure théorique proposée. En effet, pour en tirer tous les bénéfices, Scrum nécessite quelques pré-requis.

Il est donc fondamental d’avoir connaissance de ces éléments pour pouvoir échanger de manière informée.

3. Des confusions possibles

Il existe aujourd’hui ce qu’ils appellent des « PO Projets » et des « PO Socles ».

De ma compréhension :
– les « PO Projets » pourraient être assimilés à des chefs de projets
– les « PO Socles » sont ceux qui se trouvent dans les équipes

On peut voir ici que l’on utilise déjà le même terme pour désigner 2 choses différentes. Cela ne peut que nourrir la confusion et les interprétations.

On cherchera alors à développer une compréhension commune pour pouvoir distinguer les différentes notions. Je pense qu’il sera donc nécessaire de poser les bases théoriques qui viennent avec le PO. Ce sera une bonne occasion de partager une référence consultable à ce sujet : le scrum guide.

Ici l’important sera de raconter une histoire simple et cohérente afin de clarifier les zones de gris.

4. Un public hétérogène

Les personnes invitées ne seront pas toutes de la DSI. D’ailleurs, elles ne sont pas toutes sensibilisées au rôle de PO en tant que tel.

De plus, cet atelier sera à destination d’opérationnels dans un premier temps. Les résultats seront remontés au comité de direction comme support de conversation par la suite.

Par souci de transversalité et de compréhension partagée, des personnes du métier vont également être conviées. C’est plutôt une bonne chose car le rôle du PO pourrait très bien être de leur côté selon les choix que feront l’organisation. Il faut donc bien prendre en compte l’hétérogénéité de leurs connaissances mais également valoriser leur contribution dans la conversation.

On prendra ainsi bien en compte que les résultats de l’atelier comprendront :

123
Ce que certaines personnes font en tant que PO
(et qui rentre bien dans leur vision du PO)
Ce que certaines personnes font en tant que PO
(et qui pourrait être pris par un autre rôle)
Ce que certaines personnes pensent qu’un PO devrait faire
(et qui n’est pas toujours fait)

De par la culture du Power Point particulièrement bien installée dans l’entreprise, je vais produire un document de synthèse suite à l’atelier pour le comité de direction. L’idée étant non seulement de partager les résultats de l’atelier mais aussi mes observations, quelques orientations ainsi que les questions en suspens.

Structure

Pour définir notre structure d’animation, on prendra également en compte les éléments suivants :

  • Durée : 1h30
  • Nombre de personnes : 14 personnes + facilitateurs
  • Format : Distanciel (Miro)

L’agenda prévisionnel est donc le suivant :

(5′) Introduction
(30′) Partie 1 : Activités du PO (Vision émergent du terrain)
(20′) Partie 2 : Activités du PO (Vision théorique)
(20′) Questions / Réponses
(5′) Clôture

Ainsi au coeur de la démarche, on propose de créer du sens autour du sujet du PO en faisant travailler la matière par les participants. Il ne s’agit donc plus de leur imposer une vérité mais de leur faire avoir la conversation leur permettant de définir quelle vérité leur convient pour répondre à leurs enjeux.

Mon rôle restera cependant de m’assurer de la cohérence d’ensemble et de clarifier les incompréhensions.

Animation

Pour commencer l’atelier, j’accueille l’ensemble des participants en leur partageant le lien vers le support Miro prévu à cet effet. Je partage également mon écran pour faciliter l’animation.

En introduction, comme à mon habitude, je rappelle les intentions de ce moment collectif et affiche l’agenda prévisionnel.

Agenda_PO

Comme vous pouvez le voir, il est légèrement plus précis que celui de la conception. C’est un choix spontané de ma part. En effet, il peut parfois être utile de donner un peu plus de précisions aux participants pour qu’ils puissent mieux se repérer dans l’animation et dans la gestion du temps de l’atelier.

Partie 1 : Consensus Workshop

Nous démarrons alors la partie 1 en sollicitant directement les participants sur leur vision du rôle de PO. Pour cela, ils vont être répartis en sous-groupe afin d’échanger sur leurs idées.

Je crée rapidement des breakout rooms avec un remplissage aléatoire et leur montre l’espace où déposer leurs résultats. Je peux enfin les envoyer en salle où ils auront une bonne dizaine de minutes pour interagir et rendre visibles leurs idées. Bien entendu, je vais passer dans chaque salle pour voir comment les discussions se passent.

Mon rôle ici n’est pas de corriger ou d’apporter mon savoir mais plutôt de faciliter les échanges, de questionner ou d’apporter de nouvelles options à la conversation en cours.

Le temps étant écoulé, nous revenons tous en salle principale pour débriefer. Voici à quoi ressemble alors le contenu de chaque sous-groupe :

Breakouts_PO

Chaque groupe vient tour à tour partager ses idées.

Comme le veut le processus du Consensus Workshop :

  • Nous rassemblons tout d’abord les post-its qui semblent appartenir à une même thématique sous une même colonne.
  • Puis, lorsque toutes les idées ont été déposées, on travaille collectivement à nommer ces thématiques. C’est un des moments forts car ces échanges affinent la compréhension collective du groupe sur le sujet étudié. Il arrive alors que des regroupements ou des séparations de thématiques se produisent.

On en arrive au résultat suivant :

Consensus-Workshop-PO

Pour clôturer cette partie, je formule une phrase à haute voix pour répondre à la question, en reprenant les différentes thématiques. Cela semble résonner au sein du groupe. Encore la preuve que le Consensus Workshop est un outil extrêmement puissant pour la facilitation collective ! 😉

Partie 2 : Théorie

Dans cette section, c’est à mon tour de jouer. Je présente alors une vision théorique du rôle (selon moi) avec le souci de construire une histoire simple et cohérente. Voici ce que je leur ai partagé :

Du chef de projet au Product Owner

Pour comprendre le rôle du Product Owner, il est important de bien appréhender son contexte.

Un ensemble fourni de responsabilités

Dans l’approche Traditionnelle, le Chef de Projet prenait à son compte différentes activités :

ActivitéDétails
People ManagementManagement des personnes, Montée en compétence, Interactions
Process ManagementOrganisation du travail, processus de fonctionnement
ContenuVision, Priorisation voire définition fonctionnelle / technique
Une séparation focalisée des responsabilités

Dans l’approche Agile, tout particulièrement dans le Framework Scrum, ces différentes activités ont été distribuées dans des périmètres de responsabilité bien définis :

ActivitéQui
People ManagementScrum Master
Process ManagementScrum Master
ContenuProduct Owner

On peut alors comprendre pourquoi les chefs de projets ont souvent l’impression d’avoir un chevauchement de responsabilités avec les Product Owners et/ou les Scrum Masters. En fait, c’est tout simplement parce-que c’est le cas 🙂

La séparation marquée de ces 2 responsabilités a pour but d’apporter plus de focalisation dans chacun de ces domaines. En effet, à force de multiplier les casquettes, il devient plus difficile de tout faire correctement.

D’ailleurs, il arrive souvent que la partie humaine soit délaissée au profit de la partie de « production ». La création du Scrum Master est donc une manière de s’assurer que cela n’arrive pas.

La Scrum Team

Le Product Owner est un périmètre de responsabilité évoqué dans Scrum, un des frameworks Agile les plus utilisés. Il se combine avec le Scrum Master et l’équipe de DEV (réalisation) au sein de la Scrum Team.​

Scrum-Team-PO

Scrum s’appuie sur le tryptique de la Scrum Team. Chaque partie a donc un objectif clair et complémentaire.

Pour le PO, on a :

Maximiser la valeur produite par l’équipe de réalisation

– Objectif du PO

​Aujourd’hui, le tryptique de la Scrum Team dans l’entreprise ressemble plutôt à cela (voir ci-dessous) : il n’y a pas de Scrum Master dédié, intégré à une équipe.​

C’est plutôt une équipe de Scrum Masters / Facilitateurs qui se répartit l’accompagnement des différentes équipes. La contrainte étant bien évidemment qu’il y a moins de capacité à faire que de choses à faire ! 😉

Scrum-Master

Cela peut alors engendrer un flou dans les activités du Product Owner qui peut parfois prendre des actions initialement dédiées au Scrum Master / Facilitateur.

Product Owner comme interface

On peut considérer le Product Owner comme l’interface entre l’espace du Besoin et l’espace de la Solution

Interface-PO

On voit alors ici la Scrum team avec l’équipe de Réalisation et le Scrum Master représentant l’espace de la solution. De l’autre côté, dans l’espace du besoin se retrouvent les référents Métier, les utilisateurs mais également la couche managériale qui peut parfois sponsoriser le produit en question.

Le Product Owner agit donc ici comme l’interface entre ces 2 espaces en ayant une attention toute particulière sur l’affinage du besoin (d’où son décalage de ce côté). En effet, l’idée est de laisser la liberté suffisante à l’équipe de Réalisation pour proposer les meilleurs solutions.

C’est toujours la grande difficulté de réussir à communiquer un besoin plutôt qu’une solution !

Pendant ce temps, le Product Owner peut interagir avec ses interlocuteur pour éclaircir les besoins, clarifier les priorités et planifier stratégiquement le développement de son produit.

Les activités du Product Owner

Ainsi, les activités et responsabilités du Product Owner, comme définies dans le Scrum Guide peuvent se résumer à :

activites-PO

On y retrouve alors :

Garantir la
vision du Produit
Assurer la 
transparence du Product Backlog
Maintenir le 
Product Backlog ordonnancé

Note : je trouve d’ailleurs que le terme « Ordonnancer » est souvent plus explicite que le terme « Prioriser« . En effet, d’un côté on a bien une notion d’ordre, impliquant qu’aucun élément ne sera au même niveau qu’un autre. Alors que de l’autre, on a tous déjà vu des éléments de travail avec les mêmes niveaux de priorité ! 😛

Remarques supplémentaires

  • Les éléments ci-dessus peuvent être délégués mais la responsabilité principale reste chez le PO.​
  • Un seul PO, pas un comité. Il peut cependant être le représentant des besoins de différentes parties prenantes​.
  • Le PO doit avoir le mandat pour prendre des décisions, lesquelles doivent être respectées par l’organisation​.
  • Le PB ne peut être modifié qu’après voir eu l’accord du PO.
  • Le guide Scrum ne précise pas les activités du PO en amont de la phase de réalisation, malgré le fait qu’elles soient bien existantes​.

Questions / Réponses

La séance de questions/réponses ne sera pas très longue étant donné le temps qui nous reste pour l’atelier.

Cependant, la confrontation de la théorie à la vision du terrain semble avoir éclairci un certain nombre de zones d’ombres sur le sujet. Les participants quittent l’atelier avec une humeur plutôt positive et semblent satisfaits de ce qui a été produit collectivement.

J’en profite pour préciser les prochaines étapes pour donner de la visibilité. En effet, une session sera organisée avec le comité de direction pour étudier ces résultats et répondre aux questions en suspens. Puis un atelier de consolidation tous ensemble permettra de finaliser la structure du rôle de PO pour sa première version.

Synthèse

Synthèse

Comme évoqué en début d’article, j’ai travaillé sur un support de synthèse à destination du comité de direction. Pour être honnête, je n’ai jamais été très bon pour ce genre d’exercice mais au moins, les éléments ont pu être posés.

En voici quelques éléments :

Activités du Product Owner

Réponse co-construite par les participants en 1h30 :

activites_po_emergentes

Comparaison des 2 visions

J’ai tenté ici de regrouper les idées qui convergeaient dans les 2 visions du rôle de PO. Voici le résultat que j’ai partagé :

Vision émergenteVision théorique
Piloter / Gérer le contenu
Mesurer les opportunités
Valider le produit / la réalisation
Animer une équipe
Garantir la vision du produit
Maintenir le Product Backlog ordonnancé
Communiquer sur la valeur
Alimenter / détailler le besoin
Assurer la transparence du Product Backlog
Manager une équipe?

Cela a alors permis de mettre en lumière une thématique qui se retrouvait sans correspondance : « Manager une équipe ».

C’est ce que je vais creuser par la suite.

Thématique : Manager une équipe

Pour mieux comprendre ce qui se cache derrière, voici les activités qui y étaient regroupées :

Manager l’équipe de réalisationÊtre proxy managerRecrutement et suivi des partenairesGestion des formations Participer aux entretiens annuels des coéquipes internes

Cela m’a donc amené à poser les questions suivantes :

1Est-ce que cette activité doit faire partie des responsabilités du PO dans votre entreprise ?
2Est-ce au PO de gérer les formations de ses coéquipiers ?
3Que signifierait « Manager l’équipe de réalisation » dans ce cas ?

Orientations

Voici ci-dessous les orientations partagées pour ce sujet :

1L’objectif initial du rôle de PO est de rester focalisé sur le contenu à produire, de donner du sens et d’éventuels détails sur les éléments de travail.
2L’activité « managériale » comme évoquée ici est donc une activité supplémentaire au rôle de PO qui pourrait être prise par un manager extérieur à l’équipe voire par un Scrum Master, faisant le lien avec l’organisation.
3Il y a ici un chevauchement entre les activités du PO et du SM qui peuvent tous deux « suivre des tickets« , « synchroniser les teams« , « donner du sens » mais chacun avec leur focale : le PO axé sur le contenu et le SM sur l’organisation et les interactions.

Ces éléments n’ont pas vocation à être la « vérité » mais cela permet de contribuer à la réflexion avec un point de vue argumenté.

Questions générales

Enfin, pour conclure, j’invite le comité de direction à réfléchir plus précisément aux questions suivantes :

1Quelles sont les activités « essentielles/obligatoires » du rôle de PO ?
2Quelles sont les activités « non obligatoire » du rôle de PO ?
3Quelles sont les activités « hors périmètre » du rôle de PO ?
4Quelles sont les activités des facilitateurs / Scrum Masters dans l’écosystème ?

Notes :

  • En effet, il est important de prendre en compte l’écosystème autour du PO pour bien définir son périmètre de responsabilité (au sens accountability)
  • Il y a également la dimension interne / externe à prendre en compte dans les réflexions car selon le statut, les droits et devoirs peuvent différer.

Conclusion

Cet article était l’occasion de décrire une démarche alternative à la démarche de formation habituelle. En effet, pour éviter les débats d’experts et les conflits inutiles, c’est une approche qui me semble favoriser le travail collectif par la co-construction de sens.

Notre rôle dans ce genre d’atelier n’est donc plus d’apporter la vérité mais de faciliter l’appropriation de la matière par les participants. Cela semble amener à un résultat plus adapté au contexte à un instant t car plus engageant et sollicitant davantage la curiosité.

Cependant, l’hypothèse de départ est l’acceptation d’un résultat imparfait, affiné en itérations successives par la suite : vous avez dit Agile ? 🙂

En espérant que cet article aura pu vous ouvrir quelques perspectives, n’hésitez pas à tester cela dans vos contextes et à me partager vos apprentissages ! 🙂

Partager

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur pinterest
Partager sur email
Partager sur whatsapp
Olivier MY

Olivier MY

Issu d'un cursus ingénieur, je me suis vite rendu compte que mes appétences et compétences tournaient plus autour de l'humain que de la technique. Je suis alors devenu Coach Agile et Coach Professionnel car j'ai toujours voulu contribuer à rendre le monde meilleur. J'accompagne aujourd'hui des individus, des équipes et des organisations vers une meilleure compréhension d'eux-mêmes afin de bâtir ensemble le futur qui leur correspond.

Commentaires

2 réflexions sur “Atelier de réflexion autour du rôle de PO”

  1. Gerard Grandchamp

    Bonjour Olivier,
    La transition de rôles existants (notamment « chef de projet ») au rôle de PO n’est effectivement pas évidente. Dans ton contexte, il s’agissait d’un atelier portant sur le rôle du PO en interne à une organisation (client interne), ce qui est moins facile que lorsque le PO établit l’interface avec un client externe.
    A ce titre, il pourrait être intéressant d’utiliser aussi le triptyque « Desirability » (=> Besoin client) / « Sustainability » (=> Impact business) / « Feasibility », sachant que le PO devra s’intéresser au 2 1er aspects, ce qui représentent une charge de travail importante et pourrait / devrait l’amener à réduire ses activités sur d’autres aspects qui ne rentre plus/pas dans son périmètre (tels que la gestion d’équipe, le gestion des obstacles…). Il semble qu’un des aspects clefs soit d’aider les leaders des projets à évoluer de leur rôle existants vers un rôle agile (PO ou SM). Bien cordialement,

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles récents

Safety

Rétrospective et Sécurité Psychologique

Pour permettre à une équipe de performer, un critère essentiel aujourd’hui bien connu est la sécurité psychologique. La problématique derrière cette notion est qu’elle n’est …

LIRE PLUS
communaute

Lancement d’une communauté transverse

Les communautés professionnelles ont la côte en ce moment. Et pour cause, elles peuvent avoir un impact considérable au sein d’une organisation. Cependant, il n’est …

LIRE PLUS
BYI - Episode 3

Inspirer en 7 mn – l’expérience Boost Your Inspiration

En Décembre dernier, j’ai eu l’honneur d’être invité à participer au 3ème épisode de Boost Your Inspiration. Le challenge ? Partager et inspirer autour d’un …

LIRE PLUS
BYI - Episode 3 - OMY

Écouter ou l’art de prêter attention

Voici le script de mon talk de 7 minutes intitulé « Écouter ou l’art de prêter attention » pour le 3ème épisode de Boost Your Inspiration. J’ai …

LIRE PLUS
teamwork-skills

Matrice de compétence d’équipe

Pour avoir plus de clarté sur la composition de notre équipe, l’utilisation d’une Matrice de Compétence d’équipe peut être particulièrement intéressante. La version proposée par …

LIRE PLUS
Thalassagile

Thalass’Agile : une expérience réflexive hors du commun

Il y a des périodes où l’on a besoin de prendre du temps pour soi. Pour faire acte de ce que l’on a vécu, prendre …

LIRE PLUS
Retour haut de page

Confidentialité et cookies : ce site utilise des cookies. En continuant à naviguer sur ce site, vous acceptez que nous en utilisions. Pour en savoir plus, y compris sur la façon de contrôler les cookies, reportez-vous à ce qui suit : Politique relative aux cookies.

Prenons contact