PO face à un développeur "Je sais tout"

Communauté Scrum Life
1

Je suis actuellement en charge d’une équipe de développers qui est assez juniors et ont du mal à être autonomes sur le plan technique. À ma demande, l’équipe a été renforcée par un nouveau développeur expérimenté possédant des compétences qui nous manquaient.

Cependant, cela ne fait que deux jours qu’il est dans l’équipe et je rencontre déjà des difficultés avec son attitude. Bien qu’il ait beaucoup d’expertise et qu’il ait pu mettre le doigt sur plusieurs choses et proposer des idées intéressantes, il a tendance à regarder de haut ce que nous avons fait jusqu’à présent et à chercher à prouver qu’il est supérieur. Il remet en question le travail des autres développeurs et le mien -

  • « Il faut que je fasse une revue de code avec vous »
  • « MVP, c’est une connerie, il faut faire du POC, j’ai toujours fait ça et c’est la seule chose qui fonctionne ! »

Il critique également notre approche de l’US Mapping en affirmant que nous ne regardons que les fonctionnalités, une maquette dynamique suffira si nous ne tenons pas compte des tickets techniques.

Il trouve également que les US sont découpées de manière trop fine et qu’il préfère développer plusieurs fonctionnalités en même temps. Par exemple, il considère que les trois US que j’ai créées pour le panier (ajouter au panier, ajuster la quantité et visualiser le panier) ne devraient faire qu’une seule US.

Enfin, lors des réunions, il détourne souvent l’attention de l’équipe du sujet en cours en balancant des idées rien à voir, malgré mes appels de l’ordre du jour.

Actuellement, je lui donne des explications sur les différences entre POC et MVP, l’approche de l’US Mapping, ainsi que les avantages d’un découpage fin des US. Cependant, il est du genre à vouloir avoir le dernier mot, même s’il a tort.

Bien qu’il soit utile pour l’équipe d’identifier des points à améliorer grâce à ses commentaires, je sais que cette attitude va finir par irriter tout le monde.

Avez-vous déjà été confronté à ce genre de situation, et avez-vous des conseils pour gérer ce type de personnalité ? (Pour information, nous n’avons pas de Scrum Master, et je suis celui qui endosse cette casquette pour l’animation des cérémonies et pour enseigner à l’équipe le fonctionnement de Scrum.)

2

As tu songé à éventuellement passer un deal avec lui : tester sa « méthode » sur un sprint ou 2, et tester ta « méthode » sur un sprint ou deux et ensuite faire le point en toute franchise et humilité ?

L’idée est de voir ce qui marche le mieux pour l’équipe. Il fait aussi partie de l’équipe.

Très bon sujet :blush:

2 « J'aime »
3

Bonjour @nicobiot

Pour l’instant je l’ai juste proposé de regrouper les US qu’il se positionne dessus.
J’adore ton idée, je vais entamer des conversations plus ouverte avec lui dès la semaine qui arrive. Merci

4

sur ce point j’aurais tendance à être d’accord avec lui.

je n’ai absolument pas assez d’infos pour savoir s’il faut regrouper ou pas, mais j’ai toujours fait confiance aux développeurs pour me dire de quel niveau de découpage on a besoin.

je ne demande qu’une seule chose en échange : qu’on finisse les sprints. s’ils ont demandé à regrouper et que ça s’est transformé en un truc trop gros, je mets le point en rétrospective et je demande comment on fait mieux la fois d’après.

ceci dit, et là où c’est compliqué, c’est que parfois ils vont demander à quoi ça sert de finir dans un sprint donné vu qu’on continuera au suivant de toute manière.

et ça oblige à donner du sens à la notion de sprint, et donc notamment à associer la fin de sprint à certaines actions pour collecter du feedback.

dans ce cas, le problème est clair : si l’US n’est pas finie, on doit attendre le sprint suivant pour collecter le feedback.

ça a aussi un impact sur la manière dont tu découpes : comment faire pour avoir un périmètre qui permet de collecter du feedback utile à la fin du sprint ?

et une fois que vous avez ce niveau de maturité, vous pouvez même aller encore plus loin : comment collecter du feedback encore plus souvent qu’une fois par sprint ?

pour prendre un pas de recul, il me semble qu’il faut déplacer la discussion avec lui de « comment on fait » vers « que souhaite-t-on atteindre ? ».

en soi, on s’en fout de faire des MVPs ou des POCs, des story maps ou une maquette dynamique.

