P.O. débutante : normal que ça soit le bazar?

Communauté Scrum Life
1

Bonjour à tous-tes !

Depuis 3 mois, je ne suis plus seulement Scrum Master, mais j’ai pris de nouvelles responsabilités, et suis sur un poste multi-tâches de P.O./Scrum Master/Secrétaire pour une petite équipe de dév (on est 4 en tout, moi comprise).
(Oui, je sais, il ne devrait pas y avoir autant de casquettes sur une seule tête! Mais ça n’est pas le sujet :wink:)

Sur ma partie P.O., je constate que c’est le bazar côté client : les différentes personnes impliquées dans le produit se contredisent les unes les autres ET d’une réunion à l’autre, et je dois faire clarifier régulièrement des points qu’on croyait « arrêtés ».

J’aurais besoin de retours d’expé de P.O. plus ancien-nes, pour savoir si c’est normal, et si c’est précisément là que mon « talent » de P.O. va pouvoir s’exprimer (talent de pouvoir rendre clair ce qui ne l’est pas pour l’instant) OU si c’est un signe que quelque chose cloche côté client? (dont il faudrait que je m’empare).

Merci d’avance !

2

Franchement, sans avoir vu ton contexte, je ne saurais pas dire des choses très précises. Je ne te souhaite pas que ce soit le « bazar » éternellement. C’est tout de même un terme relatif.

Cela me paraît être le signe d’une situation complexe. N’hésite pas à t’intéresser à Cynefin pour mieux appréhender ce genre de situation. Tu peux probablement tenter des choses, mais il se peut que tu découvres que rien ne change après. C’est que tu n’as pas l’agentivité (capacité d’agir) nécessaire pour débloquer la situation. Cela n’aura pas été de ta faute.

Je t’encourage à tenter des choses mais en aucun cas à te charger de sauver le monde.

1 « J'aime »
3

Bonjour @Charlotte ,
C’est dans ces situations où je pense qu’un background de Chef de Projets a sa pertinence, même si je sais que parler de gestion de projets en milieu agile peut paraître comme une hérésie pour certains, alors qu’ils auraient des choses à en tirer, notamment en matière de comitologie.

Du peu d’informations que tu nous partages, j’ai le sentiment qu’il y a un problème assez manifeste d’alignement chez ton client. Et je ne pense pas que ce soit hors de ton périmètre de PO que de contribuer à y remédier. Bien au contraire.

La première piste serait d’aider ton client à clarifier sa vision produit. Il y a tout un tas d’outils et de méthodes, la plus basique étant la phrase (pitch) énonçant de manière synthétique mais complète la mission du produit.

La seconde piste étant que cette vision produit ainsi que la stratégie soient partagées par tous les intervenants côté client. Ce n’est pas forcément aisé. J’ai pu constater que moins le domaine est.technique, plus chacun est prompt à y aller de son avis et à y mettre son grain de sel. Il est souvent bon de se faire épauler par un expert du domaine, neutre de préférence (un consultant par exemple) qui pourra exposer les diverses problématiques avec pédagogie et remettre gentiment à leur place les personnes très assertives mais qui n’en savent au final pas plus que les autres. Ce sont souvent les pires car elles ont tendance à court-circuiter le processus de prise de décision.

Je t’invite d’ailleurs à mettre en place un processus de prise de décision qui non seulement vous évitera d’aller dans le mur, mais aussi vous permettra de verrouiller lesdites décisions une fois actées. C’est en effet très pénible de devoir naviguer dans un contexte où aucune décision n’est finalement sûre. Même en Agile. C’est d’ailleurs pour cela que je pense que le processus de prise de décision est vraiment le parent pauvre de tous les frameworks en vogue de nos jours alors qu’il s’agit pourtant d’un processus maître.

En espérant t’avoir fourni des pistes utiles.

2 « J'aime »
4

Merci à tous les deux, @punkstarman et @PainAuxRaisins,
C’est très intéressant!

