Au secours ! Comment faire du scrum avec une équipe offshore ??!
Avant de commencer, mettons-nous d’accord. En agilité, on préconise la communication en face à face. L’offshore ne va pas dans ce sens et est considéré comme une des causes d’échec de pas mal de projets. Pour pouvoir mettre en place du scrum, on privilégie les équipes colocalisées. Donc théoriquement, pas de membre de l’équipe scrum dans un autre pays (offshore), dans une autre ville de France (nearshore) ou plus subtile dans un autre bâtiment ou un autre étage.
Après…
Dans la pratique, souvent pour des raisons de budget, tout ou partie de l’équipe de développement peut être délocalisée dans des pays étrangers (Inde, pays de l’est, Maghreb…). Dans certaines multinationales, c’est tout simplement le métier qui sera de l’autre côté de l’Atlantique ou à l’autre bout de l’hémisphère. Plus anecdotique, j’ai vu une entreprise de petite taille qui faisait de l’offshore car le PDG voulait en faire comme tous ses autres amis auto-entrepreneurs. Quelle que soit la raison, vous vous retrouverez peut-être un jour avec votre équipe scrum répartie sur différents endroits de la planète, alors que faire ?
Le meilleur conseil que l’on puisse vous donner
L’humour
Simple mais efficace.
Vous êtes une équipe qui doit travailler ensemble mais avant tout, vous êtes des êtres humains qui allez passer pas mal de temps ensemble. Il vous faut un liant, qui doit se créer et perdurer. Bien sûr, il faut prendre en compte l’aspect culturel, on y reviendra, tout n’est pas permis. Cependant, ce qui vous permettra facilement de passer outre la frontière professionnelle pour générer une cohésion bienveillante de l’équipe sera la petite blague du matin, l’autodérision, l’image humoristique que vous avez vu sur les réseaux sociaux…
Comme on le sait, le coeur de l’entreprise est la machine à café. Bien pratique quand tout le monde est au même endroit mais ce n’est pas votre cas. Le dernier ragot en date (pro ou non), ils n’ont pas pu l’avoir, partagez-le.
Vous n’êtes pas un as du stand-up ? Parlez des news du monde, des événements sportifs (coupe du monde, jeux olympiques…) ou culturels (eurovision, comic-con, E3…), selon les goûts de votre équipe, que vous découvrirez au fur et à mesure.
Au café, le midi, avec vos collègues de l’open space vous parlez hors cadre. Quand le faire dans votre cas ? Lors du daily, pendant que vous attendez l’éternel retardataire ou que Jira se charge, dans votre outil de communication, un mail off, avec un chat bot générateur de blague (j’avais le principe “one joke a day” dans l’une de mes équipes).
Vous trouverez toujours un petit moment pour rire ou ne serait-ce qu’esquisser un sourire. Accordez-vous à la dynamique de votre équipe. Si au début le scrum master devra être l’instigateur, par la suite cela viendra naturellement au reste de l’équipe.
Se rencontrer
Une des erreurs classiques est de
se cacher derrière de fausses excuses pour repousser le voyage professionnel afin d’aller voir l’équipe dans tel pays que l’on ne veut pas visiter. Grave erreur. Ne commencez pas à travailler avec une équipe offshore sans directement vous poser la question de quand vous allez les rencontrer de visu. La communication en face à face est dans vos principes agiles et cela s’applique aussi ici. Certes, c’est plus contraignant mais cela en vaut le coup.
Un passage sur Paris d’une collègue QA, une bière plus tard avec notre ops, étrangement les problèmes d’environnement de tests se sont résolus plus rapidement.
Je faisais des points individuels avec les membres de mon équipe pour savoir comment cela allait, les amener à exprimer ce qu’ils n’osaient pas dire. Je ne comprenais pas pourquoi mes dev ne voulaient pas s’isoler dans la salle de réunion que je voyais derrière eux sur la webcam pour faire ce point tranquillement. En allant là-bas, j’ai vu que le plafond était extrêmement haut, les cloisons de la salle ne montaient pas jusque-là. Donc, quand on faisait un call dans cette salle, tout le reste de l’open space entendait ce que l’on se disait.
On a fait venir tous les dev sur Paris et on les a fait rencontrer le service client. La question métier que l’équipe de dev n’osait jamais poser de peur de paraître stupide, enfin exprimée et répondue en les rencontrant ! Un échange constructif s’est instauré.
Dans ces exemples tirés de mon expérience personnelle, vous remarquerez que je me suis déplacé et qu’ils sont également venus à ma rencontre. Il est important de le faire dans les deux sens. Parfois coûteux de faire déplacer un groupe de personnes mais tellement utile sur le long terme. La France fait (souvent) rêver à l’étranger, profitez de cet attrait pour les motiver à venir.
Quelques conseils rapides pour préparer les déplacements :
- Assurez-vous que toute la partie logistique est bien gérée (visa, logement, transport aéroport-logement-travail, est-ce que quelqu’un les accompagne pour faire le check-in, badges, accès cantine, qui paye les repas, poste de travail…).
- Le programme doit être défini, les objectifs du déplacement doivent être clairs et les interlocuteurs disponibles.
- Prévoir des sorties d’équipe les soirs, des déjeuners avec des gens connexes à l’équipe tout en leur laissant du temps pour faire les visites, sorties, shoppings qu’il veulent avec ou sans vous.
- Profitez de la venue des gens pour les faire participer à des événements d’entreprise, donner de la visibilité à ces noms qu’ils ne voient que dans les tickets ou les mails.
Se parler
Dans quelle langue parlez-vous ? Dans quelle langue sont rédigées les user stories ? La réponse ne doit pas être ce que j’ai déjà entendu : “contractuellement ils se sont engagés à parler français donc je parle en français”. La bonne réponse est dans la langue où votre équipe scrum entière se comprend le mieux.
Une fois le choix fait, le plus dur est de s’y tenir. Cela peut paraître évident mais si vous avez choisi l’anglais, alors toutes vos réunions, vos US, votre board, vos ateliers de conception, vos mails, vos chats se feront en anglais. Que se passe-t-il si la représentante métier n’arrive pas à suivre ? Oui, vous pouvez faire des intermèdes dans vos langues natales mais la discussion principale doit toujours rester dans votre langue choisie. C’est là où le rôle de facilitateur (parfois de traducteur, parfois de police) du scrum master prend tout son sens.
Se comprendre
Au-delà de la langue, c’est la culture qu’il faut prendre en compte. Dans une équipe colocalisée, les différences culturelles existent mais ont tendances à plus facilement se lisser. Quand vous avez plus de la moitié des développeurs qui sont dans un pays où dire que l’on ne sait pas est mal perçu, vous avez un tout autre chemin à faire. Il est très important que rapidement vous détectiez cela (en les rencontrant, en leur parlant et en faisant attention au non verbal).
Que ce soit dans les thèmes de vos rétrospectives, vos sujets de discussions ou vos références, vous devez prendre en compte les nationalités. J’ai déjà fait une blague malheureuse à connotation politique là où cela ne se faisait pas. La relation homme/femme et comment cela est perçu dans d’autres sociétés peut aussi être à prendre avec des pincettes. Allez-y par étapes, co-construisez votre communication en ne la limitant surtout pas à un outil de ticketing ou à des mails.
Profitez de vos différences pour alimenter votre vie d’équipe. Au moment de la construction de l’équipe, privilégiez les exercices de découverte des uns et des autres.
Quelques exemples d’icebreakers :
- Sur une mappemonde, représentez les lieux de naissance des gens et où il vivent actuellement.
- Demandez à chacun de partager une image de leur ville au moment des fêtes de fin d’année.
- Faites deviner aux autres le sens d’un mot dans votre langue natale.
- Racontez un conte de votre enfance (je me souviendrai toujours de ce début de rétro avec l’image d’un alien qui guette un hérisson dans le brouillard, référence à un conte pour enfant biélorusse).
- Citation de film décrivant le sprint (tout le monde ne regarde pas les blockbusters américains, dans certains pays ils y sont même interdits).
S’organiser
“Il est 10h à Paris, 12h à Minsk et 18h à Hangzou. Le sponsor est disponible à 11h, heure de Paris, pour le sprint review, que faire ?”
Si vous avez de la chance, il existe un fuseau horaire où tout le monde peut être disponible. Profitez-en au mieux. Il faut que le scrum master et l’équipe s’organisent pour que ce temps soit le plus productif. Si votre société a décidé de faire appel à du offshore, rappelez-leur que cela vient aussi avec des contraintes pour eux. Ce n’est pas forcément à ceux qui ne sont pas au siège de décaler les horaires. Tout le monde peut faire de temps en temps cet effort pour faciliter le travail. N’oubliez pas d’anticiper le bonus du changement d’heure d’été/hiver.
Si vous n’avez pas de chance, vous allez devoir faire de concessions. Vous ne pourrez pas avoir tout le monde en même temps. Envisagez des rotations, voire créez deux équipes plus compatibles au niveau des horaires. Evitez l’écueil de vous considérer indispensable. Vous pouvez, vous aussi, être l’équipe absente.
Dans tous les cas, trouvez avec votre équipe la façon la plus adaptée de vous laisser des messages. En fin de journée, nous faisions tous un EDS : “end of day status” sur le channel de l’équipe. Tout le monde devait pousser sur sa branche avant de partir. Votre stratégie de gestion de sources, comme pour toute équipe, doit bien être comprise. Ici d’autant plus car pendant qu’un dev dort, un autre est peut-être en train de tout refactorer. Votre board doit absolument être à jour. Rien de plus frustrant que de commencer une sous-tâche au petit matin alors qu’elle a déjà été finalisée cette nuit.
S’outiller
Pour faire travailler ensemble tout ce petit monde, la dématérialisation des outils est très importantes. Vous privilégierez un sprint backlog dans Jira ou Trello, accessible à toute heure et par tous. Les outils de ticketing sont à inclure dans votre méthode de travail (en n’oubliant pas la règle de la langue car le ticket du support urgent de prod en français alors que les dev ne savent pas le lire fait diminuer votre réactivité). Cela demande à tous une discipline qui peut être ressentie comme lourde par l’équipe. Le scrum master fait souvent le garde-fou pour éviter que l’outil ne soit pas à jour. Mais parfois, il est bon de les laisser oublier et d’en voir les conséquences en rétrospective. L’équipe doit se rendre compte par elle-même qu’elle est la première pénalisée si elle ne s’astreint pas à une mise à jour régulière.
Le nerf de la guerre reste l’outil de communication, que cela soit skype, skype business, sametime, gtalk, irc, slack, whatsapp ou autre, choisissez le bien. Voici quelques conseils pour le choisir :
- Haute disponibilité sur votre réseau (le trafic skype et skype business ne passe pas forcément dans les mêmes réseaux, dans notre cas il était plus performant de passer par skype normal que par la version business).
- Permettant la vidéo, le partage d’écran et la prise en main à distance (le pair programming à distance c’est possible !).
- Avec gestion des groupes/channels permettant d’avoir toute l’historique (celui que est à GMT+6 peut raccrocher les wagons plus facilement en lisant ce qui s’est dit pendant qu’il dormait).
- Utilisé par l’équipe (j’ai vu une équipe préférer Facebook messenger à l’outil interne, le principal est que vous communiquiez de la façon la plus naturelle et adaptée possible).
- Conforme avec les normes de sécurité de votre compagnie (dans tous les cas instaurez des règles d’utilisation, par exemple ne pas communiquer le mot de passe de production…).
- Connexion rapide (si vous perdez 10 minutes en début de chaque meeting pour commencer à parler, vous allez finir par ne plus appeler les gens).
- Ayant une version mobile.
Toutes vos cérémonies sont impactées.
Cela va demander au scrum master une gymnastique nouvelle, et de développer ses propre astuces. Personnellement, pour faire mes rétrospectives en ligne, j’aime bien utiliser lino. Vous créez votre support de rétrospective en jpeg, puis l’uploadez comme fond. Cela vous permet d’adapter les rétros comme vous le souhaitez, en utilisant quand même des post-it.
Est-ce que cela veut dire que c’est la mort du management visuel ? Pas forcément. Vous pouvez par exemple montrer les indicateurs d’intégration continue sur un écran dans chacun des pays. Vous pouvez aussi avoir des boards physiques adaptés aux personnes dans les pays concernés. On avait eu un problème de compréhension produit par le service client concernant ce qui allait se passer sur notre application mobile dans les sprints à venir. Suite à cela, la PO et les équipes en France qui géraient les API consommées par l’application ont fait un board donnant la vision macro des prochaines features avec en plus, un espace “boîte à idées”. Ne vous privez pas du management visuel. Vous en ferez sans doute moins ou en tout cas plus ciblé, mais il peut garder son utilité. N’oubliez pas d’afficher le trombinoscope ou autres photos avec toute l’équipe. Cela affirme le lien et renforce l’identité de l’équipe.
Tout membre de l’équipe doit avoir une webcam et un casque avec micro. Dès que vous en avez l’occasion, mettez la webcam. C’est le plus proche du face à face que vous pouvez avoir, usez-en ! Le messaging doit être le dernier recours alors passez des appels, vous comprendrez mieux les informations implicites. À voir dans votre contexte, nous on aimait bien avoir la webcam de l’open space des équipes. Tout de même plus pratique pour savoir quand quelqu’un est indisponible (mais si votre PDG commence à s’en servir pour vérifier la présence des gens, posez-vous diverses questions…)
Parlons contrat
Dans la plupart des cas, offshore va avec sous-traitance, et donc contractualisation. Si vous avez une volonté de faire du scrum, vous misez sur de l’amélioration continue d’une équipe. Pensez donc à vous assurer que vous avez une équipe stable qui travaille uniquement sur votre produit. Certains s’y sont cassés les dents avec à chaque daily une nouvelle personne.
“La collaboration avec les clients plus que la négociation contractuelle”
Ne cherchez pas non plus à vous enfermer dans un contrat. Mettre en place de l’agilité demande des efforts et un état d’esprit. Dans des grandes boîtes habituées à contractualiser du cycle en V, il faut à tout prix que le scrum master s’assure que le PO (ou son chef) ne se serve pas des cérémonies pour faire du reporting ou “flicage”. La tentation est souvent forte avec la distance en plus, il faut dans ce cas retravailler le climat de confiance entre les différentes parties.
À vous maintenant
Chacun trouvera la recette la mieux adaptée à son équipe. Au-delà de l’interrogation, peut-on faire de l’agilité dans un contexte offshore, ces pistes devraient vous aider à trouver votre comment.
N’oubliez pas de (vous) poser la question : ce que m’apporte l’outsourcing vaut-il tous les efforts nécessaires à faire fonctionner scrum en offshore ?
© SOAT
Toute reproduction interdite sans autorisation de l’auteur