par contre, on ne s’en fout pas si on est bloqué dans un tunnel de développement qui empêche de mettre un produit fonctionnel entre les mains d’utilisateurs pendant 12 mois, parce qu’il a fallu faire une maquette complexe.

on ne s’en fout pas si la solution est dimensionnée pour quelques dizaines de personnes alors qu’elle doit en servir des milliers, parce qu’on a fait un MVP qui n’a pas un niveau de qualité suffisant.

essayez donc de vous aligner sur ce qui est important en termes d’objectifs à atteindre, et ensuite vous pourrez avoir une discussion plus détendue sur les moyens d’y parvenir. et surtout, vous aurez chacun une meilleure base pour dire « ce qu’on fait ne marche pas » si vous avez clarifié au préalable ce que vous vouliez obtenir.

2 « J'aime »
5

Salut Nguyen,

J’ai déjà rencontré ce type de réaction plusieurs fois (j’en ai même fait partie je pense :yum:). La chose intéressante à comprendre est pourquoi réagit-il ainsi ? De mes expériences, plusieurs caractères peuvent entrainer ce comportement :

  • Le « je sais tout ». La rock star avec un ego surdimensionné. On pense souvent à celui-là en premier, mais c’est généralement le profile le moins fréquent.

  • Le Jeune fougueux. Je ne parle pas de jeune dans l’age, mais dans l’ancienneté dans l’équipe. Il y a toujours un effet « petit nuage » quand on change de boulot. On arrive plein de motivation, avec plein d’idée au risque d’aller trop vite et trop fort pour l’équipe.

  • Le faux imposteur. Une personne peu sûre d’elle, sujette au syndrome de l’imposteur qui se sent obliger de pousser ses décisions de peur qu’on lui reproche de ne pas être moteur.

  • Le « neuroatypique ». Il n’a pas du tout l’impression de remettre en cause les choses, il souhaite juste proposer des idées de manière bienveillante, mais son ton, son attitude, ne jouent pas en sa faveur.

Et sûrement plein d’autre profile !

Mon conseil est de déjà comprendre ses raisons. Discute avec lui au café, dis-lui ce que toi tu ressens, ce que toi tu comprends de la situation et laisse-le expliquer son point de vue. Paraphrase pour voir si tu as bien compris son point de vue. Une fois sur le même niveau de compréhension du problème, vous pourrez commencer à vous entendre et à négocier.

Surtout, garde ton calme. La pire chose à faire serait une phrase du style « Je suis le PO, c’est moi le responsable du backlog ». Avec ça, tu flinguerais ta relation pendent plusieurs mois au moins :wink:

2 « J'aime »
6

Salut @Hanh_NGUYEN

Beaucoup de bons conseils ont déjà été donnés, c’est top !

Quand j’ai lu ta description de la situation, je me suis demandé qui et comment on a présenté la situation à ce développeur.
Si on l’a mis en position de sauveur, d’expert dans une équipe qui va avoir grand besoin de ses lumières, ça ne serait pas étonnant qu’il adopte ce genre d’attitudes :wink:

L’idée serait alors de le faire basculer d’une posture de sauveur à une posture de mentor, dont l’objectif est d’aider l’ensemble de l’équipe à monter en compétence et en autonomie.
Pour ça :

  • j’expliciterais cet objectif avec lui. Si besoin/pertinent en incluant son manager dans la boucle.
  • je valoriserais systématiquement les fois où il se conduit en mentor
  • je valoriserais également les situations où l’équipe décide ensemble, après une discussion constructive où on a entendu l’avis de chacun.
  • quand il adopte une posture de sauveur, je chercherais à le ramener dans la posture de mentor. Par exemple : « des revues de code, bonne idée ! C’est important que toute l’équipe sache faire cela, à la fois pour leur montée en compétence, et pour que tu ne deviennes pas un goulet d’étranglement. Est-ce que tu veux bien animer un atelier avec l’équipe pour que vous construisiez ensemble votre processus de revue de code ? »

Qu’en penses-tu ?

2 « J'aime »
7

Merci à @lprost @Tan @Emilie
Je trouve que vos analyses de profil et posture sont très pertinentes. De ce mon point de vue, il est clairement venu tant que sauveur mais il cherche aussi à faire sa place dans une équipe déjà existante.
Je vais davantage veiller à son intégration et l’encourager d’etre mentor de l’équipe.

