Question d'entretien d'embauche de Product Owner : sont-ils vraiment agile ?

[@ScrumLife]

T'as pensé quoi de ce format ? À continuer ?

[@Cedoch]

C’est la même chose 😅

[@alkariane]

- Court, mais pas trop. - Clair et focus Moi j'approuve !

[@yasminamika6451]

Trés intéressant et utile pour mes futurs entretiens de chef de Projet ou de Product Owner et de savoir quelles sont les fonctions occupés dans l entreprise

[@AmorAguilera]

Yes ! Absolument, c'est intéressant de pouvoir réfléchir aux réponses un peu plus terre à terre en sortant du cadre (Scrum,SAFe,...)

[@rochdiliverpool]

Très bon format, très instructif et intéressant!

[@unpeudebonsens]

Comme dab, plein de bon sens par rapport à l'agilité, au Product et Team management :D

[@ScrumLife]

Merci beaucoup @unpeudebonsens ! 🙏 On essaie vraiment de vulgariser au maximum ces concepts pour les rendre accessibles à tous. Ça me fait super plaisir que tu apprécies nos vidéos. Est-ce qu'il y a un sujet en particulier sur l'agilité ou le management d'équipe dont tu aimerais qu'on parle dans une prochaine vidéo ? Tes suggestions nous sont toujours précieuses ! 👌🚀 Robin

[@Abdelkarim-ou3hw]

Super vidéo vraiment.J’avais une def de ce que pourrait être l’agilité,je les vue sur le forum scrum life donc elle ne vient pas de moi je tenais à le préciser : L’agilité,c’est la capacité à changer de direction chaque fois qu’on fait le point sur la où on en est et sur l’état de nos resources pour Toujour se reprocher de l’objectif.

[@ScrumLife]

Merci Abdelkarim pour ton retour élogieux ! 🙏 C’est une très belle définition que tu partages là. En effet, savoir ajuster sa direction en fonction des points de situation et des ressources disponibles est un aspect fondamental de l’agilité. 🚀 D'ailleurs, quelle approche agile préfères-tu intégrer dans ton travail : Scrum, Kanban ou une autre ? C’est toujours enrichissant de connaître les expériences et perspectives des autres pratiquants. Au plaisir de te lire et merci encore pour ton engagement ! 😊 Robin

[@spip931]

On peut dire que vous faites cette vidéo à point nommé 😍 J'ai passé mes certifs scrum il y a un mois et j'envisage sérieusement de changer de poste et de boite pour devenir PO justement. Donc autant dire que cette vidéo me sera utile, en tout cas, plus que les autres. Donc un très très grand merci 🙏🙏👍

[@ScrumLife]

Bravo pour tes certifs Scrum, @spip931! 🎉 Te connaissant, ça fait plaisir de voir ta motivation pour plonger dans le rôle de PO. Ravi que cette vidéo tombe pile/poil au bon moment pour toi ! Tu aimerai une seconde vidéo sur des questions posées en entretien ? T'as peut etre des questions que tu aimerais qu'on aborde ! Et merci mille fois pour ton commentaire. 👍💪 Robin

[@spip931]

