Quel est le degré d’isolement des membres de votre équipe ? L’avez-vous déjà évalué ? En avez-vous estimé l’impact sur votre efficacité et votre bien-être ?
- Les conséquences de l’isolement des développeurs sur la santé de l’équipe
- Comment déceler les symptômes liés à l’isolement des développeurs ?
- Comment guérir la solitude des développeurs ?
Les conséquences de l’isolement des développeurs sur la santé de l’équipe
Livré à lui même, le développeur sombre plus facilement dans les mauvaises pratiques et anti-patterns qui, sans recul sont d’apparence séduisante.
Over-thinking, Useless Code & False-feature Rich
Le développeur isolé est instinctivement attiré par les solutions complexes, alors même que les besoins sont simples. Il prendra parfois du plaisir à replonger dans la nostalgie scolaire de l’énigme à résoudre 🤯et cela peut se comprendre.
Les tâches plaisantes ont une fâcheuse tendance à être tellement immersives qu’on en oublie le besoin, la direction et qu’on en perd la notion du temps. Nous sommes tous victimes de cette maladie chronique. Ceux qui ne se sentent pas concernés n’en sont tout simplement pas encore conscients.
Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behaviour.
Dee HOCK – VISA Founder
Ego, Conflit et Compétition
Le développeur isolé investit une partie de son âme – et donc de son égo – dans son “produit”. Chaque commentaire, modification ou interrogation visant son produit peut être vécu par ce dernier comme un jugement de compétences.
Les dangers sont les suivants :
- La confusion par le développeur entre la remise en question de ses choix et celle de ses compétences.
- L’apparition de conflits et de compétitions au sein de votre équipe.
Perte de temps et retard
En s’isolant, le développeur perd du temps à essayer de sortir de situations bloquantes alors même que ses camarades détiennent souvent, déjà la réponse.
Il en résulte souvent des solutions trop complexes et des développements inutiles.
Plannings complexes
En s’isolant, les développeurs partagent moins leurs connaissances et ont souvent la maîtrise exclusive de certains sujets ou certaines technologies. La gestion des plannings peut devenir un vrai casse-tête.
Développeurs surchargés proportionnellement à leur ancienneté
Dans l’urgence, l’équipe repose sur le développeur le plus expérimenté ou le plus ancien pour traiter le sujet plus rapidement. Cela creuse alors encore plus l’écart de connaissances entre ce développeur et les autres.
On rentre alors dans un cercle vicieux dont la conséquence est de surcharger de plus en plus les membres les plus expérimentés de l’équipe… jusqu’à saturation.
Comment déceler les symptômes liés à l’isolement des développeurs ?
Quel est le degré d’isolement des développeurs de votre équipe ? L’avez-vous déjà évalué ? Le faites-vous régulièrement ?
Pour cela, posez-vous les questions suivantes :
- Vos développeurs travaillent-ils avec des boucliers d’interaction sociale (A.K.A. casques audios) ?
- Entendez-vous du vocabulaire possessif au sein de l’équipe tel que “ton outil ne marche plus”; “mon code”; “j’ai fini ma story”; “ah non ! je ne toucherai pas à ça, c’est machin qui s’en occupe”; ”ce code/cette application/cet outil, c’est mon bébé !” 😱
- L’absence de certaines personnes clées peut-elle aboutir au blocage ou au ralentissement considérable de l’équipe ?
- Votre équipe peut-elle survivre avec 50% de l’effectif ?
- Est-ce que les développeurs sont capables de différencier le code qu’ils ont produits de celui des autres ?
Et l’”open space” dans tout ça ?
ATTENTION ! L’ “open space” ne guérit pas l’isolement, au contraire, il peut l’accroitre !
En effet, la plupart du temps, les open spaces sont trop grands, surpeuplés et mélangent des équipes qui n’ont aucune interaction entre elles. Le port du casque audio devient obligatoire et la communication au sein de l’équipe en pâtit.
Comment guérir la solitude des développeurs ?
Proximité et écoute
Peu importe votre méthode actuelle de travail, le coach, le scrum master ou le team manager doit être à proximité de l’équipe.
Quel que soit votre rôle dans l’équipe, restez à l’écoute. Intéressez-vous au travail des autres membres et aussi à leur humeur.
Déceler et répondre à la détresse d’un membre doit être la priorité du reste de l’équipe.
Pair Programming
Face à la solitude, le Pair Programming est la solution ultime. En travaillant par paires (qui changent régulièrement), les connaissances se propagent et s’harmonisent au sein de l’équipe.
On obtient rapidement des résultats de meilleure qualité avec moins de code.
Vous éviterez le problème classique de la personne “clée” qui découle de l’organisation en silo (un sujet <=> une personne)
L’intérêt principal est d’encourager naturellement l’équipe à s’approprier l’ensemble des produits tout en harmonisant la charge de travail.
Il ne sera plus nécessaire de bloquer certains sujets pendants les vacances de certains ou d’annuler les vacances des autres…
Code Review
Comparé au “pair programming”, le “code review” reste une alternative intéressante mais insuffisante. Elle peut être utilisée de façon temporaire pour mener une douce transition de l’équipe vers le “pair programming”.
Le “code review” peut donner un faux sentiment de confiance car le plus souvent, le “reviewer” ne rentre pas dans le détail de l’implémentation étant donné qu’il n’a pas suivi tout le cheminement logique du développeur.
Dans le pire des cas, il jouera le rôle d’un “linter” (analyseur syntaxique automatisé) et dans le meilleur des cas, il repèrera des améliorations pertinentes mais il sera souvent trop tard pour les mettre en place.
Encore pire, il sera parfois nécessaire de renoncer à ces améliorations afin d’éviter le conflit ou la démotivation.
Pour ceux qui pensent que le “pair programming” est une perte de temps, mesurez-vous les éléments suivants :
- Le temps de debug ;
- Le temps de “code review” et le coup de l’interruption associée ;
- Le nombre d’anomalies ignorées lors de la “code review” ;
- Le coup de la dette technique associée aux anomalies qui n’ont pas pu être rectifiées immédiatement ;
- Le temps de développement du code superflu (complexité artificielle ou fonctionnalités “false feature rich”) ?
Si oui, n’hésitez pas à nous faire part de votre expérience.
Stand-up meeting efficace
Le “stand-up meeting” ou “daily scrum meeting” etc… est un concept, commun aux équipes agiles ou quasi-agiles, qui encourage les développeurs à sortir de leur solitude. Toutefois, il est intéressant de profiter de cet article pour éclaircir certains point à ce sujet.
Dans une équipe agile équipée des bons outils, il n’est pas nécessaire de rappeler à chaque “stand-up meeting”, les tâches effectuées et celles à venir car tout le monde devrait être au courant de l’état du “backlog”, du “burn-up” etc…. En revanche, il est intéressant d’y partager ses émotions, expériences, difficultés, plaisirs, déplaisirs et surprises…
Le “stand-up meeting” devrait avoir une durée maximum de 15 minutes ; un “stand-up meeting” de 5 minutes n’est donc pas forcément un mauvais “stand-up meeting”.
Encouragez l’équipe à auto-réguler le temps de parole et à avoir une approche “peer-to-peer” et non de rapport à la hiérarchie.
Iteration Master
Pour lutter contre l’abnégation de certains, la timidité d’autres, ou plus simplement encourager l’appropriation collective du produit, pourquoi ne pas nommer aléatoirement un “iteration master” à chaque itération ?
Le rôle de l’”iteration master” est d’être le référent central et l’intermédiaire commun de l’itération pour toute l’équipe, pour le “product owner”, voire même pour les autres équipes.
Afin de pouvoir accomplir sa mission et répondre aux interrogations de tous, il est tenu de s’intéresser de plus près à l’ensemble du produit et des interactions associées.
Wishtack 