Agile, équipe distribuée

1. L'équipe agile distribuée
Scott W. Ambler
Les problèmes de communication sont votre principal risque.
Scott examine les mythes entourant le développement logiciel agile.
Scott travaille en qualité de Practice Leader Agile Development pour IBM Rational.
Traduction par Emmanuel Hugonnet de l’article The Distributed Agile Team avec l’aimable
autorisation de Scott Ambler et de Jon Erickson du Dr. Dobb’s Journal.
Parmi les mythes qui entourent l'agilité, celui qui laisse à penser qu'elle ne s'applique qu'à de petites
équipes regroupées géographiquement reste largement diffusé. L'étude Dr. Dobb's 2008 Agile
Survey (www.ddj.com/architect/207600615) a prouvé le contraire, les réponses indiquent, en effet,
que les stratégies agiles sont appliquées avec succès par des équipes comptant plus de 200 membres
et qu'une grande part des équipes agiles sont distribuées. Dans l'article "Agile Large Teams"
(www.ddj.com/architect/208700162), j'ai proposé différentes stratégies pour organiser de grandes
équipes agiles, et ce mois-ci je vais vous décrire les expériences vécues au sein d'une équipe de
développement IBM, à la fois distribuée et agile.
Si un membre de l'équipe travaille à un autre étage, ou depuis chez lui, ou dans un autre bâtiment
que le reste de l'équipe, alors votre équipe est distribuée. La Figure 1 résume les résultats de l'étude
Dr. Dobb's 2008 Agile Survey, qui montrent que les chances de succès se réduisent avec la
distribution géographique de l'équipe. Bien que cela soit alarmant, ce n'est pas surprenant – plus
grande est la distribution et plus élevé est le risque. Cependant, il faut noter que beaucoup d'équipes
arrivent avec succès à développer en mode agile distribué.
Comprendre les risques
Le taux de réussite moins élevé des équipes de développement distribuées vient principalement des
problèmes de communication qui augmentent. Même dans le cas où l'équipe est distribuée sur un
même site et peut facilement se réunir si le besoin s'en fait sentir, il existe des risques de
communication comme le fait d'avoir des priorités différentes, ou sur la compréhension des
exigences. De nombreuses entreprises vont utiliser le papier et demander à ce qu'on écrive des
spécifications détaillées pour se prémunir contre de tels risques, mais comme la théorie sur la
richesse des média l'a montré depuis des années, la documentation est le moyen le moins efficace
pour communiquer entre personnes, et peut même augmenter le risque.

2. Figure 1 : Taux de réussite des projets pour les équipes agiles distribuées. Plus une équipe est distribuée et plus le
risque d'échec de votre projet augmente.
Les projets dont les membres de l'équipe sont loin les uns des autres, où il faut passer par l'avion
pour réunir l'équipe, peuvent souffrir des décalages horaires et des différences culturelles. Pour
minimiser ces risques, j'ai pour habitude de poser des questions ouvertes pour savoir si les autres
comprennent ou non le sujet de la conversation. En particulier, je ne pose jamais de question dont la
réponse est oui ou non, car un 'oui' peut avoir une variété de sens selon la culture :
 Oui, je vous entends
 Oui, je comprends ce que vous dites
 Oui, je comprends et je suis d'accord avec vous
Lorsqu'il faut travailler avec des personnes distantes, il est recommandé de leur demander de
résumer la conversation par écrit, même si c'est un simple courriel avec une liste de points/choses,
pour valider la compréhension commune des décisions.
Le manque de confiance dans les capacités de ceux avec qui vous ne travaillez pas directement ou
que vous ne connaissez pas bien, est aussi un problème, cela devient particulièrement vrai lorsque
plusieurs services ou entreprises sont concernés. Cette méfiance transparaitra sous la forme de
spécifications détaillées à écrire et valider pour les personnes distantes, du temps passé sur l'aspect
légal des contrats entre entreprises, et au contraire du manque de discussions sur le processus suivi
par 'chaque coté'. Ayant été consulté par de nombreuses SSII, ainsi que par leurs clients, je peux
assurément dire que tous ceux qui se retrouvent impliqué dans un projet off-shore bénéficieraient
grandement de discussions franches et ouvertes sur leur véritable manière de travailler. La plupart
des SSII aimeraient fournir une meilleure qualité de service à leurs clients en travaillant de manière
plus agile, mais elles croient à tord que leurs clients veulent travailler de la manière bureaucratique
traditionnelle. De la même façon, leurs clients croient que les SSII ne peuvent travailler ainsi,
pensant à tord qu'une entreprise respectant CMMI ne peut être agile. Mon conseil en la matière est
de parler à votre partenaire, et de voir ensemble comment travailler plus efficacement.
Pour illustrer mon conseil je veux partager avec vous certaines de mes expériences avec une équipe
de développement d'IBM travaillant sur un outil de gestion de projet par les métriques de nouvelle
génération, autour de la technologie de la plateforme Jazz (www.jazz.net) et qui permet de
réconcilier les différentes méthodologies de gestion de projet: agile, traditionnelle, hybride et tous
les niveaux intermédiaires. L'équipe projet se compose actuellement de 30 membres repartis sur
Bangalore, Boston et Toronto. Les itérations se font à une fréquence d'une toutes les trois semaines,
avec une démonstration interne hebdomadaire pour s'assurer un retour régulier des parties-prenantes
distribuées, et une revue de l'état d'avancement toutes les six semaines pour maintenir leur