Merci Robin. C'est en partie grâce à vous @@ScrumLife , vos vidéos et votre forum si j'y suis arrivé (juste un exemple : les vidéos que vous avez faites entre juillet et aout avec des questions posées lors des examens de certifications😉) Et, pour répondre à ta question, oui, ça m'intéresse ce genre de format et d'ailleurs, j'ai quelques questions qu'un recruteur pourrait poser en entretien d'embauche (j'espère que je ne donne pas le baton pour me faire battre 😆😛) : 1. "En fait, il y a une coquille dans l'offre d'emploi : le poste à pourvoir n'est pas un poste de 'Product Owner', mais un poste de "Proxy PO" (ou "Product Manager"). Qu'en pensez-vous ?" 2. "La personne précédente à ce poste [de product owner] avait constitué un product backlog et travaillait avec plusieurs parties prenantes. Si vous commencez demain, que feriez-vous (avec le Product Backlog et les parties prenantes) ?" Sous entendu "Est-ce que vous repartez de 0 au niveau du Product Backlog et/ou des parties prenantes, ou est-ce que vous prenez la suite (avec le même Product Backlog et/ou parties prenantes) ?" 3. "Si demain, au lieu d'une seule équipe qui travaille sur le produit, il y a 2 ou 3 équipes, que faites-vous en tant que PO ? Autrement dit, est-ce que le poste de PO vous intéresse (toujours) si au lieu de travailler avec une seule équipe, vous travaillez avec 2 ou 3 équipes ?" 4. "Demain, on passe de Scrum à SAFe, ou de Scrum à Kanban, ou de Scrum à Prince 2, ou inversement. Que faites-vous en tant que PO ?" 5. "Vous avez travaillé à un autre poste et/ou dans un tout autre secteur d'activité. Quelles seront vos premières actions/décisions en tant que PO ?" 6. "Mise en situation : vous êtes en conflit avec un des membres de l'équipe de dev ou avec une partie prenantes. Que faites-vous ?" 7. "(Je suis) votre N+1 et (je) vous demande à vous, PO, des rapports/des graph sur la vélocité de l'équipe. Que faites-vous ? Que me répondez-vous ?" Enfin, j'ai une autre question (qui pourrait être posée en entretien d'embauche si tant est qu'on se soit au préalable renseigné sur l'entreprise et sur le produit qu'elle développe) : Peut-on, dès le début, en tant que PO, avoir un product goal, voire une vision du produit ? Si oui, est-ce qu'on peut les résumer (le product goal et/ou la vision produit) en quelques minutes et pendant un entretien d'embauche ? Si non, au bout de combien de temps peut-on l'(es) avoir ? D'ailleurs, est-ce qu'un product goal et/ou cette vision sont susceptibles d'évoluer avec le temps (normalement et selon moi, oui, dans un contexte agile) ou est-ce qu'ils doivent être fixes (ou du moins varier le moins possible) ? Par ailleurs, pas grand-chose à voir avec ce qui précède, est-ce que demain, jeudi 9 mai, vous faites un live ou pas ? Ou est-ce que vous le reportez à vendredi ? Merci pour vos réponses 😉

[@spip931]

@@ScrumLife Autres questions : Imaginons que pendant l'entretien d'embauche, je m'aperçois que (sciemment ou non) il y a confusion de la part de mon/mes interlocuteurs entre les postes/rôles de "Product Owner" et "Product manager", ou réciproquement. Que dois-je faire selon vous ? Est-ce que je leur dis, plus ou moins frontalement, qu'il y a confusion (si c'est fait sciemment pour voir ma réaction ça sera bien vu) ou est-ce que, au contraire, je vais dans leur sens (leur montrant ainsi que je sais m'adapter) (là, pour le coup, si la confusion est faite sciemment, ça sera mal vu car ça peut vouloir dire que je ne sais pas, moi-même, faire la différence entre les 2 rôles/postes et/ou que je ne connais pas bien Scrum) ? Ce que je verrai bien en entretien d'embauche c'est un ou deux tests : Test 1 : Le recruteur présente une liste de 5-8 US - Taches et le candidat doit 1) ordonner, prioriser le Product Backlog et 2) expliquer/argumenter sur cette priorisation Test 2 : Le recruteur présente un product goal et demande au candidat de rédiger 4-5 User Stories

[@tapuopeiluj]

Pour moi, l'agilité c'est d'abord une intuition et une fluidité qui rend la vie/les choses faciles, compréhensibles et acceptées/consenties. Et donc appliquée au PO, j'axerai pas la définition sur "collecter des feedback pour les utiliser le plus tôt" mais sur la deuxième partie de votre phrase à savoir la valeur : l'agilité c'est travailler sur des choses/fonctionnalités/produits/services qui ont du sens, de la valeur, qui servent à quelque chose, qui répondent à un vrai besoin et qui sont utilisées avec le + de consentement & d'acceptation possible. Appliquée aux frameworks type Scrum, ça correspond bien à une des valeurs du manifeste agile (qui mentionne effectivement la rapidité & la régularité des livraisons) : "Les individus & les interactions plus que les processus & les outils". Pour moi cette valeur elle est cardinale dans la manière de penser l'agilité.

[@ScrumLife]

Merci pour ton commentaire @tapuopeiluj, tu as parfaitement saisi l'essence de l'agilité ! 🙌 C'est vrai que l'intuition et la fluidité sont souvent sous-estimées, alors qu'elles jouent un rôle crucial dans la réussite de tout projet agile. L'essence même du Manifeste Agile, avec sa priorité aux individus et aux interactions, met en lumière cette flexibilité et cette humanité que tu décris si bien. Ton point de vue sur la valeur est également très pertinent. Travailler sur des produits et services qui ont du sens et qui répondent à de vrais besoins est effectivement central. Peut-être que cette dimension est souvent occultée par la pression des deadlines et la quête incessante de feedbacks. Ça me donne une idée, pourquoi ne pas consacrer une prochaine vidéo à cette notion de "valeur réelle" et comment elle guide notre démarche agile au quotidien ? Qu'en penses-tu ? Hâte de te lire, et merci encore pour ton insight précieux ! 😊 Robin de Scrum Life