Pour préciser mon propos : quand je dis que les personnes impliquées se contredisent, voici ce qui se passe souvent : une personne présente lors d’une des réunions tranche une question que j’ai posée (vous préférez A, B, C?) et choisit une option.
Lors d’une réunion ultérieure, une autre personne qui était absente lors de la réunion précédente (alors qu’elle y était invitée), va émettre des objections à la décision prise précédemment. On repart dans des débats, qui sont normaux et peut-être même sains pour l’amélioration du produit, mais qui retardent la prise de décision finale.

Je me demandais donc si ce genre de choses était habituel (je n’ai pas assez de recul, c’est mon 1er poste de PO, et mes expé précédentes de gestion de projets étaient dans de tout autres contextes, où la partie « Business » n’existait pas et où l’intelligence collective, créativité, inclusivité, étaient prioritaires…)

Et je me demande aussi dans quelle mesure j’ai un rôle à jouer en tant que PO : soit en aidant le client à trouver des façons plus efficaces pour trancher ses débats, soit en les tranchant moi-même? Est-ce que ce serait dans mes attributions? (Sachant que je suis salariée du prestataire, que je porte 3 casquettes, que je ne suis pas spécialiste du domaine du produit qu’on développe, et que mon titre de P.O. est discuté chez le client dont certains membres m’ont fait remarquer que le vrai P.O. était de leur côté -sans que personne n’ait ce titre, officiellement, chez eux.- Bref!)

Dans la mesure où je serais la P.O. « pour de vrai », mon rôle est d’apporter de la valeur au produit, et je serais théoriquement habilitée à faire des propositions, voire à trancher. Mais d’un autre côté, ce n’est pas mon entreprise = pas mes sous! C’est délicat de trancher sur des features à développer alors que ça n’engage pas, financièrement, ma propre boîte…(voire même qu’il y a conflit d’intérêt : ma boîte a intérêt à faire durer la mission, pas le client).

Enfin, concernant la vision produit, il me semble qu’elle est claire et partagée. C’est sur les « détails » que les personnes ne tombent pas d’accord (doit-on mettre telle feature dans la V1 ou plus tard? Est-ce qu’on doit donner telle permission à tel profil utilisateur, ou non? etc.)

Voilà!

Merci encore, et si vous avez d’autres retours, n’hésitez pas!

5

Salut @Charlotte,

Courage dans ce nouveau role que je trouve très difficile.
J’ai l’impression que tu attends des solutions opérationnelles, je vais donc formuler une réponse dans ce sens.

De ce que je comprends, le débat se porte se plusieurs solutions.
Je m’attarderais à poser “clairement” la problématique et le gain attendu.
Je rappellerai que seul le terrain pourra decider de la solution la plus adéquate, pendant que vous discutez les clients attendent et qu’une tentative de solution est toujours mieux que de rien faire. Et que vous pourrez toujours faire un autre solution plus tard.

Autre pistes : proposer un A/B testing pour determiner quelle solution est la meilleur.

1 « J'aime »
6

Merci pour ta contribution, @Aladin,

Oui, des solutions opérationnelles sont bienvenues, et merci pour tes suggestions. :pray:

C’est aussi des retours d’expérience de P.O. expérimentés que j’aurais aimés, idéalement, pour savoir si c’est classique (chez tous les clients, il y a des problématiques de prises de décision, de LEUR côté), et aussi, pour savoir si le fait que je les laisse décider montre ma défaillance (peut-être que c’est mon rôle de PO de trancher à leur place?). Concernant cette dernière question, j’envisage de poser la question au responsable du projet, côté client : qu’attendez-vous exactement de moi? (ça permettra de clarifier mon rôle, puisque « P.O. » ne semble pas être la bonne étiquette, selon eux…)

7

Je suis un PO expérimenté, mais pour savoir si c’est normal ou pas il faudrait que j’observe plus ton contexte précis. Il y a pas mal de facteurs qui pourraient changer mon appréciation de la situation.

Ca m’est déjà arrivé, effectivement. Parfois c’est bien, parfois c’est pas bien.