3. hiérarchie informée.
Démarrer un Projet Agile Distribué
Une des toutes première choses par laquelle une équipe agile disciplinée va commencer – et c'est
d'autant plus vrai pour une équipe distribuée – est de modéliser une vision globale à la fois de
l'architecture et des exigences. Dans le cas de notre équipe projet, elle a identifié avec le
responsable produit une liste des principales histoires d'utilisateur ce qui lui a permis de définir le
périmètre initial, et à partir de celui-ci elle s'est donnée une direction pour son architecture
technique en définissant les principaux concepts architecturaux. Commencer par concevoir
l'architecture permet à l'équipe distribuée de s'organiser efficacement comme nous le verrons par la
suite.
Les équipes agiles disciplinées commencent aussi par une planification de haut niveau afin
d'identifier les dépendances importantes et les dates de livraison – vous n'avez pas besoin d'un
diagramme de Gantt monolithique avec plus de 1000 tâches, mais vous devez avoir réfléchi à tout
cela. Les équipes efficaces intègrent activement les développeurs dans la mise au point de cette
planification (ils font partie de la même équipe après tout), en effet, ils font tout leur possible pour
prendre en compte tous les coûts associés, et en particulier ils n'oublient pas les risques à faible
probabilité mais fort impact qui sont souvent à l'origine de la mort des projets.
Regrouper l'ensemble de l'équipe physiquement au lancement du projet est aussi une stratégie
essentielle. Ainsi cela vous permet de créer des liens entre les membres de l'équipe, de connaître les
personnes avec qui vous allez travailler ce qui facilitera la communication par la suite, et de mieux
comprendre la situation sur le terrain. C'est sûr que de regrouper les gens en les faisant venir par
avion augmente les coûts initiaux, cependant c'est un investissement qui sera rapidement rentabilisé
par la réduction des risques encourus. Dans mon expérience ce qui coûte moins cher dans ces
voyages est de le faire, alors que cela coûte plus cher de ne pas les faire ce qui augmente les risques
liés à la communication par la bureaucratie et la documentation. Hélas cette stratégie est souvent
sacrifiée sur l'autel du gain financier à court terme, aux dépends des risques pris sur le projet.
Organiser une équipe agile distribuée
Une bonne pratique pour organiser les équipes distribuées, décrite dans "Lean Developement
Gouvernance", est d'organiser votre équipe selon l'architecture afin de réduire les communications
entre les différentes sous-équipes. Lorsque l'on analyse les flux de communication dans une équipe
de développement logiciel, on s'aperçoit que la majorité des échanges se fait entre les personnes qui
réalisent ensemble un sous-système, aussi organiser votre équipe en suivant l'architecture réduit les
risques liés à la communication. C'est l'une des raisons pour laquelle il faut commencer par
modéliser l'architecture – en identifiant les sous-systèmes, et en investissant un peu de temps pour
définir les interfaces de chacun d'entre eux, vous permettez à vos sous-équipes de se concentrer sur
leur tâche. Les responsables de l'architecture de chacun des sous-systèmes doivent se coordonner
pour modifier les interfaces ensembles, c'est un sujet que je décris en détail dans mon article de
Juillet 2008 (www.ddj.com/architect/207600615). Cette manière de gérer l'architecture s'appelle
'API First' dans Eclipse Way, une méthodologie agile pour les équipes distribuées.
Une grave erreur serait d'organiser l'équipe autour des spécialités techniques, par exemple avoir une
équipe d'analystes métier, une équipe de concepteurs, une équipe de testeurs, etc. et de faire transiter
les tâches entre ces équipes de spécialistes. Cette stratégie augmente la bureaucratie, donc le coût,

