Gérer la dynamique de l’équipe de développement logiciel de l’intérieur
Ce qui distingue le développement de logiciels des autres secteurs, c’est que les perturbations dans la pratique sont la norme et que les personnes agissant de manière inhabituelle peuvent être une caractéristique et non un bug. Les problèmes des membres de l’équipe, comme l’inexpérience ou le désagrément, affectent chaque lieu de travail, et vous pouvez lire de nombreux ouvrages de gestion fastidieux sur la façon d’écraser avec diligence ces chevilles carrées dans leurs trous ronds. Mais les équipes logicielles agiles ont toujours été à la pointe de l’autonomie et n’attendent généralement pas les résolutions d’en haut – à supposer qu’il y ait un d’en haut. Peu de ce qu’ils font est mandaté, la plupart est convenu après avoir observé la pratique récente. C’est pourquoi ils ont un peu plus de responsabilité d’agir lorsqu’ils voient des problèmes dans la dynamique de l’équipe ou dans les relations de travail.
Comme la plupart d’entre nous, j’ai été à la fois un problème d’équipe et un résolveur de problèmes d’équipe à différents moments, donc je n’ai certainement pas l’intention de proposer des mesures disciplinaires ; si l’équipe peut reconnaître les problèmes potentiels dès le début, elle peut généralement simplement utiliser la puissance douce pour les écraser.
Cet article essaie de marquer différentes relations problématiques que j’ai vues plus d’une fois dans des équipes ou des projets logiciels. Je ne parle pas de problèmes verticaux (« Je déteste mon manager », etc.) mais de communication au niveau de l’équipe ou horizontale avec d’autres services homologues dans les grandes organisations. C’est par hasard qu’un autre article est récemment paru sur la gestion d’ingénieurs logiciels difficiles, mais je m’intéresse presque toujours à la dynamique entre deux parties. Je ne crois pas que les développeurs individuels aient un type permanent auquel ils adhèrent dans toutes les situations. Pourtant, parfois, les projecteurs tombent sur une personne et c’est ainsi que vous remarquez un problème pour la première fois.
Au cours de la communication
Un membre de l’équipe, probablement un homme, a tendance à trop communiquer avec enthousiasme. Autrement dit, il ne se tait pas et n’interrompt pas les autres. Cela bloque non seulement le passage de la conversation, mais aussi réduit la qualité du temps que l’équipe passe ensemble. Cela peut être un gros problème lors d’une rétrospective où les membres de l’équipe les plus introvertis décident que leur contribution doit passer au second plan. À la lumière froide du jour, cela signifie simplement que des informations sont perdues – et cela ne doit pas être toléré à la légère.
Le problème n’est pas « possédé » par le sur-communicateur, cependant. Le style contradictoire d’une salle d’audience fonctionne parce que le juge dirige soigneusement le temps et l’orientation des arguments. Peu importe qu’un avocat ait raison ou qu’il soit plus charmant ; une fois debout, les arguments doivent être concentrés, précis et répartis dans le temps. L’équipe, probablement par l’intermédiaire du chef d’équipe, a la responsabilité de modérer toutes les réunions. Si vous ne parvenez pas à gérer un seul membre vocal de l’équipe, alors la dure tâche consistant à fabriquer des produits à contre-courant vous semblera vraiment difficile. Une réunion d’équipe n’est pas un confortable salon parisien du XVIIIe siècle ; c’est un lieu de travail. Désolé.
Vie de salon
Adolescent avec les clés de voiture
La plupart des problèmes avec les équipes sont des ruptures de confiance. Lorsqu’une personne gère un système, elle peut être perturbée par un utilisateur négligent. La situation typique est celle où un gestionnaire de services pense qu’un de ses utilisateurs ouvre trop de ressources sans les fermer par la suite. Cela peut conduire à la confiscation des clés de l’adolescent.
En fin de compte, vous devez faire confiance à l’adolescent car c’est le seul moyen de franchir la barrière de l’expérience. Et un service est conçu pour être utilisé. Néanmoins, un mauvais pilote est un bon test pour les limites d’un système. Les ressources valorisées doivent être auditées. Les nudges, comme les e-mails rappelant à l’adolescent et à son responsable les ressources ouvertes à long terme, sont un moyen judicieux de gérer cela. Habituellement, un mauvais conducteur passe rapidement à un meilleur conducteur – ou connaît une fin difficile. Mais un système rigide finira par en accrocher d’autres. Le pire résultat serait que l’expérience avec un mauvais conducteur amène un administrateur système à exclure davantage de jeunes conducteurs.
Devoir serrer les dents pour surmonter l’apparente inconscience d’un coéquipier n’est pas quelque chose à ignorer – cela doit simplement être mis en perspective. Contrairement à un accident de voiture, une mauvaise utilisation d’un logiciel ne devrait être ni fatale ni trop coûteuse. Mais il faut bien sûr le noter.
Test échoué
Sous rapport
Ce n’est pas le contraire d’une communication excessive. Il s’agit d’une décision d’édition consciente, prise par les membres de l’équipe, que leur équipe n’a pas besoin d’entendre ou n’appréciera pas certains des détails qu’ils connaissent.
L’un des problèmes courants dans ce domaine est la mauvaise relation entre un chef de projet et un développeur principal. Le responsable ne regroupe tout simplement pas les problèmes en morceaux de la bonne taille pour être digérés par un responsable occupé. L’introduction dramatise les petits problèmes et laisse de côté les fissures croissantes. Et le manager est trop peu curieux pour vérifier.
Mais un problème similaire se produit au sein des équipes, que l’agilité ne fait qu’amplifier si divers signaux sont supprimés. L’inconfort, la confusion ou les soupçons concernant une tâche ne doivent pas être cachés. Mais ces sentiments peuvent être cachés par un récit ou un résumé sec.
Les exemples incluent des résumés tels que «Je me suis connecté à la base de données» qui oublient d’ajouter à quel point il a été difficile de trouver les informations d’identification ou que l’autorisation d’un tiers a été demandée de manière inattendue. Cela fait perdre du temps au prochain membre de l’équipe qui a besoin de la connexion. Il existe probablement un environnement dans lequel tout le monde est un héros, donc ignorer les problèmes d’efficacité fait preuve de courage. Mais dans ce cas, cela cache simplement l’absence d’un wiki d’équipe ou d’un radiateur d’informations similaire.
Parfois, tout le monde utilise un outil lent, mais supposez simplement que c’est le coût de faire des affaires. Donc personne n’en parle comme d’un bloqueur. Lorsque ce type de problème est détecté, l’équipe doit repenser ses actions dans le temps pour voir dans quelle rétrospective passée, un meilleur reporting aurait pu sauver la situation.
Le nouveau pousseur
Dans la plupart des cas, toute l’équipe aura intérêt à essayer de nouveaux outils ou services de temps en temps, simplement pour comprendre les modèles et les tendances. Nous savons que nous devrions toujours accroître l’automatisation. Cependant, en particulier avec des éléments tels que les frameworks JavaScript, le New Pusher fait un bond en avant – trop enclin à adopter le nouveau alors qu’il n’existe aucune preuve que les gains valent le coût de la perturbation. Ou pire, ignorer complètement le coût de la perturbation.
Le New Pusher peut inciter l’équipe à rechercher le chemin non emprunté, au lieu de faire ce qu’elle devrait faire, et à enquêter un peu pendant son temps libre pour voir comment l’équipe bénéficiera réellement de sa brillante trouvaille.
Lorsqu’elle envisage d’adopter un nouvel outil ou service, l’équipe ne doit pas le tester dans un endroit sans conséquence, car cela ne serait ni concluant ni bénéfique. Une courte période d’examen ou d’étude devrait conduire à une décision oui/non et à l’utilisation de l’outil ou de la plateforme dans un endroit utile. Une fois le modèle défini, le nouveau pousseur peut travailler sur ce modèle.
Le soupçon selon lequel les gens veulent simplement mettre de nouvelles expériences sur leur CV est un peu hors de propos. La capacité de filtrer les chemins possibles pour des raisons solides devrait être un muscle d’équipe, même si la décision finale peut revenir au leader. Un grand nombre d’options apparentes peuvent certainement être paralysantes, c’est pourquoi il est essentiel d’évaluer rapidement ce que vous attendez vraiment de votre chaîne d’outils, ce qui manque éventuellement et ce qui n’est qu’un battage médiatique que vous n’avez pas demandé et dont vous n’avez pas besoin.
Brillant!
Dans l’ensemble, toutes les équipes ont des problèmes mineurs qui représentent simplement les merveilles de travailler avec d’autres personnes. Malheureusement, les équipes logicielles ne sont pas des mini ligues de gentlemen extraordinaires, ce sont simplement des gens ordinaires à qui on demande d’exceller plusieurs heures par semaine. Cela signifie qu’une vigilance éternelle est requise, et non des détectives occasionnels. Oui, le chef d’équipe doit assumer l’essentiel de la responsabilité de maintenir la bonne dynamique, mais il doit vraiment agir comme le phare. Être une bonne équipe est ce que tous les membres de l’équipe devraient être.