[@fbuiphuong61]

En ce qui concerne la dette technique, il y a 2 risques à gérer et à mettre dans la balance face à la valeur et au ROI du produit quand on est PO et qu'on veut prioriser : le risque élevé de bug/anomalie/dysfonctionnement comme vous l'avez mentionné et aussi l'AUGMENTATION DU TEMPS DE CYCLE et du TEMPS DE TRAVERSEE (vrai en particulier sur un projet légacy, pas sur un green field, les 6 premiers mois). Parce que plus la dette technique augmente, plus le code spagetti, impossible à déméler et mal conçu, grossi et se répend à toute la codebase, et plus il faudra du temps pour le faire évoluer, le corriger et tout simplement le comprendre pour gérer ses dépendances et intégrer y d'autres (nouvelles) parties de code. Ce n'est qu'une question de coût : est-ce que ça coute moins cher de le laisser en l'état même si chaque développement plus ou moins lié prend beaucoup plus de temps et ralenti tout le monde, ou bien est-ce que le moins cher c'est de donner un coup de pied dans la fourmilière et de le refaire/refactorer ? Et c'est à l'équipe (autonome et responsable !^^) d'évaluer chacune des solutions de prendre cette décision comme vous dites pour le mieux dans un climat de confiance .... parce que plus le temps passe et plus le temps de cycle augmente (c'est exponnentiel, le temps double au bout d'une année !). Plus on le refait tôt, moins c'est cher et moins le coût pèse sur les prochaines itérations. Voila comment un PO digne de ce nom doit le gérer .... et le défendre pour son équipe.

[@ScrumLife]

Salut @fbuiphuong61 ! Tu as parfaitement résumé le dilemme auquel sont confrontés les Product Owners lorsqu'ils doivent jongler avec la dette technique. D'ailleurs as-tu vu notre vidéo sur le cout du délai ? Si "non", je pense qu'elle te plaira et que tu te reconnaitras dedans ! L'importance d'une équipe autonome et responsable ne peut être sous-estimée. Comme tu le dis, il faut évaluer les coûts à court et long terme et décider si un refactoring est la meilleure solution. La transparence et la confiance au sein de l'équipe sont essentielles pour prendre ces décisions critiques. Merci pour ton analyse approfondie, c'est exactement ce genre de réflexion qui permet de mieux comprendre les enjeux d'un bon Product Owner. À bientôt et n'hésite pas à partager d'autres réflexions ou questions ! 🚀 Robin

[@ScrumLife]

Salut @fbuiphuong61, Merci pour ton commentaire très détaillé et pertinent ! 🙌 Tu as parfaitement mis le doigt sur une problématique cruciale en gestion de produit : la dette technique. Tu soulignes bien l'impact de cette dette non seulement sur la qualité du produit, mais aussi sur les temps de cycle et de traversée, des éléments souvent sous-estimés. Effectivement, comme tu le dis, la dette technique peut devenir coûteuse à long terme si elle n'est pas gérée proactivement. En tant que PO, il est vital d'évaluer constamment cet équilibre entre valeur immédiate et coûts à long terme. La clé, c'est de maintenir ce dialogue de confiance avec l'équipe pour prendre des décisions éclairées ensemble. C'est aussi une question de transparence et de priorisation intelligente dans le backlog. Quelle stratégie préconises-tu généralement dans ces cas-là ? Prioriser des refactorisations itératives ou planifier des sprints dédiés à la réduction de la dette technique ? À bientôt, et au plaisir de lire ta réponse ! Robin 🚀

[@fbuiphuong61]

@@ScrumLife "Prioriser des refactorisations itératives ou planifier des sprints dédiés à la réduction de la dette technique ?" C'est l'équipe responsable et autonome, auto organisée en un mot, qui choisit la mise en oeuvre au cas par cas comme il lui convient le mieux ie comme elle sera la plus efficace et productive. Le PO ne choisit pas ou que très rarement entre les options de mise en oeuvre possibles, il donne les contraintes et les priorités, la vision qui oriente les choix, mais c'est l'équipe qui reste maitre des choix de sa propre organisation et des choix techniques. Ces points peuvent d'ailleurs évoluer : c'est itératif et aussi sujet à amélioration continue !^^ Et le PO adapte ou refait ses stories, ses spec, ses sprints, son backlog .... il est aussi agile le PO !^^