4. car il devient nécessaire d'écrire plus de documentation, de tenir plus de revues de documentation,
de fournir plus d'efforts en termes de traçabilité, etc. pour permettre à cette organisation d'équipe de
fonctionner. Cela a aussi pour effet de favoriser le rejet de la faute sur les autres équipes en cas de
problème – un logiciel qui fonctionne est nettement plus concret et mesurable que de la
documentation, ce qui facilite la tâche lorsqu'il s'agit de déterminer la valeur produite par une
équipe, ou son absence.
Le seul cas où vous pouvez briser cette règle, serait le cas d'un projet off-shore avec des tests
indépendants, comme décrit dans "Scaling Test-Driven Development"
(www.ddj.com/architect/205207998), lorsque vous avez une petite équipe de testeurs de qualité
pour réaliser des tests complexes en parallèle des développements. Avoir une petite équipe qui
réalise les tests en parallèle des développements sur le site du client permet au client de suivre
l'avancement du projet et la qualité du travail fourni par l'équipe tout en limitant le besoin de
spécifications détaillées, de revues couteuses des livraisons tout au long du projet, et de la longue
phase de tests à la fin du projet (il faut tester à la fin du projet mais ce n'est pas du même ordre de
grandeur).
Gérer un projet agile distribué
La différence entre le fonctionnement de l'équipe d'IBM et d'une équipe agile regroupée est très
similaire. Ils commencent une itération avec une session de planification durant laquelle l'équipe
identifie les tâches à réaliser durant cette itération et qui fait quoi. Ces sessions de planification
comprennent la phase de modélisation durant laquelle chaque histoire d'utilisateur est élaborée par
ceux qui vont la réaliser. Le but de tout ceci est de creuser suffisamment les détails de réalisation
pour pouvoir planifier l'itération efficacement, même si la modélisation sera détaillée plus en
profondeur lors de l'itération selon les besoins.
Les réunions express quotidiennes1
se passent légèrement différemment pour les équipes distribuées
par rapport aux équipes regroupées. Les personnes qui sont dans un même lieu géographique
tiennent leur réunion debout quotidienne durant laquelle ils échangent les informations de bases –
ce qu'ils ont fait depuis la dernière réunion debout, ce qu'ils espèrent réaliser d'ici à la prochaine, et
s'il existe des éléments bloquants. Ensuite des représentants pour chaque réunion, se réunissent pour
se coordonner. Si la réunion quotidienne debout est la première chose à faire le matin en arrivant, la
réunion de coordination doit, elle, prendre en compte les fuseaux horaires. Une bonne pratique
consiste à faire tourner l'heure de la réunion de coordination, de manière à répartir l'effet des
différents fuseaux horaires.
Les équipes distribuées ont besoin de meilleurs outils que les équipes regroupées car les fiches, les
tableaux d'affichage, et les tableaux blancs ne fonctionnent pas bien en mode distribués. Une option
est d'intégrer un ensemble d'outils libres, une autre est d'accepter la perte de productivité liée à
l'hétérogénéité de ces outils, enfin une troisième option est d'adopter des outils dédiés à un
développement distribué. L'équipe projet d'IBM utilise le produit Rational Team Concert (RTC),
téléchargeable sur www.jazz.net, qui fournit un environnement de développement intégré complet
et distribué (Integrated Distributed Development Environment) permettant la gestion distribuée des
exigences et des défauts, de savoir si un membre de l'équipe est disponible et de pouvoir discuter en
ligne avec lui avec une traçabilité complète, et la gestion des processus. L'équipe a choisit d'investir
dès le début dans l'automatisation pour pouvoir supporter la vitesse de développement et le volume
des modifications. RTC n'est pas simplement dédié aux développeurs, il peut aussi fournir un
ensemble de graphiques qui permettent de suivre en temps réel l'état du projet notamment au
1
N.d.T.: Daily Stand up Meeting

