Penser globalement, programmer localement : le secret des équipes distribuées

Les équipes distribuées et les bureaux distants ne sont pas en voie de disparition. Mais est-il possible de les intégrer à une culture agile prospère ? Nous pensons que oui.

Dan Radigan Dan Radigan

À l'origine, le développement Agile a été imaginé à l'attention des équipes groupées en clusters ou physiquement réunies dans un même bureau. Étant entendu que « la méthode la plus efficace et la plus productive pour transmettre des informations à et au sein d'une équipe de développement est la conversation en face à face », les premières équipes Agile ont dû commencer à travailler en étroite proximité.

Mais aujourd'hui, la plupart des entreprises comptent avec quelques, voire de nombreuses, équipes distribuées. Ce n'est pas une simple tendance. C'est du bon sens. Les équipes distribuées peuvent travailler sur les projets en continu. De plus, il existe des talents exceptionnels sur des marchés moins compétitifs. (Il est aussi plus facile de les retenir en n'exigeant pas leur déménagement contre leur volonté.) Mais les avantages des équipes distribuées impliquent certains compromis. Pour beaucoup de ces équipes distribuées, il est évidemment difficile d'adopter les interactions en face à face, une pratique agile.

Autres défis liés aux équipes distribuées de développement logiciel :

  • Coordination entre différents fuseaux horaires
  • Établissement de liens entre des personnes qui ne travaillent pas dans le même bureau
  • Collaboration entre différentes cultures de développement
  • Organisation de réunions ou de conversations informelles lorsque les deux équipes sont en ligne en même temps pendant quelques heures seulement (voire moins)

Ces problèmes sont réels. Mais pas impossibles à résoudre. Examinons différentes stratégies qui permettent de combler le fossé de la distance entre les bureaux locaux et les bureaux distants, ainsi que quelques idées pour limiter d'autres problèmes potentiels.

Comment structurer les équipes globales

Une bonne architecture logicielle impose une conception modulaire. Vous devez donc structurer vos équipes de la même façon. Chaque bureau doit être autonome pour le développement d'un composant technologique unique, ce qui limite la collaboration requise avec des équipes situées dans d'autres fuseaux horaires. Cela leur permet de travailler en autarcie. Lorsqu'un projet nécessite l'intervention d'équipes situées sur d'autres sites, celles-ci peuvent se concentrer sur leurs points d'intégration et leurs API.

Les revues du code jouent également un rôle important. Comme les équipes se connectent à des horaires différents, la connaissance distribuée du code entre les bureaux facilite considérablement le support et la maintenance. Si un ticket de production est créé alors que l'équipe n'est pas en ligne, un autre bureau peut facilement intervenir et le résoudre, grâce au savoir-faire acquis des revues du code entre équipes et entre sites.

Établir des liens

Il est important dans n'importe quel programme, en particulier dans les programmes agiles, d'établir des liens solides au sein de l'équipe. Les liens personnels renforcent la confiance, limitent les déceptions au niveau des attentes, favorisent l'autonomie et dopent le moral. Au sein de vote bureau, prenez le temps d'apprendre à connaître tous les membres de votre équipe. Et, dans la mesure du possible, faites de même avec les employés des bureaux distants. Les liens personnels sont essentiels. Plus ces liens sont forts, plus vous considérerez ces collègues comme d'autres collègues, et non plus comme de vagues collaborateurs distants, sur des sites dont vous ne savez rien, avec qui vous n'entretenez pas spécialement de bonnes relations.

Pro Tip:

Chez Atlassian, chaque nouvel employé publie un « billet de présentation » sur notre instance interne de Confluence, l'outil d'Atlassian pour la collaboration autour du contenu. Ce billet décrit la nouvelle recrue d'un point de vue professionnel, mais également personnel (loisirs, intérêts, famille, etc.), ce qui contribue réellement à tisser des liens entre les différents bureaux. Plus nous apprenons à nous connaître les uns les autres en tant que personnes, mieux nous travaillerons ensemble en tant qu'équipes. 

