Le Proxy PO c'est quoi ? Proxy Product Owner - Scrum Life 77
Вставка
- Опубліковано 2 лип 2024
- 🎁 Le guide du Scrum Master compétent 👉 sl.run/uHFnzV
Que faire lorsque le Product Owner n'est pas assez disponible ? Est-ce que c'est le Proxy PO la solution ? D'ailleurs c'est quoi le Proxy PO ? #scrum #productowner #proxypo
💜️ La communauté Scrum Life 👉 sl.run/nro4KK
----------
LIENS EN RAPPORT AVEC CETTE VIDÉO
► Article de Constantin sur le Proxy PO "Que se passe-t-il avec un PO qui n’est qu’un passe-plat ?" : const.fr/blog/agile/po-passe-...
► Retour d'expérience sur le rôle de PO par Nathalie Keo dans Scrum Life 61 : • Le rôle du Product Own...
► Product Owner et Product Manager, quelle différence ? Scrum Life 28 : • Product Owner (PO) et ...
----------
SOMMAIRE️
0:00 Ouverture
0:24 Exemple du problème
1:17 Qu'est-ce que le rôle de Proxy Product Owner ?
5:21 Un membre de l'équipe de développement à part entière ?
6:36 Est-ce un signe de mauvais augure ?
9:05 Un rôle temporaire utile dans une transformation ?
11:10 Le Proxy PO, parfois un vrai PO sans le titre ?
Découvrez toute la communauté Scrum Life ! 👉 sl.run/gILr3V
Merci pour cette video :)
Vraiment, je n'ai eu qu'accès à ce rôle dans l'ESN dans laquelle j'étais... (mission dans le secteur public au forfait, the worst)
Dans le meilleur des cas, comme tu le dis à la fin, le PO devient une partie prenante et on peut avoir une vraie ampleur PO sans le titre.
Dans le pire des cas, on nous supprime la partie proprisation et prise de décision et là, on devient un acteur de plus. Ce qui va à l'encontre du SCRUM GUIDE qui préconise un seul et unique PO.
Je trouve que bien souvent dans le cadre du passage en agile et surtout sur scrum, on oublie bien souvent l'importance de transformer l'organisation en amont pour que tous les acteurs puissent avoir leur place et connaître les tenants, les aboutissants de ceux-ci...
C'est bien dommage
Merci beaucoup Emilie pour ce partage, même s'il n'est pas très gai !
Mon entreprise y a recours ponctuellement. Un exemple récent : l’agilité est méconnue par les parties prenantes, ils veulent l’adopter car perçoivent qu’ils vont pouvoir utiliser la solution plus rapidement qu’avec un cycle en V. Ils nomment parmi les experts un PO mais celui ci n’est pas a l’aise avec cette casquette, notamment la responsabilité de prioriser le backlog y compris sur des domaines pour lequel il n’a pas l’expertise. In fine, le PO et le PPO sont dans l’équipe a temps plein, ils codeveloppent la solution et le PO apprends les pratiques agiles grâce au PPO.
Super vidéo, merci beaucoup et quel talent pour le déguisement 👸!
Merci d'abord pour ces vidéo qui est très clair et très intéressant! Est ce que vous pouvez faire une série de vidéo qui parle du rôle de " business Analyste" au sein d'un projet Agile Scrum?
En vrai, dire a un client "vous êtes stakeholder" est pas assez valorisant pour lui. La parade, dite lui : "vous êtes PO" chez vous, mais on vous met un PPO dans l'équipe scrum ^^.
Je suis d'accord avec la dernière partie, dans certains contextes PPO est très souvent le PO pur et dur d'une entreprise.
Seulement, certaines entreprises donnent le rôle de PO à des personnes "métier" ou des "clients" sans aucun mindset Agile et Scrum et même pas dans l'équipe Scrum (autre site, autre fonction).
Du coup, ils sont en réalité des Stakeholders, mais pour moi c'est juste une manière de flatter les ego des faux "PO", qui sont en faite des "metier/client".
Il est faux de dire de toute façon que le PO priorise seul en Scrum, il en a l'entière responsabilité, mais il prend en compte toutes les remontées client/métier/user des stakeholders.
Très très bonne vidéo sur le PO et le PPO. Je vous félicite pour la qualité du contenu.
Avec plaisir ! Merci des compliments.
On m'a appelée pour un poste de PPO, j'ai regardé cette vidéo, puis réussit à trouver dans mon réseau quelqu'un qui travaille dans cette équipe pour me dire plus de choses en off. Pour ainsi dire, c'est exactement tous les mauvais côtés dont vous parlez : un PO qui est très proche du métier, qui fait beaucoup de politique, de courbettes, mais ne comprend rien à l'IT, qui cherche quelqu'un a qui déléguer toutes ses tâches dès que ça parle un peu trop près d'un ordinateur, d'un modèle ou d'une architecture.
Et le PPO recherché a un peu les pieds et mains liées, restent toujours dans la "transition temporaire" où on va piocher ce qu'on aime bien dans les méthodes agiles (rapidité de mise en production, standup meeting) tout en gardant tous les mauvais côtés de cette méthode + celles des méthodes classiques. Bref, pour l'instant je bannis un peu toutes ces offres ingrates...
Très intéressant merci. Dans les grandes DSI, je rencontre souvent ce rôle, sans être assumé. Le "vrai" PO est dans l'entité "métier", mais n'assume pas le rôle de PO (il n'en a même pas le titre d'ailleurs). Le "PO" coté DSI est en réalité un Proxy PO ( et pourtant il a le titre ). Evidemment ce fonctionnement n'est pas idéal mais les silos métiers/DSI ont du mal à sauter dans ces organisations :-(
Tristement trop courant... On essaie de se battre contre ça ! Méfiez-vous des coach qui vous disent que c'est "OK"
Super vidéo comme d'habitude.
J'ai l'impression que ta définition du proxy PO se rapproche du Business Analyst... Je reconnais beaucoup de choses qui se passent dans mon équipe. Et je reconnais aussi ce que tu dis sur le fait que le faux PO est en fait un stakeholder !
Quel est ton avis sur cela, et sur l’intérêt même du BA en Scrum ?
Salut, le "vrai" rôle de Business Analyst a toute sa place au sein de l'équipe de développement Scrum -- si tant est que le domaine fonctionnel est suffisamment complexe pour en justifier la présence, bien entendu.
Je précise "vrai" rôle car il reste bien distinct du rôle de Product Owner ou de Proxy Product Owner : il n'est pas question de rédiger/spécifier les US à la place du PO. (si tant est que cela soit le rôle du PO... !) Il peut par contre avoir toute une expertise métier très poussée et très spécifique qui complètera à merveille les autres expertises de l'équipe de développement.
Vidéo très pertinente pour sujet pourtant trop peu abordé.. merci ! Il me reste une interrogation concernant la possibilité de rendre "scalable" me fonctionne de PO. Je comprends mal comment se passer de PPO lorsque plusieurs scrum teams délivrent pour un unique produit assez complexe. Par exemple, ces différentes équipes vont potentiellement avoir leur rituels en même temps, et avoir besoin de précisions/trancher sur des sujets très différents. Avoir des PPO qui portent certains épics en se les répartissant, cela ne peut il pas mieux fonctionner que d'avoir une seule personne désignée pour assumer le rôle a se partager entre toutes ces équipes ?
Oui, c'est un peu l'organisation que j'ai mis en place. Un PO du produit et plusieurs équipes travaillent sur ce produit. Dans chaque équipe, il y a un PPO (on les appelle Business Analyst) qui est là pour rédiger les stories mais c'est bien le PO qui gère l'ordonnancement (en communiquant avec le PPO bien sûr).
Exact. Le poste de PPO est peut-être en soi une aberration simple.
C'est rigolos car nous avvons la même situation dans notre departement ! Mais de toute façon on fait semblant ! Puisqu'on a pas eu la formation adéquat car personne ne veut payé pour ça alors que la banque mondiale veut qu'on soit agile on a regardé quelques video et pi c tout ! Et on essaie de dire des buzz word lors des reunions pour qu'ils pensent qu'on est agile alors qu'en faite non ! Ha ha ha ha ha! Le PPO est apparu parsqu'on a vue qu'il faut un PO en scrum et un scrum master et des dev ! Le PO ne vient pas des metier il est un employé du departement et on l'a forcé a le faire !
Aïe ! Mais la situation n'est pas une fatalité. Que pourriez-vous mettre en place à votre niveau qui améliorerait les choses ? Quelle petite action améliorerait un tout petit peu les choses ?
-- JP
@@ScrumLife je croix que cela s'améliorera si la BM voulait bien engager des coachs agile mais je croit qu'il font exprès pour que tous le monde se plante pour que le financement arrive toujours et encore !!! Je les ai entendue dire qu'il faut deux jour d'apprentissage et passer les examens pour êtres certifié, je croix qu'ils ont mal interpréter les 35 heures de contact d'enseiggnement (les fameux PDU) qu'il faut pour pouvoir passer le PMP du PMI !!