Qui convie et anime ces réunions ? Y a-t-il une personne qui joue le rôle de facilitation ou au moins de maitre du temps ? As-tu établi ton autorité ? Quelle autorité as-tu ? Qui peut couper court aux discussions stériles ? De qui peux-tu invoquer l’autorité ? Le supérieur hiérarchique des autres personnes ? Quelles opportunités donnes-tu de réagir et est-ce que tu fais savoir, explicitement ou dans la forme, qu’il y a des moments où les décisions prises ne doivent pas être rediscutées à moins que ce soit une question de vie et de mort ? Les absents ont-ils tort ou pas ? As-tu convié les gens correctement ?

Après la réunion, est-ce que tu envoies un compte-rendu à tout le monde, y compris les absents, en précisant les décisions prises et en invitant à commenter en réponse au mail ?

En as-tu la capacité ? Est-ce que ton commanditaire attends ça de toi ? A-t-il créé l’environnement qu’il faut pour que tu puisse le faire ?

Je t’invite à nouveau à regarder Cynefin qui apporte des réponses à pas mal de tes questions.

C’est une discussion à avoir avec ton commanditaire et en fonction de tes compétences.

La mention « pour de vrai » est contreproductive. Le diable est dans les détails. Ca ne sert à rien de parler pas de vaches sphériques dans le vide. Quelle agentivité as-tu ?

C’est bien de l’avoir en tête que ce ne sont pas tes sous, mais ce n’est pas ça qui doit t’empêcher de trancher. Le client a signé un contrat et j’imagine après t’avoir vue en entretien. Tu n’as pas été sortie de la mission. C’est que quelqu’un te fait confiance et délègue au moins certaines décisions.

1 « J'aime »
8

Selon mon interprétation, tu n’es pas PO, puisque tu n’es « Owner » de rien dans la mesure où tu ne sembles pas avoir avoir de prise sur les palabres des « personnes » qui veulent prioriser les features ou définir les droits des uns et des autres. Pour moi, le rôle de PO est dilué entre toi et ces différents acteurs…

Les Devs qui font ce qu’ils veulent, en appelant souvent ça « best effort », les objectifs de sprint qui parlent de « commencer » « continuer » « poursuivre » « finir » sont révélateurs d’un fonctionnement empirique ou à vue. On dévoie l’itératif en avançant dans le brouillard, sans culture du livrable ni de la valeur produit. On ne fait pas de doc, on ne produit pas de conditions d’acceptation (ou on en rajoute au fur et à mesure des découvertes), on n’évalue pas l’effort nécessaire à telle ou telle feature, on voit des US trainer pendant 3, 4 … x sprint parce que « on a eu des surprises »

Toutes ces dérives révèlent des organisations déficientes et un management diffus. La transversalité a ses limites. Si un CTO ou même un PMO demandait des burn-out charts ou les coûts réels des features, les choses seraient plus faciles à cadrer.

Mais quand le CTO me demande de ne plus faire de remarque quand certains devs arrivent systématiquement en cours de DSM (9h30), de façon quasi systématique … « c’est pas dans la culture de la boite d’aller au clash » … que voulez vous faire ?

9

Je suis d’accord avec le CTO sur ce point.
On ne gagne rien à aller au clash. Il faut penser long terme.

10

Maxime,
pour moi, rappeler à certains développeurs indépendants avec des TJM qui frôlent l’indécence que l’entreprise a des horaires, qu’il y a des rendez-vous à honorer, qu’il y a du respect à avoir avec tes collègues qui eux sont à l’heure … ce n’est pas aller au clash. C’est du savoir vivre.
Est-ce qu’il font pareil quand il s’agit de prendre un train ou un avion ? Non, ils sont à l’heure dans ces cas là … il y a bien une approche différente.

En fait, dans l’équipe à laquelle je fais référence, il y a une forme de « dictature » sourde de quelques devs en prestation, qui font ce qu’ils veulent, quand ils veulent car se considérant intouchables, au motif qu’ils détiennent la connaissance histo sur le périmètre.

Dernier « 'exploit » en date « je rallonge mes congés d’une semaine » … bouzillant le peu d’organisation en place.

Et donc le CTO dit Amen à tout. Parce qu’il fait dans son froc que le gars se barre si d’aventure on lui met quelques contraintes… c’est une une vision à long terme, ça ?

1 « J'aime »
11

On est d’accord que ces éléments de contexte change la perspective de ton précédent post.

1 « J'aime »