C’est dans les situations comme ca, que la difficulté de travailler à distance se ressent. Pour cette équipe, la moitié de l’équipe se retrouve que le jour du review, soit 1 fois tous les 2 sems, l’autre moité, jamais, 100% remote

Par ailleurs, je veux vous poser une question concernant l’utilisation de la caméra. Avant, j’ai travaillé dans les autres secteurs, et tout le monde mis sa caméra d’office. Ici, personne ne veut mettre sa caméra. J’ai meme organisé des cafés virtuels pour faire du ice breaking, mais malgré les encouragesments, certains refusent catégoriquement de mettre sa caméra (pas à l’aise, la chambre est un mess, les enfants sont autour…) Ca fait 1 mois de demi que je travaille avec eux et je connais toujours pas ressemble une partie de mon équipe. Est ce que cette situation est courant ? et quelles sont vos astuces pour créer des moments off, créer une conversation informel comme la pause de cafe

8

je viens d’avoir un flash mais il me semble que moi et lui, on a tous les 2 mélangés des pinceaux entre le product backlog et le sprint backlog.

Le product backlog est sous la responsabilité de PO et on détaille des fonctionnalités.
Lui, il voulait avoir des taches techniques dessus, mais ca doit etre du sprint backlog qu’il parle. A ma connaissance, c’est le backlog géré par les dev et ils peuvent mettre des tâches techniques dessus pour mieux organiser le travail. Mon équipe n’a pas trop developpé cela lors des 2 derniers prints.

Comme tous les 2 , on a simplement dit backlog chaque fois, on a du mal compris.
Je vais vérifier avec lui ce point demain

1 « J'aime »
9

Pour la webcam j’ai déjà eut ce cas. Je pense même que j’ai plus souvent eut des équipes qui ne mettaient pas la webcam que l’inverse. J’ai récemment bossé pendant 6 mois avec un collègue en Georgie sans jamais vois son visage, pas même une photo d’avatar :smiley: . Ca n’empêchait pas d’avoir de très bonnes relations et de très bien travailler ensemble.

Certaines équipes sont fun, d’autre sont boring. Changer une dynamique prend du temps, je dirai au moins 6 mois si l’équipe est réceptive. Si tu les sens prêts, tu peux tenter une rétro Moving Motivator pour comprendre ce qui les motive. Mais vas-y en douceur, certaines équipes sont très réticentes au management 2.0 (ou 3.0, j’ai perdu le compte :stuck_out_tongue: ).

Pour le Product Backlog VS Sprint Backlog, perso je ne fais pas trop la différence. Pour moi, le Sprint Backlog est juste le haut du Product Backlog.

Par contre, tu soulèves la question des tâches techniques dans le backlog. A voir si ces tâches sont un découpage technique d’une stories. Dans ce cas, il découpe bien comme il veut du moment que la story est Done à la fin du sprint.
S’il s’agit de tache, de dette technique, c’est un vaste sujet…

1 « J'aime »
10

Bonjour,

Pour son comportement, je suis assez d’accord sur le côté sauveur/mentor, il faudrait que tu puisse revoir avec lui son positionnement pour qu’il comprenne qu’il fait aussi parti de l’equipe. Je pense c’est le point principal :).

Concernant le côté « tickets techniques », je creuserais un peu plus avec lui ce qu’il veut dire par là, je ne comprend pas sa remarque sur les maquettes. De mon point de vu des tickets techniques peuvent tres bien être dans le backlog produit si il s’agit de dette technique par exemple ou même d’un besoin d’analyse.

Pour l’histoire de la camera, je n’ai pas de réponse, mais justement, si d’autres personnes ont le même soucis j’aimerais bien savoir si ils ont pu régler ça et comment.

11

Bonjour,

Je pense qu’il pâtit justement de son expérience : en effet, il a peut être déjà travaillé avec des équipes plus seniors. Quand tu travailles avec ce genre d’équipe, c’est sûr que tes US peuvent être un peu moins découpées et d’ailleurs ton sprint fournira sans doute plus de features. Mais tu dois lui rappeler qu’il faut emmener toute l’équipe. Et puis c’est tellement facile d’appliquer des recettes toute faites qu’il n’a peut être pas vu que l’équipe ne suivrait pas.

