Je voudrais évoquer un personnage côtoyé lors d’un projet précédent et auquel on se confronte au moins une fois dans une carrière dans la tech. Je veux parler d’un dev chevronné aux compétences techniques indéniables mais qui considère que toute l’équipe Scrum voire même les parties prenantes doivent s’adapter à lui, son incomparable talent et non pas l’inverse. Celui-là a intégré l’équipe en cours de projet en tant que freelance. En toute honnêteté, je ne pense pas avoir été rigide mais plutôt ouvert aux remarques d’un intervenant externe mais en tant que PO je ne me suis pas senti respecté dans mon rôle. Quelqu’un a déjà été confronté à une situation similaire ?
Ah ça, je dirais que c’est un classique dans plusieurs organisations. Vous avez frappé un scénario où c’est le dev, mais des gens comme ça, il y en a dans tous les postes possible. Le truc, c’est généralement de ne jamais les prendre de front, car il faut comprendre que souvent, avant d’être des divas, c’est généralement des gens qui ont beaucoup bossé pour atteindre une certaine position (relative) et que c’est seulement en développant une certaine intransigeance qu’ils ont (enfin) fini par se faire écouter. C’est généralement des gens de ce profils qui vont nous sortir des lignes du type « ça fait des années que je dis cela et personne ne m’écoute ». En bref, c’est généralement un carence en écoute de la « machine » qui génère ce type d’individu et c’est toujours plus rentable au final de démontrer une écoute, puis consulter ailleurs et revenir plus tard sur la situation avec beaucoup de transparence pour qu’il comprenne le fondement de la situation. Il sera alors plus facile de faire passer des contre-suggestions par la suite, car l’individu aura (enfin) l’impression d’être écouté.
Cela dit, c’est du travail à long terme qui demande vraiment beaucoup de patience pour passer au travers des frustrations. Je ne dis pas que ça sera facile, mais ça va quand même être moins pire que d’être en constant affrontement. Ces confrontations vont simplement le nourrir dans son impression d’être un éternel incompris et empirer tout ça.
Deux remarques en te lisant …
Tout d’abord, c’est une erreur de casting. Quand on recrute un Dev pour bosser dans une ÉQUIPE scrum, un profil moins pointu mais peut être plus engagé dans l’esprit collectif est probablement plus adapté.
Ensuite, le SM doit recentrer le fonctionnement sur les fondamentaux scrum. Un Dev peut échanger avec les parties prenantes, mais à la marge. Exceptionnellement.
Son interlocuteur c’est le PO qui est l’arbitre/garant des choix fonctionnels et de leur priorisation.
Le SM doit s’appuyer sur la méthode et le choix de l’entreprise en faveur de cette méthode, pour que chacun reste dans son rôle …
Ou une erreur de transformation. La personne a pu être recrutée bien avant l’idée de faire du travail en équipe auto-organisée. Elle a peut-être progressé jusque-là dans un modèle compétitif. Elle n’a, peut-être, même pas été consultée ou écoutée dans le passage à Scrum.
J’en ai connu, je les prends plus pour des « solistes » que des « divas ».
Généralement je me suis arrangé pour les laisser faire leur solo, et détacher la responsabilité de leur travail de celle des autres. J’en fais une équipe à eux seul. Des éclaireurs, ou des snipers, leur comportement peut protéger une équipe « collaborative » qui travaillera sur du plus « complexe, stable, qualitatif ». Le soliste sur de l’urgence, du décousu, ou du pointu.
Par contre, c’est en C.O.P. / Chapter que je vais m’arranger à les faire se rencontrer et grandir.
En cherchant à ce qu’ils apprennent à « communiquer », « partager », certain devront apprendre à transmettre, d’autre à se laisser challenger.
Il y a juste une « menace » que j’ai rencontré sur ce modèle, c’est le management 1.0 / rouge qui aura tendance à faire plus marque de reconnaissance au soliste shooter qu’à la force douce de l’équipe.
On retient toujours plus vite le nom du chanteur d’un groupe de musique…
J’ai une hésitation sur cette phrase en particulier, que j’attache à un autre comportement.
Celui de l’expérimenté blasé.
J’en suis un .
J’ai juste le recul pour ne pas dire la phrase à voix haute. Mais je la pense extrêmement souvent.
La diva, veut faire ce qu’elle veut, comme elle pense.
L’expérimenté blasé est « fâtigué » de voir les mêmes débats recommencer.
Et c’est super facile de construire des expérimentés blasés dans votre équipe. Faites des sessions (de découvertes, de brainstorming, de rétrospective, …) où vous leur demandez d’écrire des post-it avec les points qui les interpellent, puis faites les travailler en groupes pour faire des « choix » (avec un dot voting)… Ça vous parle ?
Multipliez ce genre d’exercice très efficace…, et comptabilisez le nombre d’idées abandonnées lors des choix inévitables qui ont dû être faits.
C’est une usine à frustration, à blasitude
Ce n’est qu’un exemple de ce qui amène à cet état.
Je pourrais entreprendre d’écrire le « comment réagir à ça » … mais là je file dans les transport
J’éditerais mais d’autres auront peut-être répondu entre temps
Intéressant…Avec le recul, je me dis que j’aurais dû le considérer comme un soliste et que le management aurait dû mettre les choses au clair dès son arrivée. Merci en tout cas d’avoir répondu.
On peut facilement faire le parallèle avec le sport ou on loue « la force du collectif » par opposition au talent individuel qui seul ne peut conduire au succès de l’équipe.
Je reste circonspect sur ces profils « Diva » ou « Soliste » … à l’arrivée, ils ont une trop forte propension à engendrer des déséquilibres dans une équipe : domaine réservé, « il ne faut pas contrarier le Soliste », « Oui mais bon c’est Norbert, tu sais comment il est … »
La cohabitation des Solistes ou Diva, ben c’est le PSG … (que les parisiens me pardonnent). Sur le papier, probablement la meilleur équipe du monde … mais ça ne fonctionne pas
Si ce développeur a ce comportement de « diva » depuis longtemps, cela signifie que son comportement a été, au pire, encouragé, au mieux laissé exister. Comme le dit @Moosh, le management à l’ancienne a tendance à valoriser ce genre de comportement. Et s’il récolte les lauriers lorsqu’il fait la diva, il serait bien bête de ne pas continuer. Cela peut-être aussi que son ou sa manageuse craint les situations conflictuelles et ne sait pas comment le recadrer. Ou même que le management ne voit pas les inconvénients de son comportement pour l’organisation.
Bref, s’il tire avantage de son comportement, pas étonnant qu’il continue. Et si les impacts ne sont pas explicités, pas étonnant que personne ne le confronte.
Je chercherais à rendre visible les impacts de son comportement : les positifs et les négatifs. Pour lui, pour son équipe, pour l’organisation. Ensuite, j’essaierai de travailler avec lui, son ou sa manageuse et/ou l’équipe (en fonction des drivers de motivation de ce dev) pour trouver une façon de garder les impacts positifs et limiter les impacts négatifs.
D’ailleurs, un atelier « moving motivators » peut-être intéressant à faire dans cette équipe
Bonjour
Dans ma carrière j’ai été confronté 2 fois à ce genre de développeur. La diva incontournable, intouchable,…
Merci de toutes vos réponses.
Continuez s’il vous plaît à développer ce sujet, cela est très inspirant.
MERCI
Perso, je tiens a souligner que le comportement de soliste (pas de diva) a des aspects positifs qu’il y a lieu de conserver si on arrive a gérer les négatifs. Et particulièrement si cela vient de sa personnalité, de son mode de fonctionnement,et non dun désir de profiter d’un management old school.
Ne jamais oublier qu’on ne fonctionne pas tous pareils. Qu’au-delà de nos compétences, il y a aussi lieu de tenir compte de nos fonctionnements dans la création de nos interactions
Ça me fait penser au mode d’emploi personnel. Un chouette exercice que m’avait inspiré un épisode du podcast de @leodavesne
Ce manuel est bien entendu la perception que j’ai de mon fonctionnement. Ça n’est ni le fonctionnement perçu par les gens qui m’entourent, pas plus que mon fonctionnement réel.
N’hésitez pas à m’en faire un retour, c’est toujours enrichissant de découvrir ces différences de perception. (ce document est ouvert aux commentaires)
Je suis tout à fait d’accord avec vous en fait. Même que si le positionnement de mon commentaire s’adressait à l’auteur de la question elle-même, au final, je voulais surtout dire qu’un dev réellement diva, en fait, c’est extrêmement rare, même que je ne me souviens pas en avoir réellement rencontré. Pourtant, des gens qui finissent par adopter des comportements intransigeants par rapport à l’équipe ou l’entreprise, on en voit partout.
Il faut donc creuser. Qu’est-ce qui a amené cette personne à adopter de tels comportements ? Au delà de la personnalité, peut-être qu’il y a des pratiques (passées ou actuelles) dans l’entreprise qui génèrent cette réaction ?
C’est pour ça que je dis qu’au final, c’est généralement l’écoute et surtout la preuve d’écoute qui peuvent amener à corriger une telle situation et amener un soliste, comme vous dites, à adopter des comportements qui respecteront sa personnalité tout en facilitant son intégration à l’équipe.
Parce que oui, même si le soliste préfère généralement avoir l’espace pour utiliser sa créativité ou simplement pour se concentrer sur ses choses sans être importuné, le reste des membres de l’équipe, eux, se sentiront beaucoup plus à l’aise de travailler ou de soulever des problématiques s’ils n’ont pas la crainte d’un « loose cannon » dans l’équipe. Aussi gentil, drôle et efficace soit-il.
Le plus difficile dans le développement logiciel, c’est d’arriver à faire cohabiter le domaine et la technique dans un seul crâne, et à fortiori, qu’il soit virtuellement le même pour tout le monde.
Du coup, si quelqu’un, même bien attentionné.e, bosse en solo sur des parties du code, on crée un ownership qui de part mon expérience, est l’une des causes principales d’échec de projet (personne providentielle sans qui le projet ne peux pas tourner).
