Scrum distribué
David Starr dirige le service de développement logiciel pour Scrum.org où il se concentre sur l'amélioration du métier du développement logiciel. Il a également fondé la communauté technique en ligne, ElegantCode.com.
Juillet 2012
Les équipes multisites ont souvent des difficultés de communication cohérente, opportune et efficace. Comprendre comment le Scrum fournit un conteneur dans lequel les différents types d'équipes multisites peuvent s'améliorer et réussir.
L'infrastructure Scrum n'affiche rien sur les équipes de développement multisites. Scrum n'exige pas que tous les membres d'une équipe Scrum ou même les membres d'une équipe de développement travaillent dans la même salle, le même bâtiment, la même ville ou sur le même fuseau horaire. Les équipes Scrum exposent activement les obstacles à l'accroissement de la productivité, et lorsque la communication est un obstacle, Scrum l'indique de manière très visible.
Lorsque les membres de l'équipe ne travaillent pas ensemble physiquement, les communications au sein de l'équipe sont nécessairement plus complexes et il en est de même pour le logiciel créé par cette équipe. En 1968, Melvin Conway a écrit :
Les organisations qui conçoivent des systèmes sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations.
La loi de Conway s'est révélée être plus qu'un adage ; c'est une dynamique mesurable dans les équipes de développement logiciel. Une étude a montré l'effet de la loi de Conway en mesurant ce que l'effet de la répartition de l'équipe peut avoir sur l'architecture du système. Lorsque les membres de l'équipe sont répartis sur des sites, les développeurs de logiciels ont tendance à créer des couches d'abstraction dans le code afin d'essayer de les isoler les uns des autres[1].
Vue d'ensemble
Consultation de l'équipe dans le code
Stella est développeur dans une équipe Scrum qui fournit régulièrement le travail qu'elle prévoit pour chaque sprint. Son équipe est réputée pour créer des logiciels de haute qualité, même si leur code est un peu difficile à comprendre pour les autres utilisateurs qui tentent de le lire.
Elle travaille à domicile et dans un fuseau horaire différent du reste de l'équipe. Ils utilisent la messagerie électronique, un système de gestion des spécifications coûteux, et occasionnellement la vidéoconférence pour discuter de leur travail dans chaque sprint. Ils utilisent Scrum comme prescrit avec un Scrum quotidien planifié pour s'adapter à la planification de chacun. Elle s'occupe de la planification des réunions et du Scrum quotidien par téléphone sans voir les visages de ses coéquipiers lorsqu'ils communiquent. Elle n'entend même pas les conversations qui se tiennent avant et après chaque Scrum quotidien.
Dans une bonne intention, Stella crée une couche d'abstraction dans son code, ainsi son travail est isolé et testé plus facilement. Sa nouvelle abstraction sépare son implémentation de l'interface qu'elle a déclaré et rendu disponible pour d'autres membres de l'équipe. Elle déclare que ce type de système enfichable aboutit à des architectures de système découplées propres. Elle se rappelle que « l'utilisation d'interfaces comme limite d'implémentation est simplement une bonne conception orientée objet ». Son nouveau modèle de plug-in lui permet de travailler uniquement dans sa section de code sans créer d'interférences avec ses coéquipiers travaillant dans d'autres domaines.
Comme énoncé par la loi de Conway, le code reflète maintenant sa communication avec son équipe : faible couplage. Sa conception remplace les conversations qu'elle aurait eues avec son équipe et le système devient inutilement complexe. Cette complexité inutile est un miroir de ses relations avec les autres membres de l'équipe de développement. Au final, ces décisions auront un coût pour sa société puisqu'il y a plus de lignes de code à s'approprier, davantage de niveaux d'indirection que les futurs développeurs devront comprendre, et plus de tests pour vérifier que la fonctionnalité de l'abstraction s'exécute correctement.
Stella n'a commis aucune erreur. En fait, elle a su tirer parti de bonnes pratiques de conception orientée objet pour isoler un problème au sein du système. Malheureusement, le problème qu'elle a isolé concernait ses propres défis de communication et la solution autorise encore moins les communications fréquentes. Tristement, le système qu'elle a modifié lors de l'adressage du problème impliquait le logiciel. Une façon plus efficace de traiter ce problème aurait pu consister à simplifier les communications avec son équipe de développement.
Lorsque les membres de l'équipe ne sont pas assis côte à côte, ils ont tendance à remplacer de simples échanges verbaux par des conversations plus compliquées et plus formelles. Au lieu de discussions rapides et efficaces quant à de petites décisions tactiques, les sujets s'accumulent et sont traités ultérieurement. Souvent, ces questions ne sont jamais abordées. La baisse des communications personne à personne engendre d'autres types de communication comme les spécifications, les billets de travail ou même du code. Les ISomeInterfaces sont conçues pour couvrir les dysfonctionnements des équipes qui les créent.
Complexité involontaire de la répartition d'équipe
Les décisions prises en dehors d'une équipe Scrum sont celles qui probablement augmentent la complexité. La composition des équipes de développement de logiciels ou la répartition des tâches par individu est rarement simple, et c'est pour cela que le Scrum fournit des limites de manœuvre permettant de réduire cette complexité. En dépit de cela, la complexité réelle d'écrire du code et de livrer un logiciel est parfois faible par rapport à la complexité de la culture et des processus organisationnels mis en place dans le cadre de l'équipe de développement.
Par conséquent, la décision de composer une équipe de membres Scrum qui se trouvent dans des fuseaux horaires différents est rarement prise par ceux qui effectuent le travail. Les décisions de créer une équipe Scrum multisite proviennent probablement des responsables qui peuvent constituer une équipe de spécialistes fortement qualifiée, ou qui peuvent (plus probable) essayer de réduire les coûts de production en recourant à des prestataires de service hors site pour développer des logiciels à moindre coût. Bien que ces modèles peuvent réduire le coût initial de développement de logiciels, ils échouent généralement dans la prise en compte du coût de la maintenance continue et de la complexité ajoutée à faire face aux difficultés de communication au sein de l'équipe de développement.
Peu importe comment et pourquoi les équipes multisites sont créées, elles sont une réalité et rien n'indique qu'il soit possible de faire sans. Même dans les cas d'équipes multisites, le Scrum reste une excellente infrastructure pour gérer la planification et l'exécution de la livraison d'un produit logiciel. Les membres de l'équipe doivent tout simplement être plus diligents quant à l'amélioration des canaux de communication existants et faire attention aux sous-optimisations telles que celles décrites dans l'exemple ci-dessus.
Réalité des équipes multisites
Les équipes multisites peuvent offrir l'opportunité de faire appel aux services de la personne adéquate pour le travail à fournir, quel que soit son lieu d'habitation. Autrement dit, les personnes peuvent travailler depuis le site de leur choix et non plus au siège de la société. Bien qu'il soit facile de débattre de l'utilité des équipes multisites, l'économie de la sous-traitance, de l'utilisation des ressources internes, de la délocalisation de proximité et de la délocalisation rurale restent très intéressantes pour de nombreuses organisations.
Le guide Scrum, publié sur Scrum.org, codifie le Scrum et représente l'ensemble des règles permettant d'appliquer l'infrastructure Scrum. Bien que le guide Scrum est silencieux sur la question des équipes multisites et ne fournit aucune aide les concernant particulièrement, le Scrum insiste sur les retards et les manques de communication qui existent dans les équipes dont les membres ne peuvent pas se parler entre eux sans périphérique électronique en guise de relais de communication.
Environnement de confiance
L'essentiel de ce que les individus se disent entre eux est véhiculé par le langage du corps. Les informations recueillies en observant quelqu'un pendant une discussion de conception peuvent être aussi précieuses que les informations qui sont écrites sur le tableau blanc. De ce fait, une grande partie du focus pour établir le lien entre les travailleurs multisites implique de surmonter la barrière du langage du corps.
Steve McConnell a écrit, « La demi-vie de la confiance est d'environ 6 semaines. » [2] Cela signifie que les développeurs travaillant et collaborant ensemble chaque jour développent un niveau de confiance mutuelle. Le degré de confiance varie comme dans toute relation, mais le potentiel de confiance est plus élevé si les coéquipiers se voient et travaillent souvent ensemble.
Lorsque les coéquipiers cessent de se voir tous les jours et ne travaillent pas à proximité les uns des autres pendant environ six semaines, le niveau de confiance dans la relation est réduit de moitié par rapport au début. Le peu de confiance restant diminue rapidement à mesure que le temps s'écoule.
Ce n'est pas que les personnes impliquées ne se respectent pas, mais la confiance et l'efficacité de l'équipe sont perdues. Sans confiance, la collaboration diminue et les limites entre les coéquipiers augmentent. Ces limites sont souvent répercutées dans le code.
Les caméras, la téléconférence, la messagerie instantanée (Instant Messenger), la conversation vidéo, le partage d'écran et d'autres outils de collaboration permettent de réduire l'écart existant entre les coéquipiers, et ces types d'outils doivent être aussi omniprésents que l'air pour que les équipes multisites soient fortement productives. Une communication visuelle fréquente contribue à établir une relation de confiance durable.
Quelle que soit l'utilisation des outils, les équipes multisites peuvent augmenter leur efficacité en exploitant les opportunités liée à la communication haute fidélité. En bref, se parler de vive voix est préférable à la messagerie instantanée (Instant Messenger), qui est préférable à l'envoi d'un message électronique, etc. Réduire le temps entre les interactions est encore mieux.
Degrés de séparation
Les membres d'une équipe peuvent être séparés de différentes manières et il existe souvent des modèles récurrents de répartition d'équipe. Comme les modèles trouvés dans d'autres environnements (comme la conception de logiciels), les modèles de répartition d'équipe peuvent se produire intentionnellement ou par erreur. Les modèles accidentels se produisent comme une réponse inconsciente à la pression existante et les modèles intentionnels sont implémentés délibérément pour contrôler la complexité.
Les modèles Scrum distribués décrits ici peuvent être prescrits ou involontaires. Ils peuvent être inspirés par les décisions prises en dehors de l'équipe Scrum ou peuvent résulter de l'auto-organisation de l'équipe Scrum autour d'un problème particulier. Indépendamment de leur origine, les modèles de répartition suivants sont généralement communs.
Les équipes de développement distantes collaborent, mais sont physiquement séparées du reste de la société.
Dans le modèle Membre d'équipe distant, un seul membre de l'équipe travaille à un autre emplacement que le reste de l'équipe dont il fait partie.
Dans une équipe multisite, tous les membres de l'équipe travaillent ensemble avec le même objectif, mais chacun à un emplacement différent.
Équipe de développement à distance
Certaines équipes de développement se retrouvent séparées géographiquement de leur plus grande organisation parente, voire pire, de leurs propriétaires de produits. Cela est courant lorsqu'une société en absorbe une autre ou lorsque deux sociétés fusionnent. Si l'équipe de développement doit être distante, le Scrum est une façon idéale de gérer efficacement le travail et la communication de cette équipe avec l'organisation élargie. De nos jours, de nombreuses équipes réussissent avec cette formule.
Bien que les situations varient, les équipes de développement distantes se sentent souvent démunies, sous-évaluées et coupées de l'organisation principale. Les membres de l'équipe distante peuvent se sentir ignorés et aliénés par la société parente, qui peut (souvent involontairement) considérer l'équipe moins importante que celles situées au siège de la société.
Ces équipes de développement distantes recherchent sans cesse des raisons, des excuses et des possibilités de ne pas associer leur travail à celui des autres équipes. Il est facile d'expliquer à distance pourquoi l'intégration de ce sprint est sans importance, inutile ou impossible. Le ressentiment grandit et l'équipe de développement constate que les demandes d'intégration de son code avec celui de l'organisation générale sont « déraisonnables », « incohérentes », « inutiles » ou « inadaptées aux besoins ».
Si aucune ou toutes ces impressions sont applicables, le cas n'entre pas dans le cadre de ce sujet. L'équipe de développement à distance doit se sentir entendue et comprise, tout en comprenant sa propre valeur au sein de l'organisation élargie. Il est facile d'oublier que le travail effectué à distance repose sur chaque individu.
Un ScrumMaster travaillant à un autre emplacement que l'équipe de développement contribue à l'échec du projet. Les ScrumMasters ne peuvent pas effectuer efficacement les tâches d'encadrement, organiser les événements Scrum et assurer l'intendance du Scrum lui-même à distance. La distance entre une équipe de développement et un ScrumMaster empêche toute communication et présente trop de risques pour l'équipe Scrum. La familiarité est nécessaire pour établir la confiance, et une grande confiance mutuelle est essentielle à la réussite du Scrum.
Les ScrumMasters travaillent au même emplacement que leurs équipes de développement.
Pour qu'une équipe de développement soit au service de son propriétaire de produit, une communication ouverte et claire est également nécessaire. Le propriétaire du produit doit être disponible pour l'équipe de développement partout dans chaque sprint pour répondre aux questions et fournir des commentaires sur les travaux en cours. Bien que cette interaction fréquente est possible dans des situations distantes, une méthode fiable pour conserver cette communication doit être établie.
Un propriétaire de produit absent est l'une des forces les plus destructrices qu'une équipe Scrum peut subir. Une équipe de développement négligée est forcée de prendre des décisions en matière de fonctionnalité et de priorité. Or ce groupe est souvent le moins apte à effectuer les choix adéquats en matière de fonctionnalité, car il est généralement moins bien informé des besoins du client que le propriétaire du produit.
Les propriétaires de produit accordent de l'attention à l'équipe de développement et fournissent des commentaires tout au long du sprint.
Malheureusement, trop souvent absents ou rarement disponibles, les propriétaires de produit affaiblissent les équipes Scrum, même dans des environnements colocalisés. Pour que le Scrum soit optimisé, l'équipe Scrum doit fonctionner comme une unité soudée, fiable et collaborative et qu'elle bénéficie de l'attention constante d'un propriétaire de produit dédié.
Membre de l'équipe distante
Certains développeurs sont isolés de leurs coéquipiers qui sont eux-mêmes colocalisés et travaillant ensemble à un emplacement partagé. L'exemple classique est celui du développeur télétravailleur qui travaille avec dévouement avec une équipe depuis son bureau à domicile. Bien que les cas de figure varient, ce type d'arrangement est de plus en plus courant.
Alistair Cockburn a inventé la communication osmotiqueTerm[3] pour identifier un type de communication intrinsèque dans la pièce d'équipe.
La communication osmotique signifie que les informations sont diffusées de façon « ambiante » (sans que les membres de l'équipe les écoutent activement), afin qu'ils en extraient des informations pertinentes, comme par osmose.Cela se produit généralement en étant présents dans une même pièce.Ensuite, lorsqu'une personne pose une question, les autres personnes dans la pièce peuvent prendre part à la discussion ou poursuivre leur travail.
La communication osmotique n'est pas limitée aux équipes de développement de logiciels. Les visiteurs d'une salle de presse d'un grand journal ou d'un grand média rechercheront souvent exactement ce type de dynamique. Même les enquêteurs chargés d'une affaire criminelle au sein des services de Police du monde entier ont recours aux salles de conversation d'équipe pour réfléchir ensemble aux éléments de l'enquête.
La perte de communication osmotique est la perte de connaissance de la situation au sein de l'équipe. Lorsqu'un développeur de logiciels ne tient pas compte des modifications constantes appliquées au logiciel par ses coéquipiers, il y a une perte de la cohésion et du contexte partagé dans l'équipe. Le membre de l'équipe ininterrompu, concentré et distant n'est pas sur la même longueur d'onde que la salle d'équipe. Il est à l'écart des discussions ad hoc en matière de conception et d'autres décisions pouvant être prises de manière fluide tout au long d'une journée donnée.
La tendance à fournir des logiciels plus rapidement avec moins de temps entre les versions nécessite une plus grande connaissance de la situation au sein de l'équipe de développement. Pour le membre de l'équipe distant absent de la salle d'équipe, la connaissance de la situation est simplement perdue.
Pour régler ce problème, le recours à la téléprésence devient plus courant. Des solutions de téléprésence simples peuvent être mises en place au moyen d'un ordinateur portable, d'une caméra et de haut-parleurs. L'installation de ce système dans la salle d'équipe peut fournir un canal de communication ouvert pour le développeur distant qui peut simplement laisser le canal ouvert toute la journée.
La vidéo et la téléconférence comblent les lacunes liées à l'absence physique.
Les signes qui montrent que le développeur distant ne tient pas à faire réellement partie de l'équipe sont les suivants :
L'utilisation de communications écrites telles que la messagerie électronique ou la messagerie instantanée (Instant Messenger) pour discuter de sujets complexes.
La définition d'interfaces fixes en tant que contrats dans le code plutôt que d'avoir des discussions régulières avec les autres développeurs.
Le fait de vouloir une branche de code privée ou personnelle dans le contrôle de version.
Lorsque vous établissez le lien entre un développeur distant et le reste de l'équipe, les visites périodiques sont très utiles. Les appels vidéo sont préférés aux appels téléphoniques. Les appels téléphoniques sont préférés aux messages saisis, et le fait de compter sur la messagerie électronique pour communiquer présente des risques.
Équipe multisite
Dans une équipe Scrum vraiment multisite, les individus travaillent ensemble pour fournir le même objectif de sprint, et chaque membre de l'équipe travaille à un emplacement différent. L'exemple archi-classique est le projet open source avec des collaborateurs situés partout dans le monde. Bien que les problèmes de communication soient significatifs, la validité de ce modèle est démontrable. La communication dans une équipe comme celle-ci est nécessairement un défi, mais devient plus courante à mesure que la technologie continue à réduire la barrière du langage du corps.
Lorsque les membres de l'équipe sont assis à différents emplacements, le logiciel de partage d'écran est essentiel pour tenir des conversations efficaces en matière de conception et de code. Concernant le code, sauf si les deux parties dans une conversation constatent la même chose, la discussion inclut trop d'hypothèses. Heureusement, le logiciel de partage d'écran est facilement disponible et très efficace. Les membres de l'équipe qui ne sont pas dans la même salle doivent se retrouver à partager des écrans avec leurs coéquipiers plusieurs fois par jour.
Le partage d'écran peut être un outil de couplage et de collaboration très efficace.
La recherche d'excuses pour examiner du code, des éléments du journal des travaux en souffrance (backlog) ou d'autres artefacts, est un formidable moyen de maintenir à haut niveau la connaissance situationnelle dans les équipes multisites. Une autre technique performante ajoute une règle de vérification simple pour tout élément fourni dans le cadre du sprint. La règle en deux parties est la suivante :
Chaque élément doit être vérifié dans un environnement d'intégration considéré comme terminé.La personne effectuant la vérification peut ne pas être la personne qui a effectué le travail.
Les équipes de développement adoptant cette règle simple recherchent une meilleure compréhension collective du travail effectué au sein de l'équipe.
Note de l'auteurJ'ai travaillé avec une équipe de développement dont les membres ont travaillé dans le même bâtiment, mais dans des bureaux différents. C'est un signe de fierté pour la société que de fournir des bureaux privés à tous les employés. L'équipe de développement a finalement décidé de créer une salle d'équipe virtuelle dans laquelle chaque membre de l'équipe pouvait intervenir à l'aide d'une caméra, d'un microphone et de haut-parleurs. La salle d'équipe virtuelle restait ouverte en permanence pour permettre aux membres de l'équipe de travailler sur le produit qu'ils partageaient.Au bout de quelques temps, l'équipe a fini par apprécier cette salle virtuelle. Ils ont commencé à utiliser le logiciel de partage d'écran pour afficher les écrans de chacun plutôt que d'arpenter les couloirs, car ils trouvaient cela plus rapide. L'équipe a commencé à utilisé la salle d'équipe virtuelle toute la journée, même si chaque membre était assis dans des bureaux séparés par des parois murales de quelques centimètres.Par la suite, un des membres de l'équipe a testé le travail à domicile pendant quelques jours plutôt que de se rendre au bureau. Lors de la rétrospective du sprint, l'équipe de développement s'est accordée à dire que grâce à la salle d'équipe virtuelle, il n'importait plus de savoir si une personne travaillait dans le bureau d'à-côté ou depuis son domicile. La salle d'équipe virtuelle s'est révélée être plus importante que les différents bureaux.
Outils et pratiques
Les équipes Agile qui ont recours à des outils rudimentaires et à des outils de haute fidélité pour gérer leur travail, rencontrent de nombreuses difficultés. Lorsque la complexité de la répartition géographique ou que plusieurs équipes de développement s'y ajoutent, les cartes et les marqueurs d'index analogiques ne sont simplement pas mis à l'échelle aussi bien que pour une solution logicielle. Cela a conduit à une surabondance d'outils de gestion de travail spécialement conçus pour Scrum ou les équipes « Agile », avec de nombreux fournisseurs d'outils faisant essentiellement la promesse suivante : « Notre outil vous rendra agile ! ».
Confusion entre les outils et les pratiques
Naturellement, aucun outil ne peut rendre une équipe « agile ». La véritable agilité provient de la culture, des attitudes et des comportements des personnes créant et fournissant les logiciels. De ce fait, le manifeste Agile[4] exprime une valeur pour « les personnes et les interactions sur les processus et les outils ».
Un dicton dans la communauté Agile dit que « les personnes sont supérieures aux processus et les processus sont supérieurs aux outils ».
Pour les pragmatiques, le dicton dit que « les outils définissent les règles ».
Ces deux adages s'appliquent à la relation que les personnes entretiennent avec les logiciels qui leur permettent de communiquer, de collaborer et de gérer le travail. Les outils de suivi de travail sont censés réduire la complexité en matière de communication et de compréhension, mais le résultat contraire peut se produire. Il n'est pas rare que les personnes tombent dans l'ornière du signalement inutile d'un défaut au lieu de le résoudre, par exemple.
Note des auteursUne ressource importante pour ceux qui considèrent l'équilibre entre les outils, les processus et les pratiques : le Livre blanc de Kent Beck Tools for Agility. Le document est aussi perspicace aujourd'hui qu'il l'était lorsque M. Beck l'a écrit en 2008.
Les membres des ScrumMasters et de l'équipe de développement sont sujets à se plaindre que « l'outil est obsolète » lorsque les données du travail ou le système de suivi des fonctionnalités ne sont pas à jour. Cela ne tient pas compte de vos connaissances intuitives :
L'objectif est de conserver l'équipe à jour et non l'outil.Parfois, l'outil peut vous y aider.
Le Scrum est particulièrement conçu pour augmenter la connaissance de la situation dans l'équipe Scrum. Le Scrum est silencieux sur le format des spécifications, la conservation des minutes, les répartitions du travail, les unités d'évaluation ou le suivi du temps. Les équipes peuvent trouver ces informations utiles et peuvent travailler dans le contexte du Scrum. Mais les équipes utilisant ces pratiques supplémentaires le font en plus du Scrum, pas à cause de lui.
Prise en charge des pratiques avec les outils
Tout outil utilisé par une équipe Scrum est heureusement choisi pour prendre en charge une pratique sélectionnée avant l'outil. Autrement dit, les équipes Scrum saines s'améliorent délibérément. Cela signifie choisir de tester une nouvelle pratique ou technique car l'équipe souhaite s'améliorer dans un domaine spécifique. L'utilisation d'un outil pour prendre en charge la nouvelle pratique peut venir après le test des notions de base. En résumé :
Choisissez les personnes les plus importantes en premier.En tant qu'équipe autonome, elle sélectionne ses propres pratiques, puis choisit un outil pour prendre en charge la pratique qu'elle a choisie.Accordez plus de valeur aux personnes qu'aux processus et plus de valeurs aux processus qu'aux outils.
(Pour plus d'informations sur les outils permettant de prendre en charge vos pratiques disponibles dans Microsoft Visual Studio 2012, consultez Collaborer (approfondir) [redirection], Collaborer [redirection] et la section Learn du portail d'accueil sur Visual Studio Online.)
Le mode de collaboration des membres de l'équipe a des effets indéniables et évidents sur le logiciel qu'ils créent. Quand la communication est simple et efficace, cela se reflète dans la conception du logiciel. Inversement, lorsque les équipes s'efforcent de communiquer en interne ou avec les personnes pour lesquelles elles travaillent, le logiciel que l'équipe produit reflète l'impédance des expériences de l'équipe.
Les cycles d'inspection et d'adaptation normaux de Scrum permettent d'aider les équipes implantées sur plusieurs sites. Les événements prescrits dans le Scrum forcent à la communication, mais n'ont pas nécessairement un impact sur la forme de la communication.
Une salle d'équipe colocalisée reste la technologie minimale, la fidélité maximale et la méthode la plus efficace pour qu'une équipe puisse créer en collaboration un logiciel complexe. Toutefois, les équipes distantes demeurent. Qu'elles soient motivées par des intérêts personnels, économiques ou par un manque de prévoyance, de plus en plus d'équipes Scrum se retrouvent à travailler dans des situations où les membres de l'équipe ne sont pas réunis physiquement.
Participer à la communication d'une équipe malgré les limites physiques ne peut que porter ses fruits en termes d'accroissement de la qualité, de réduction de la confusion, de rapidité de la production et de bonheur des individus. Si une attention particulière est donnée aux outils et pratiques au sein de l'équipe, la répartition peut fonctionner correctement. Elle peut même s'exécuter correctement.
Références
Herbsleb, 1999 Architectures, coordination, and distance: Conway's law and beyond. IEEE Software, 7
McConnell, S. (2009). Travel Restrictions and Offshore Development.
Cockburn, A. (2008). Osmotic Communication.
divers. Agile Manifesto.