5. travers des graphes de reste à faire, de tendance des défauts, d'état du 'build', et des statistiques
d'allocation des ressources qui se basent sur les véritables activités des membres de l'équipe (à
l'opposé des activités rapportées par l'équipe qui oublient souvent des points critiques). L'intégration
de cet outil réduit très fortement la nécessité de rapporter pour l'équipe ce qui lui permet de se
concentrer sur les tâches de développement, et fournit les informations nécessaires aux
gestionnaires à distance du projet.
Enfin, deux autres pratiques critiques pour les équipes de développement agile distribuées sont
d'avoir des ambassadeurs et des médiateurs. Les ambassadeurs sont des experts séniors techniques
ou métier qui passent d'un site à l'autre en échangeant avec les différentes sous-équipes. Réunir
l'équipe au complet au début du projet a créé les bases d'une bonne communication, mais sans un
investissement régulier pour maintenir une collaboration efficace entre les équipes vous risquez de
voir vos sous-équipes dévier de la stratégie globale. Les médiateurs sont ceux qui sur le site
facilitent la communication entre les membres de la sous-équipe et entre les sous-équipes. On en
retrouve classiquement sous trois formes – les responsables qui gèrent le projet de la sous-équipe,
les responsables produit qui représentent le métier dans la sous-équipe, et les responsables de
l'architecture qui donnent la direction technique des développements. Ces médiateurs vont travailler
en étroite collaboration avec leurs pairs, se réunissant régulièrement pour se coordonner entre sous-
équipes, ainsi que des réunions impromptues à quelques uns pour résoudre des problèmes
spécifiques.
Plus la distribution géographique est importante plus la
discipline doit être forte
Sur un projet distribué, agile ou non, la communication est le risque le plus important. La bonne
nouvelle vient du fait que les méthodes agiles mettent l'accent sur la communication et la
collaboration, c'est déjà un premier pas dans la bonne direction. Accepter d'investir dans les
voyages, faire un peu plus de modélisation dès le début du projet, organiser votre équipe autour de
l'architecture, et adopter des outils plus sophistiqués sont les clefs du succès en mode agile
distribué. Si vous souhaitez de plus amples informations je suggère de consulter le livre rouge
d'IBM intitulé "Global Development and Delivery in Practice: Experiences of the IBM
Rational India Lab" (www.redbooks.ibm.com/abstracts/sg247424.html). Je trouve cette approche
un peu trop lourde à mon goût mais c'est écrit par des personnes avec des années d'expérience dans
le développement distribué géographiquement.
Remerciements
Je voudrais remercier Rajesh P Thakkar, Lead Architect au laboratoire logiciel d'IBM à Bangalore,
pour ses informations inestimables qui ont permis cet article.

6. travers des graphes de reste à faire, de tendance des défauts, d'état du 'build', et des statistiques
d'allocation des ressources qui se basent sur les véritables activités des membres de l'équipe (à
l'opposé des activités rapportées par l'équipe qui oublient souvent des points critiques). L'intégration
de cet outil réduit très fortement la nécessité de rapporter pour l'équipe ce qui lui permet de se
concentrer sur les tâches de développement, et fournit les informations nécessaires aux
gestionnaires à distance du projet.
Enfin, deux autres pratiques critiques pour les équipes de développement agile distribuées sont
d'avoir des ambassadeurs et des médiateurs. Les ambassadeurs sont des experts séniors techniques
ou métier qui passent d'un site à l'autre en échangeant avec les différentes sous-équipes. Réunir
l'équipe au complet au début du projet a créé les bases d'une bonne communication, mais sans un
investissement régulier pour maintenir une collaboration efficace entre les équipes vous risquez de
voir vos sous-équipes dévier de la stratégie globale. Les médiateurs sont ceux qui sur le site
facilitent la communication entre les membres de la sous-équipe et entre les sous-équipes. On en
retrouve classiquement sous trois formes – les responsables qui gèrent le projet de la sous-équipe,
les responsables produit qui représentent le métier dans la sous-équipe, et les responsables de
l'architecture qui donnent la direction technique des développements. Ces médiateurs vont travailler
en étroite collaboration avec leurs pairs, se réunissant régulièrement pour se coordonner entre sous-
équipes, ainsi que des réunions impromptues à quelques uns pour résoudre des problèmes
spécifiques.
Plus la distribution géographique est importante plus la
discipline doit être forte
Sur un projet distribué, agile ou non, la communication est le risque le plus important. La bonne
nouvelle vient du fait que les méthodes agiles mettent l'accent sur la communication et la
collaboration, c'est déjà un premier pas dans la bonne direction. Accepter d'investir dans les
voyages, faire un peu plus de modélisation dès le début du projet, organiser votre équipe autour de
l'architecture, et adopter des outils plus sophistiqués sont les clefs du succès en mode agile
distribué. Si vous souhaitez de plus amples informations je suggère de consulter le livre rouge
d'IBM intitulé "Global Development and Delivery in Practice: Experiences of the IBM
Rational India Lab" (www.redbooks.ibm.com/abstracts/sg247424.html). Je trouve cette approche
un peu trop lourde à mon goût mais c'est écrit par des personnes avec des années d'expérience dans
le développement distribué géographiquement.
Remerciements
Je voudrais remercier Rajesh P Thakkar, Lead Architect au laboratoire logiciel d'IBM à Bangalore,
pour ses informations inestimables qui ont permis cet article.