Il faut quand même que tu positionnes son rôle. C’est aussi, je crois, ce qu’il ne comprend pas. Si vous lui avez dit qu’il faut qu’il apporte son éclairage senior, c’est ce qu’il fait et là, c’est vous qui n’êtes pas clairs. Il faut lui dire où tu as besoin d’avoir son conseil et ses retours et lui rappeler que son rôle est de faire monter les développeurs en compétence, de valoriser leur travail, pas de les démotiver en leur disant qu’ils font mal.

Enfin, de ton côté, tu dois assumer les choix que vous avez fait. Il trouve que ce n’est pas comme ça que ca aurait dû être fait? Oui mais tous les arbitrages ne sont pas toujours techniques. Toi tu t’en rends compte parce que tu échanges avec les métiers, les parties prenantes, tu fais avec des budgets etc. et tu en as discuté avec les autres dév avant, mais lui ne le sait pas. Il n 'est d’ailleurs pas sûr que ses remarques soient des critiques mais des incompréhensions. De plus, il te faut prévoir que s’il fait son boulot de montée en compétence des équipes, de ton côté, il faudra progressivement adapter tes US en échangeant avec eux en permanence pour être au bon niveau de détail.

Pour la caméra, c’est peut être qu’ils ne veulent pas trop montrer leur espace perso(s’ils bossent de chez eux) et tu ne pourras pas leur faire allumer la caméra. En même temps, s’il n’y a pas d’ambiance, ce n’est pas en les regardant que ca ira mieux. On peut créer du lien au téléphone avec des gens qu’on ne connais pas. Donc il faut faire pareil qu’au téléphone: voix chaleureuse, blagues, partage de galère, rebondir de l’anecdote de l’un sur l’anecdote de l’autre pour créer du lien… c’est long parfois avec les introvertis mais ça marche.
J’espère que l’ambiance va s’améliorer!

12

Pour la caméra, tous les logiciels de visio ont un système de background qui masque l’environnement, donc cela ressemble à une excuse.

Je ne pense pas que c’est en poussant sur cet aspect que les choses s’amélioreront. Perso je ne suis pas toujours fan de la camera et mes collègues non plus et nous arrivons à bosser ensemble.

Pour voir leur tête peut être qu’une visio à deux, un café virtuel sera plus simple à mettre en place.

13

merci @Tan @val @ALO pour vos partages.

Après une semaine passée dans l’équipe et quelques conversations avec le dev en question, j’ai remarqué qu’il est très motivé pour améliorer les compétences de l’équipe. Cependant, il semble que la motivation seule ne suffit pas.

Avant son arrivée, l’équipe progressait lentement en raison de problèmes de compétences, mais elle progressait quand même. Depuis son arrivée, il a tenté de mettre en place diverses choses, telles que des code review, Git flow et divers paramètrages. Cependant, avec tout cela, l’équipe s’est complètement détournée de son travail, et apparemment, aucune ligne de code n’a été écrite à quelques jours de la revue.

Il m’a assuré que ces changements étaient indispensables avant de commencer à développer, et je suis parfaitement convaincu de cela. Cependant, après avoir discuté avec différents membres de l’équipe à qui il a essayé d’aider, j’ai appris qu’il essaie de montrer beaucoup de choses, mais ne résout pas nécessairement les problèmes. De plus, les membres de l’équipe sont tous intimidés par son expertise, n’osent rien dire même s’ils sentent que c’est du temsp perdu, et après avoir passé une journée avec lui à examiner différents sujets, ils ont dû chercher de l’aide ailleurs.

La semaine prochaine, je prévois de discuter à nouveau avec lui pour trouver des moyens d’améliorer la situation. Je demanderai aux responsables techniques d’intervenir pour les problèmes techniques, mais il est clair que l’objectif de ce sprint ne sera pas atteignable :disappointed_relieved:!

14

@Hanh_NGUYEN Du coup, vous avez annulé le sprint ou pas ?

15

Il faut quand même lui laisser le temps de mettre en place les choses. Une code review, ca ne semble pas fou. Et attention en tant que PO, pour le coup, ça n’est pas ton rôle d’intervenir sur la manière dont les dév prennent le sujet.

Par contre, délivrer de la valeur à chaque sprint fait partie du rôle de l’équipe. Là où ca pêche c’est qu’aucun d’entre vous n’a anticipé le fait que des changements en interne risquaient d’avoir des impacts sur le sprint et qu’il fallait peut être voir moins grand. Et ça c’est précieux comme apprentissage! As-tu vu avec les dév s’il n’y a pas moyen de respecter l’objectif de sprint en réduisant un peu la voilure ?
Pensez que vous être maintenant une équipe avec lui et que le succès de l’équipe passe par une adaptation des deux côtés.