Surtout, rien ne remplace les entretiens en face à face. Dans chaque bureau, les membres de l'équipe retireront certains avantages d'échanges réguliers en face à face, y compris par visioconférence ou grâce aux déplacements dans les bureaux distribués.

La visioconférence contribue énormément à combler le fossé entre les équipes, en particulier dans le cas d'équipes agiles distribuées. Cependant, les équipes qui ont recours à la visioconférence doivent être conscients de certaines de ses limites.

  • La visioconférence n'offre qu'une fenêtre de communication très courte, alors que le fait de travailler dans le même bureau donne une visibilité importante sur le monde de l'autre : défis, réussites et opportunités.
  • Des problèmes de réseau surviennent entre les bureaux. Le son est haché, la vidéo est brouillée et les conversations sont difficiles à comprendre.
  • La visioconférence est encore généralement considérée comme une activité planifiée. Il faut du temps pour instaurer une culture où la conversation vidéo est utilisée pour des discussions informelles et spontanées.

Afin de limiter certains problèmes liés à la visioconférence, encouragez les membres de l'équipe à organiser des sessions hebdomadaires de conversations vidéo individuelles. Moins formelles, celles-ci facilitent le partage des connaissances de façon plus décontractée. Les membres de l'équipe peuvent profiter de ces occasions pour établir des liens et mieux travailler ensemble. 

N'oubliez pas, le ton, la voix et la posture jouent un rôle important dans la communication. Les échanges en personne permettent à l'équipe de connaître leurs collègues à distance avec une plus grande fidélité, ce qui renforce l'efficacité des sessions de visioconférence ultérieures.

Que ce soit pour une maison ou un produit, vous devez définir la vision et mettre en évidence les thèmes stratégiques. Envisagez les thèmes comme des domaines d'amélioration à l'échelle de l'organisation. Sur quoi souhaitez-vous vous concentrer au cours du prochain trimestre, des 6 prochains mois, de l'année prochaine ? À quels niveaux voulez-vous consacrer du temps et des ressources ? Performances, expérience utilisateur, sécurité, nouvelles fonctionnalités compétitives (quelqu'un a parlé d'un jacuzzi ?) ou une combinaison de tous ces éléments ?

How we do it:

Les détachements sont des missions temporaires sur un nouveau poste ou un nouveau site, qui s'étendent de quelques semaines à un an. Non seulement ils constituent un moyen efficace d'établir des liens et de diffuser la culture au sein de l'équipe, mais c'est également une excellente façon de découvrir une culture différente. 

Développer une culture de développement unifiée

Quatre méthodes simples permettent aux équipes de faciliter le travail entre différentes zones géographiques et de partager une culture de développement commune :

  • Communiquer en permanence les décisions entre les différentes zones géographiques
  • Minimiser les frictions dans la mise en place de l'environnement de développement
  • Définir clairement la notion de « terminé »
  • Élaborer des directives pour remplir des rapports de bogues efficaces

Décomposons tout cela.

D'abord, lorsque vous passez d'un bureau mitoyen à une culture distribuée, la communication devient beaucoup plus difficile. Le premier défi consiste à former l'équipe afin qu'elle comprenne que, lorsque des décisions sont prises, celles-ci doivent être communiquées. Cela semble aller de soi, mais c'est tellement facile à oublier ! Souvent, les décisions importantes sont prises dans un couloir, lors de réunions informelles de l'équipe locale, voire de façon complètement individuelle. De plus, certaines décisions sont facilement considérées comme peu importantes. 

Communiquez même les moindres détails jusqu'à ce que les deux bureaux trouvent leur rythme commun.

Lorsque des décisions sont prises, chaque employé du bureau doit comprendre ces décisions et, dans l'idéal, la raison pour laquelle elles ont été prises. N'utilisez pas l'e-mail. Il est trop facile de perdre des informations importantes. Utilisez un système de gestion des contenus, tel qu'un wiki, où les membres de l'équipe peuvent facilement rechercher les dernières informations au sein de l'équipe (et être alertés des mises à jour par e-mail ou par le biais de leur outil de messagerie de groupe). Lorsque des membres de l'équipe travaillent sur des informations obsolètes et rencontrent un problème qui les bloque, ils posent des questions et font perdre à l'équipe beaucoup plus de temps qu'avec un partage proactif des informations.

Ensuite, un environnement de développement homogène pour l'ensemble de l'équipe facilite la collaboration et le suivi des problèmes. Passez un peu de temps à élaborer un guide de démarrage simple et apprivoisez les frictions initiales en automatisant la mise en place au maximum.

De plus, lorsque vous travaillez entre plusieurs bureaux, une définition claire de la notion de « terminé » permet de gérer plus facilement les attentes et d'établir des liens entre les équipes. Une définition incontestable de cette notion élimine toute ambiguïté dans le travail. En l'occurrence, lors de l'expédition d'une livraison impliquant plusieurs équipes, expliquez clairement à quel moment elle sera considérée comme « terminée » : code créé, pull request créée, code révisé, testé et mergé dans la branche appropriée.

Et enfin, un développement distribué signifie que tout le monde n'est pas en ligne au moment où un problème survient. L'élaboration de directives claires pour les rapports de bogues et le dépannage simplifie, pour tous les membres de l'équipe, le suivi des problèmes. La revue de code et de bons tests automatisés permettent également de partager les connaissances liées à la base de code. L'équipe concernée est alors habilitée à corriger les problèmes et à confirmer toute absence d'effets secondaires indésirables en cas de changement. Autrement dit, aucune équipe ne devient un blocage pour les autres. 

Maximiser les meilleures heures

Tout photographe connaît ces « meilleures heures », juste avant et après le lever et le coucher du soleil, et sait que ce sont des moments idéaux pour prendre de superbes photos de paysage. Pour les équipes distribuées de développement logiciel, les meilleures heures correspondent aux moments où les équipes locales et distantes sont dans leurs bureaux respectifs au même instant. Lorsque toutes les équipes sont dans les bureaux, c'est une excellente occasion d'organiser des stand-ups.

For teams that share work between time zones, stand-up is a great time to pass the baton so the team just coming online can pick up where the other team left off. And holding stand-up via video conference makes it easy to ask questions and get up to speed so everyone is off and running as soon as the meeting is done.

Dans certains cas, les bureaux sont tellement éloignés l'un de l'autre que les réunions peuvent s'avérer douloureuses pour l'une des équipes. (Se lever à 5h pour participer à un stand-up avec l'autre équipe ? Mmmm....non merci.) Changez régulièrement l'heure de la réunion afin que cette douleur soit partagée, plutôt que d'imposer sans arrêt les mauvais horaires à l'équipe distante, ce qui serait la meilleure façon de leur détruire le moral. Surveillez étroitement l'engagement de l'ensemble de l'équipe lors du stand-up. Si l'équipe ressent une tension inutile ou si elle n'en retire pas de réels avantages, les membres de l'équipe commenceront à se désinvestir et cesseront d'écouter ou de partager. Par ailleurs, le stand-up ne doit pas forcément être quotidien. Organisez cette réunion avec l'équipe distante plusieurs fois par semaine et avec l'équipe locale les autres jours. De même, le stand-up ne doit pas forcément avoir lieu le matin. Le meilleur moment est celui qui convient à toutes les parties impliquées. 

Chaque équipe est distribuée

In a distributed organization, the reality is that every team is remote. All teams need to adapt and learn how to share work between offices, communicate effectively, and grow a consistent culture across geographies. The most effective teams don't just make the remote office conform to the headquarter's culture because they understand that every office can learn something from the others. They seek to find and share successful practices across all locations. They also embrace "we" rather than an "us vs. them" culture.

En effet, la réalité, c'est aussi qu'elles deviennent distribuées de temps à autre. Les déplacements professionnels obligent les employés à quitter le bureau. Et parfois, le travail à domicile peut aider les employés à mieux gérer leur équilibre entre vie personnelle et vie professionnelle. Les équipes qui adoptent à la fois la structure et la transparence grandissent et s'adaptent de façon plus efficace. Lorsque votre projet s'étend au-delà de votre bureau, la culture impose naturellement les attitudes correctes.