À 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.
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.
Les outils de vidéoconférence comme Zoom contribuent à combler le fossé entre les équipes, en particulier dans le cas d'équipes Agile distribuées. Cependant, les équipes qui ont recours à Zoom doivent être conscientes de certaines de ses limites.
- La vidéoconférence n'offre souvent 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, ses défis, ses réussites et ses opportunités.
- Zoom a parfaitement réussi à résoudre les perturbations du réseau. Cependant, des problèmes peuvent parfois survenir entre les bureaux. Le son est haché, la vidéo est brouillée et les conversations sont difficiles à comprendre.
- La vidéoconférence Zoom est encore généralement considérée comme une activité planifiée. Il faut du temps pour instaurer une culture où le chat vidéo est utilisé pour des discussions informelles et spontanées. Aussi, utilisez des outils de messagerie instantanée, comme Slack, pour les questions rapides.
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 ?
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.
Dans un premier temps, lorsque vous passez d'un bureau colocalisé à 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 les comprendre et, dans l'idéal, saisir leur raison d'être. N'utilisez pas les e-mails. Il est trop facile de perdre des informations importantes. Utilisez un système de gestion de contenu, 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, Slack). Vous pouvez également utiliser Slack pour créer des chaînes permettant aux individus et aux équipes de communiquer et de voir les mises à jour. 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.
Chez Atlassian, nous utilisons Atlas pour partager des mises à jour sur les projets et les objectifs dans les équipes. Nous sommes informés des dernières actualités par un e-mail récapitulatif quotidien ou via Slack. Cela permet à nos équipes de communiquer de façon ouverte et d'acquérir une compréhension commune du contexte de leur travail, afin de répondre aux questions suivantes :
- Que sommes-nous en train de faire ?
- Pourquoi ?
- Qui travaille sur quoi ?
- Avancement du travail
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 la livraison d'une version 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 bug 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 bloqueur 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.
Pour les équipes qui partagent leur travail entre différents fuseaux horaires, le stand-up est l'occasion rêvée pour passer le témoin. L'équipe qui vient de se connecter peut prendre le relais de l'autre. De plus, l'organisation d'un stand-up par vidéoconférence permet de poser des questions facilement et d'obtenir des informations. Chacun est alors opérationnel dès la fin de la réunion.
Dans certains cas, les bureaux sont tellement éloignés l'un de l'autre que les réunions peuvent s'avérer difficiles pour l'une des équipes. (Se lever à 5 h pour participer à un stand-up avec l'autre équipe ? Mmmm… non merci.) Changez régulièrement l'heure de la réunion afin que ce fardeau soit partagé, plutôt que d'imposer sans arrêt des horaires bizarres à l'équipe distante, ce qui serait la meilleure façon de lui saper le moral. Surveillez étroitement l'engagement de l'ensemble de l'équipe lors du stand-up. Si l'équipe ressent une tension inutile ou qu'elle n'en retire pas de réels avantages, ses membres 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
Dans une organisation distribuée, en réalité, chaque équipe est distante. Toutes les équipes doivent s'adapter et apprendre à partager leur travail entre les différents bureaux, à communiquer efficacement et à développer une culture homogène entre les différentes zones géographiques. Les équipes les plus efficaces ne se contentent pas d'assurer la conformité du bureau distant à la culture du siège social. Elles savent que chaque bureau peut apprendre quelque chose des autres bureaux. Elles cherchent à identifier et à partager les pratiques efficaces entre les bureaux. Elles adoptent également une culture du « nous », plutôt que du « eux contre nous ».
En réalité, elles sont aussi 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.