Dans le cadre de notre trajectoire de mise en place de l’Agilité à l’échelle depuis 1an, je me rend compte en tant que Scrum Master, que pour le moment les rôles de PM/PO ne sont pas correctement maîtrisés et nous avons les irritants suivants :
Les features sont créées par les PO et non pas par le PM ;
Les stories sont créées par l’équipe de DEV et non pas par les PO ;
Les PO ne font pas de revue de backlog et ne gère pas leur backlog de stories ;
Depuis le passage à l’échelle, les PO ne donnent plus d’objectif de sprint en sprint planning ;
Comment pouvons-nous revenir à de bonnes pratiques et sensibiliser les acteurs sur ces irritants.
Si j’étais un peu coquin, je diras : on a l’impression qu’en fait l’organisation est assez saine, le seul problème c’est qu’on a nommé des gens « PO » mais qui en pratiques ne servent pas à grand chose, le rôle de PO (au sens Scrum) étant assumé par le PM.
Aussi, as-tu vu nos vidéos sur les rôles PO vs PM ainsi que sur celui de Proxy PO ? Ils pourraient t’apporter des éléments de réponse, ou du moins détailler / expliciter mon paragraphe précédent.
P.S. : wow, ça fait beaucoup de vignettes de JP Lambert !!!
Les features sont créées par les PO et non pas par le PM ;
C’est vrai, les POs sont souvent plus proche du besoin, et font les features. Mais ils ne sont pas seuls, ils le font avec l’aval est le support des Epics Owner et l’accord du PM.
Sans compter que le RTE doit veiller à ce que l’on se concentre sur ce qui apporte le plus de valeur.
Les stories sont créées par l’équipe de DEV et non pas par les PO ;
Oui, si elles ont été créé en avance, elles sont revues en PI planning sinon elles sont créées durant le PI planning. Et souvent suite à cette définition le score de la feature peut être modifié;
Tout n’est que négociation.
Les PO ne font pas de revue de backlog et ne gère pas leur backlog de stories ;
Euh, ça c’est très étrange…
Depuis le passage à l’échelle, les PO ne donnent plus d’objectif de sprint en sprint planning
Il faut essayer de comprendre pourquoi. Sinon peut être que le Scrum master doit être aider, supporter par le RTE.
C’est au fond pas une question bête parce qu’il y a beaucoup de confusion chez beaucoup de gens sur le sujet.
Feature (trad: fonctionnalité) : On appelle communément une fonctionnalité d’un logiciel ou d’un produit une « feature ». C’est une implémentation, une capacité, et elle a donc déjà fait l’objet d’une définition et d’un raffinage.
(User) Story (trad: récit ?): C’est un pense bête tenant en une phrase, proposé par l’utilisateur.ice ou son .sa représentant.e (!!! le PO n’est PAS le représentant des utilisateurs !!!) et amenant l’équipe à une discussion avec le ou la dite représentante/utilisatrice. Le toute permettant à l’équipe de définir une feature potentiellement développable.
Il semblerait qu’il y ait une confusion entre les rôle de PMs et de PO :
Les PM sont responsables de toutes les étapes du cycle de vie du produit. Les PO, eux, sont uniquement responsables de la partie Delivery.
Pourtant, il ne faut pas sous-entendre que les Product Owners sont simplement une fraction de PM : ils endossent une responsabilité différente, et les deux positions peuvent s’avérer complémentaires.
Grâce à leur dimension plus stratégique, les Product Managers tendent à répondre plutôt au “Why”, tandis que les Product Owners, en communication directe avec les développeurs, répondent au “What”.
L’idéal pour pour revenir à de bonnes pratiques et rétablir les missions propres à chaque métier serait de proposer à votre entreprise de vous former par le biais de formation Product. Il en existe des dédiées au Product Management, comme Professional Scrum Product Owner (PSPO) ou SAFe cependant elles restent très théoriques, et 100% dédiées aux méthodes agiles. Ces formations, en plus d’être onéreuses, sont très courtes et très incomplètes.
Attention aux formations de PM gratuites que vous retrouverez en ligne : celles-ci ne sont pas certifiantes et peu reconnues par les recruteurs.
Pour acquérir les bonnes pratiques et compétences des métiers de Product Manager comme Product Owner, je pense que Noé (http://noe.pm) pourrait vous aider : elle forme à toutes les dimensions de ces deux métiers et de la gestion de produits en 4 semaines de bootcamp intensif. Le matin vous apprenez la théorie et l’après-midi vous l’appliquez par groupe à la problématique réelle d’un des sponsors BlaBlaCar, Doctolib et Getaround. Ca vous permettrait de mieux comprendre le rôle de chacun tout au long du cycle produit.
À nouveau, je ressens toutefois une confusion entre rôle et métier.
Le rôle est le nom pour un ensemble générique (normalisé) de responsabilités pour un contexte organisationnel (ITIL, Scrum, SAFe, Management, TOGAF, XP, COBIT, …).
“Générique (normalisé)” parce que sur le terrain, on va adapter ces responsabilités, sachant que toute « personnalisation »/« adaptation » devrait être clairement discutée, annoncée, affichée, documentée puisqu’on s’écarte de la « norme » (pour de bonnes raisons ? En tout cas pour des raisons qui mèneront à une remise en question régulière de ces adaptations lors des inspections).
« Responsabilité » avec cette ambiguïté à prendre en compte entre le français et l’anglais, mais on parle bien de tout ce qui est RACI/RMscI/RASCISS, etc.
Et le métier ? Le métier représente un autre ensemble générique, mais de « compétences » (et non de responsabilités).
La fonction, c’est mon « rôle » vis-à-vis du contexte de l’entreprise. Que ce soit ma fonction dans l’entreprise, ou bien mon rôle dans la gestion de « quelque chose » (un projet ? un produit ? une chaîne de valeur ? une équipe ? un service ? une ressource ? un parc informatique, …), j’aurais besoin de compétences. Certains « métiers » correspondent bien à certains rôles. Mais nommer un « métier » par le « rôle » auquel il prédestine est une des pires calamités dans nos organisations. Cela sclérose tout. Cela empêche l’adaptation rapide de l’organisation d’une de ces gestions.