Enfin, il y a peut être un peu de travail de communication sur le plan humain à faire plus que sur le plan du travail, histoire de détendre tout le monde : on est moins crispé quand quelqu’un d’un bon niveau nous donne un conseil et qu’on le connaît bien que quand c’est quelqu"un qu’on ne connaît pas. C’est plus facile de dire qu’on ne comprend rien quand on connait la personne, idem pour lui expliquer.

16

Profitez de la rétro pour identifier les points justement que les personnes ont identifiés comme ne leur convenant pas et les actions à mettre en place pour le prochain sprint pour que toute l’équipe y trouve son compte.
Chacun doit s’améliorer, chacun doit changer, chacun peut et doit faire un effort pour que l’équipe grandisse.
Si les devs te reprochent certaines choses sur les US, demande leur ce qu’ils proposent pour que tu les fasses mieux pour qu’elles leur conviennent mieux.
Pour l’histoire du backlog, normalement, il y en a un seul, le tien.
Ensuite, sur l’US, rien n’empêche l’équipe de créer les sous-tâches « techniques » qui vont permettre à l’équipe de traiter ton US et libre à eux d’y écrire ce qu’ils veulent.
Et même si c’est le PO qui est le maitre de l’US, rien n’empêche que l’équipe la complète si elle considère qu’il y manque quelque chose ou que le format ne lui convient pas… à discuter tous ensemble afin de travailler ensemble plutôt que mettre des frontières en disant : ça c’est mon job, pas le tien, l’outil est au service de toute l’équipe et rien ne marche mieux que l’entraide plutôt que les critiques qui pourrissent l’ambiance dans l’équipe.

17

On annule pas. Un (seul) dev a pu avancer un peu et on va avoir le minimum à présenter mais c’est sûr que l’objectif du sprint ce n’est pas atteint.

@ALO
Le développer pour laquelle j’ai créé ce poste est de plus en plus coopératif avec moi et l’équipe , et la quantité de travail sur le changement n’est pas si important mais Nous n’avons pas eu que des difficultés techniques en ce moment. 1 dev vient de perdre un proche, 2 autres à des soucis avec la justice, et la personne en question a aussi des soucis financiers :person_facepalming:. J’ai vraiment beaucoup de difficultés pour booster la productivité (aussi bien avec la casquette PO que SM). La journée de travail est souvent fracturée par des longues pauses que chacun partage les misères, ils ne sont pas focus sur le travail… J’ai l’impression que ça arrange quand même certains d’avoir quelqu’un qui prend le lead sur paramétrage/ code review plutot que passer la journée sur le code

Je les ai proposés de profiter le reste de ce sprint pour corriger les bugs qu’on a aperçu entre-temps en leur disant que au prochain train il faut tout donner pour attraper notre retard. Mais est-ce que c’est la bonne chose à faire ?

18

Mais si vous savez que l’objectif n’est pas atteignable à quoi bon maintenir le sprint ? J’ai du mal à comprendre. :sweat_smile:

19

Je ne suis pas sûre d’avoir la bonne réponse pour cela :sweat_smile:
Parce que chez nous, c’est review tous les deux jeudis et on ne peut pas démarrer un nouveau avant.
On nous a demandé de me tenir le review, ce qui permet de montrer le peu de choses qu’on a pu travailler dessus.

D’après le Scrum guide PO peux annuler si l’objectif est devenu obsolète mais pour moi, nous ne sommes pas dans ce cas, non atteignable est différent de obsolète.

Par ailleurs, si vous annulez un sprint, vous commencez un autre directement après ou vous attendez le prochain début ?

20

En ce qui me concerne, si un but n’est pas atteignable, il devient obsolète par définition. Le but c’est aussi de réveiller l’ensemble de l’organisation et de la mettre devant la situation accomplie.

Pour ce qui est de la procédure, une première idée est de replanifier un mini-sprint avec le temps restant en « attendant » le prochain sprint en en tirant le plus de valeur possible.

Une deuxième solution (sûrement préférable à mon avis) serait de faire une retrospective, d’aller au fond des choses, et de profiter du temps qui reste pour faire en sorte que ça n’arrive plus :slight_smile: