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 :

1	2	3
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.

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 :

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 :

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 Management	Management des personnes, Montée en compétence, Interactions
Process Management	Organisation du travail, processus de fonctionnement
Contenu	Vision, 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 Management	Scrum Master
Process Management	Scrum Master
Contenu	Product 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 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 ! 😉

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

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 à :

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

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 :

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é :

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 manager

Recrutement et suivi des partenaires

Gestion des formations

Participer aux entretiens annuels des coéquipes internes

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

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

Orientations

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

1	L’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.
2	L’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.
3	Il 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 :

1	Quelles sont les activités « essentielles/obligatoires » du rôle de PO ?
2	Quelles sont les activités « non obligatoire » du rôle de PO ?
3	Quelles sont les activités « hors périmètre » du rôle de PO ?
4	Quelles 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 ! 🙂