Scrum pour l'équipe répartie entre deux langues parlées

J'ai une équipe qui, sans une seule langue commune à tous les membres de l'équipe. L'équipe est répartie sur deux sites (bien que la géographie ne soit pas le problème principal). Tous les membres de l'équipe dans chaque emplacement parlent la même langue et il y a des membres dans les deux emplacements qui peuvent parler les deux. Je voudrais présenter Scrum, mais je me bats avec la logistique pour traiter le problème de la langue.

Ce n'est pas une équipe offshore. Tous les membres de l'équipe sont des employés de l'entreprise, mais situés dans deux bureaux différents dans différents pays. Heureusement, nous n'avons aucun problème avec les fuseaux horaires; la langue est le principal obstacle. Bien que l'équipe puisse être divisée en deux équipes, étant donné la taille et les compétences des personnes dans chaque emplacement ainsi que d'autres facteurs externes, il est plus souhaitable de s'intégrer en une seule équipe.

Je pense qu'il serait préférable d'utiliser la visioconférence afin d'avoir une communication plus riche et aider à unir l'équipe pour pouvoir se voir et faire la vraie approche stand-up. Cependant, je crains que cela ne soit difficile à communiquer entre les langues. Les membres bilingues de l'équipe devraient-ils traduire verbalement? Alternativement, nous pourrions utiliser le message instantané comme recommandé par la seule référence que j'ai pu trouver aux problèmes de langue dans la mêlée distribuée. Je suis préoccupé par la communication "plus pauvre" et c'est peut-être une mauvaise introduction au concept de mêlée.

Des personnes qui ont de l'expérience dans la gestion des différences linguistiques au sein d'une équipe, comment avez-vous résolu le problème et dans quelle mesure cela a-t-il fonctionné pour vous?

Les équipes pratiquant l' agile sont censées être ouvertes à l'expérimentation, n'est-ce pas? Vous savez, "les gens sur les processus" et autres.

Essayez de vous diviser en deux équipes selon leur langue et voyez comment cela fonctionne. Si cela s'avère problématique, vous pouvez essayer l'approche en équipe.

_{mise à jour, sur la base des éclaircissements fournis dans les commentaires}

Je pense que la réponse réside dans ce que vous avez dit à propos de "être ouvert à l'expérimentation" ... en fin de compte, nous avons expérimenté quelques approches différentes pour trouver ce qui fonctionne le mieux

Vous avez eu mon idée à 100% correctement, et je pense que vous abordez le problème de la bonne façon.

Comme ils l'ont écrit dans The Pragmatic Programmer il y a plus de dix ans,

Il n'y a pas de réponses faciles. La meilleure solution n'existe pas ...

C'est là qu'intervient le pragmatisme. Vous ne devriez pas être lié à une technologie particulière, mais avoir une expérience et une base d'expérience suffisamment larges pour vous permettre de choisir de bonnes solutions dans des situations particulières ...

Vous ajustez votre approche en fonction des circonstances et de l'environnement actuels. Vous jugez l'importance relative de tous les facteurs affectant un projet et utilisez votre expérience pour produire des solutions appropriées. Et vous faites cela en continu au fur et à mesure que le travail progresse ...

On peut dire qu'Agile renforce cette philosophie ancienne mais dorée en faisant des ajustements continus une partie explicitement bienvenue du processus de développement.

Le moyen le plus efficace consiste à diviser en deux équipes différentes avec des livrables logiquement isolés pour chaque équipe - ils auront leurs propres maîtres de mêlée.

Veuillez lire le lien ci-dessous, cela a de nombreux bons points que vous pouvez suivre. (même si penser ne répond pas au souci de deux langues différentes, cela a de nombreux points liés à deux emplacements géographiques). Martin Fowler a écrit cet article après de nombreuses années de travail avec des équipes offshore.

http://martinfowler.com/articles/agileOffshore.html

Quelques extraits de puces de l'article ci-dessous.

1. Utilisez l'intégration continue pour éviter les maux de tête liés à l'intégration

2. Demandez à chaque site d'envoyer des ambassadeurs aux autres sites

3. Utilisez les visites de contact pour établir la confiance

4. Ne sous-estimez pas le changement de culture

5. Utilisez des wikis pour contenir des informations communes

6. Utilisez des scripts de test pour mieux comprendre les exigences

7. Utilisez des versions régulières pour obtenir des commentaires sur la fonctionnalité

8. * Utiliser des réunions régulières de courte durée *

etc

Quelle est la langue officielle de l'entreprise? Je ne connais pas la taille de votre entreprise, mais chaque lieu où je travaillais avait une langue officielle.

Mon conseil est d'utiliser le langage d'entreprise par défaut, à moins que l'équipe Scrum ne veuille quelque chose de différent et soit prise en charge par la direction.

Notre équipe néerlandophone travaille en étroite collaboration avec notre branche francophone. Aucune équipe francophone ne parle le néerlandais et notre français n'est que correct.

Tout le monde parle au moins un peu l'anglais cependant, certainement les programmeurs, c'est la Lingua Franca en Europe occidentale. Donc toute la documentation est en anglais, tous les commentaires de code, tous les mails et réunions.

De temps en temps, nous visitons également nos succursales. Souvent, quelqu'un qui le visite souvent amène quelqu'un de nouveau pour laisser tout le monde rencontrer tout le monde.