[@TiffannyDoll]

Ça m'intéresse d'avoir plus de vidéo

[@ScrumLife]

Salut @TiffannyDoll ! Merci beaucoup pour ton intérêt ! 🎉😊 On adore savoir ce que vous aimeriez voir sur Scrum Life. Y a-t-il un sujet particulier sur l'agilité ou sur Scrum et Kanban que tu aimerais qu'on explore davantage ? Tes suggestions sont toujours les bienvenues ! 🚀 À très vite, Robin

[@fbuiphuong61]

J'aime beaucoup vos vidéos, je suis globalement d'accord avec la majorité de ce que vous dites. Sauf que dans la définition de l'agilité comme dans tout le reste de la vidéo, vous ne mentionnez jamais la terminologie "AMELIORATION CONTINUE" ... alors que c'est quand même le vrai objectif final de l'agilité ! Pourquoi on itère en récupérant du feed back à chaque fois, c'est pour s'améliorer de façon empirique : on améliore ainsi les process de chaques équipes, le dev, la code base, les compétences, on trouve une solution à la majorité des problématiques, les comportements s'améliorent aussi ... et le graal vers lequel on converge tous ... on améliore le produit pour optimiser sa valeur pour les utilisateurs et son ROI pour l'entreprise ! C'est quand même dingue d'expliquer un concept sans jamais le nommer littéralement !^^

[@ScrumLife]

Merci pour ce commentaire. Pour être pointilleux, je ne pense pas que l’objectif final de l’agilité soit l’amélioration continue. L’objectif est de faire le bon produit. L’amélioration continue reste indispensable, mais c’est un outil, pas une fin en soi. Qu’en dis-tu ? - Constantin

[@ScrumLife]

Salut @fbuiphuong61, Je te remercie pour ton commentaire super pertinent ! Tu mets le doigt sur un point crucial : l’amélioration continue est effectivement au cœur de l’agilité. Tu as tout à fait raison, notre approche consiste à itérer, recueillir du feedback, et ajuster en conséquence pour constamment s'améliorer. Peut-être que dans cette vidéo spécifique, j'ai davantage mis l'accent sur d'autres aspects de l'agilité, tels que la collaboration, la flexibilité, ou l’adaptation au changement. Mais tu fais bien de souligner l’amélioration continue, car elle est le moteur qui nous permet de gagner en qualité et en efficacité. Je suis ravi de voir que tu es aussi passionné par le sujet et que tu as une compréhension si fine de ces concepts. Pour toi, quelle pratique agile incarne le mieux cette notion d'amélioration continue ? J’aimerais beaucoup connaître ton avis ! Merci encore pour ton retour et à très vite sur Scrum Life ! Robin

[@fbuiphuong61]

@@ScrumLife : oui l'objectif final est bien le bon produit mais ça ne change pas, c'est toujours vrai, c'était aussi le cas en waterfall et c'est vrai avec n'imorte quelle méthodologie, framework ou absence de framework ... c'est une vérité absolue en soit (enfin j'espère !^^) . Le propre de l'agilité, ce qui fait sa particularité puisque c'est le sujet ici, c'est l'amélioration continue, concept inexistant dans les autres frameworks et anciennes méthodologies, qui conduit à tout ce que vous mentionnez très justement en terme de feed back, d'itération ... la différence est là.

[@ScrumLife]

Dans ce cas, plus que l’amélioration continue, je parlerai d’empirisme incarné dans Scrum par la transparence, l’inspection et l’adaptation. Robin

[@fbuiphuong61]

@@ScrumLife Oui c'est exactement l'idée, merci, et ça n'est pas dans la vidéo non plus. Et l'empirisme c'est du lean et c'est aussi l'EBM de scrum, et la transparence, l'inspection et l'adaptation, c'est la théorie du scrum guide, basé sur la roue de Deming (Shewhart cycle). C'est dommage de ne pas mentionner toute cette terminologie dans une vidéo sur la définition de l'agilité, même sans l'expliquer (c'est le sujet de vos autres vidéos plus détaillées d'expliquer chacune de ces notions). D'ailleurs, il n'y a pas grand chose sur l'EBM qui mériterait à être plus connu et reconnu, car c'est le début des feed backs plus formalisés.