Comment construire un produit lorsque l’équipe est répartie sur 3 continents ? Comment collaborer, en pratique ? Quels sont les pièges qui attendent au tournant ?

Nous vous proposons ici un ensemble de bonnes pratiques issues du terrain, mais attention : cet article ne contient pas LA vérité du développement de produit en remote, mais UN retour d’expérience d’une organisation adaptée aux contraintes de notre projet.

“Chacun chez soi, et les rituels seront bien maintenus !”

****Un peu de contexte : 1 équipe, 4 lieux

Le client est un groupe industriel avec des opérations sur tous les continents. Nous fabriquons ensemble une application mobile pour le grand public, et l’équipe est à l’image du groupe : intercontinentale.

• Développeurs/QA/UX : 8 personnes plein-temps à Toronto, sur le site client
• Copywriter : 1 prestataire externe à temps partiel à Toronto, mais ailleurs
• PO/Co-PO/PM/Métiers : équipe mixte de 8 personnes OCTO/client à Paris
• 2e UX : 1 prestataire externe en Argentine, qui nous a rejoint en cours de route

50 nuances de distance

• La distance physique, qui change la nature et la fréquence des interactions
• Le décalage horaire de 4 à 6 heures : notre journée commune commence à 15h à Paris. Du coup, nous sommes très souvent en réunion de 15h à 19h, et la demi-journée restante permet de se concentrer sur les tâches productives
• La distance culturelle : l'équipe rassemble des nationalités d'Inde, de France, du Canada, et d’Argentine
• Langue : l'anglais et ses multiples accents, pas toujours évidents à comprendre par téléphone

Démarrage : tout le monde sur place pendant 2 jours

Nous avons démarré le développement par un séminaire de 2 jours dans les locaux à Toronto, pour faire connaissance et profiter d'animations postito-ludiques. Nous ne nous étendrons pas sur ce séminaire car l’article traite de ce qui vient après : le remote

Le remote au quotidien  

De manière générale, pour toutes les réunions à distance si vous le pouvez, identifiez un facilitateur, qui aime faire ça si possible. Ç****a change tout ! S'il n'est pas partie prenante des discussions, il va mener la réunion à son terme, vérifier que toutes les questions sont répondues, surveiller l'heure, attribuer la parole, garder le rythme, et éviter les flottements. Nous ne le faisons pas tout le temps et nous en voyons la différence.

Nous avons dans l'équipe de Toronto un Scrum Master qui est devenu le point de contact privilégié entre PO et dev, et ça apporte beaucoup de valeur. Non pas qu'il fasse l'intermédiaire et qu'il limite les communications directes, mais il est le point de référence pour les questions en l'absence des (co)PO, soit la moitié du temps travaillé.

Du reste, voici comment ça se présente chez nous :

• Méthodo Scrum : c'est pratique à distance et à 1/2 journée de décalage. L’équipe se synchronise en début et fin de sprint, et hop l'équipe de dev est indépendante pour 2 semaines. Dans les grandes lignes évidemment. Le besoin de synchro et de communication reste quotidien, mais les priorités sont fixées pour 2 semaines, ce qui évite les questions structurantes qui pourraient paralyser quelqu'un pendant une demi-journée en attendant son interlocuteur. Ça donne de la marge au besoin de synchro.
• Réunions via Zoom. Bonne qualité audio et vidéo et partage d'écran facile. Pas besoin de login pour les participants. Sur navigateur, il manque la possibilité d'afficher tous les participants en même temps en vignettes vidéo, il n’est possible de voir que celui qui parle.
• Discussions via Slack : c'est pratique pour solliciter rapidement et partager, mais attention au chaos. La dernière personne arrivée dans l'équipe a commencé à l'utiliser façon chat pour poser des questions et partager sur les canaux communs, et ça devient très vite illisible, les fils de conversation se mélangent. On a dû se mettre d'accord sur l'usage - exemples : un canal par epic, utiliser les sous-fils de discussions pour répondre plutôt que le fil principal, penser mail plutôt que chat sur les canaux partagés, etc.
• Daily via Zoom : ça marche bien, tout le monde parle spontanément dans le même ordre à chaque fois, autrement le top est que quelqu'un attribue la parole à chacun. En revanche, l'équipe de dev est ensemble dans une salle et il n’est pas toujours évident de bien les entendre. C'est mieux quand chacun est connecté sur son propre PC. Les daily ont tendance à durer plutôt 20 minutes que 10, mais c'est normal et utile quand on a moins facilement la possibilité d'échanger, du fait de la distance et du décalage horaire.
• Sprint planning, grooming et review en Zoom avec JIRA et Zeplin, avec le backlog de sprint et les maquettes en partage d'écran. Ç****a marche très bien si votre JIRA est propre (dans notre cas : tous les tickets prêts selon la Definition of Ready*, avec maquettes, dans le nouveau sprint et triés par priorité), nous passons en revue et estimons successivement chaque ticket du futur sprint, et nous arrêtons quand la capacité théorique est atteinte.

*Complément d’information sur ce point : dans notre contexte distant et décalé, nous préférons fonctionner sur la base de stories détaillées et de maquettes finalisées. Nous essayons de couvrir tous les scénarios et toutes les questions sur une story pendant la conception, puis en grooming, et enfin en sprint planning, et traçons tout ce détail dans le ticket. Nous cherchons par là à limiter les questions qui bloqueraient les développeurs dans l’écriture du code, qui devraient alors parfois attendre une demi-journée pour obtenir une réponse. Post-sprint planning, les questions des QA/dev sur les user stories sont posées en commentaires sur JIRA, et nous rebouclons en daily si besoin de précisions ou complément. Nous nous astreignons à être hautement réactifs sur les notifications, ça permet à la fois de donner une réponse quasi-immédiate et de tracer l’information. Le scrum master joue aussi un rôle important à partir de là. il code moins souvent que les autres et participe plus aux réunions, ce qui lui permet d’avoir le même niveau d'information sur tout le backlog que les PO.

• Rétrospectives avec MIRO et Zoom, la version gratuite de Miro suffit si vous souhaitez travailler avec une seule équipe. Il n’est pas possible de créer un tableau à partager avec l’équipe de ce produit et un autre avec celle d’un autre produit par exemple. Mais vous pouvez en créer un pour l'un et en rejoindre un créé par quelqu'un d'autre pour l'autre. Nous avons démarré avec un format basique Start Stop Keep pour habituer tout le monde à l'outil, puis nous pourrons varier les plaisirs. Ci-dessous le modèle que nous avons créé.

Astuces : verrouiller tout ce qui ne doit pas bouger pour éviter que ça soit déplacé accidentellement (c'est systématique), attribuer une couleur de post-it par personne et un ordre de parole, préparer les éléments clé en main à copier-coller pour les participants (post-its, gommettes de vote, etc.)

Notre rétrospective sur MIRO

• Démonstration présentée par les dev via Zoom, en partageant l'écran depuis un smartphone via l'app mobile Zoom. Pour l'équipe qui présente, c'est beaucoup plus sympa si les participants sont sur webcam. Autrement le silence et l'absence d'image du public sont vraiment désagréable dans un moment comme ça. Vous vous autorisez moins de réactions spontanées à distance, donc pour le présentateur c'est dur de récolter du feedback.
• Roadmap PPT partagée sur Confluence et tenue à jour en permanence. Nous pensons faire la prochaine roadmap sur MIRO pour qu'elle soit plus directement visible par tout le monde.

La conception à distance  

Pas évident de concevoir des fonctionnalités avec 2 UX, 2 PO et les développeurs dans 3 pays et fuseaux horaires différents. Nous nous sommes dit qu'un séquencement des tâches avec un rythme régulier aiderait là-dessus, nous avons donc opté pour une approche inspirée du design sprint. Cela dure pour une fonctionnalité entre 7 et 10 jours, surtout en fonction de la possibilité de démarrer tôt les ateliers initiaux :

1. Atelier Example mapping : PO, UX, QA, 1 dev : nous couvrons le contenu de la fonctionnalité, les règles, les questions
2. Atelier Sketching : PO, UX, QA, 1 dev : méthode 6 to 1
3. Maquettes : UX : d'abord partagées via Invision, puis nous l’avons laissé de côté pour Zeplin
4. Tests utilisateurs : UX : à distance via usertesting.com et en physique en guerrilla testing, ~5 personnes à chaque fois
5. User stories : PO : découpage et rédaction des stories sur JIRA

Nos difficultés : nous n’avons jamais réussi à prendre de l'avance entre la conception et le développement, l’équipe finit toujours pile à l'heure pour le sprint planning ; pas toujours facile de gérer l'avancement en parallèle de plusieurs features ; pas le temps d'avoir une étape de validation par la Product Manager entre la conception et le sprint de dev. Nous avons pallié à ça récemment en validant plutôt le cadrage des features ensemble en amont.

En pratique :

• Example mapping avec MIRO et Zoom, mêmes conseils que pour la rétro : préparer un modèle clé en main et verrouillé, que les participants n'aient que du copier-coller à faire. Le PO mène la discussion mais tout le monde a la possibilité d'interagir avec le modèle

Un atelier d'example mapping avec MIRO

• Sketching avec MIRO web + mobile (gratuit aussi) et Zoom : c'était ce sur quoi nous avions le plus de doutes au départ, et ça fonctionne finalement pas mal : chacun dessine de son côté pendant que l'animateur gère le temps, chacun importe directement ses oeuvres en photo sur MIRO via l'app mobile, puis on partage, chacun pose des pastilles sur les bonnes idées, et on joue un 2e round

Un atelier sketching avec MIRO

• Une réunion de synchro PO-UX chaque vendredi pour planifier la semaine à venir : quels ateliers quels jours, quelles échéances pour les maquettes et les tests. Plus récemment, avec 2 UX à distance, nous sommes passés à un daily dédié au design après le daily commun
• La suite se passe à distance sur JIRA et Zeplin avec le tableau dédié à la conception, les assignations, les pièces jointes :

Notre processus de conception sur JIRA

Les galères

So far à peu près so good, mais nous n’avons tout de même pas réussi à éviter quelques désagréments :

• La com’ et l'implication de l'équipe sur les prises de décisions rapides impactantes : le problème d'avoir une demi-journée de décalage, c'est que lorsqu’il faut prendre des décisions rapides, nous ne pouvons pas toujours avoir tout le monde dans les réunions. Résultat, nous en avons perdu en route sur certains virages, et ça a impacté l'esprit d'équipe ainsi que l'efficacité à court terme. Les signaux d'alerte sont plus difficiles à déceler à distance. Nous recommandons de bien peser les risques avant d'aller au plus vite, et de prendre tout de suite après des actions compensatrices pour vérifier le partage d'info, l'adhésion, la compréhension de toute l'équipe
• Les personnes qui n'étaient pas dans les invitations, ajoutées à la dernière minute, et qui n'ont pas encore accès aux outils, comme MIRO ou JIRA : 10 minutes perdues garanties
• Les bouts de discussions sur Slack, puis JIRA, puis daily, puis un autre canal Slack, puis on ne sait plus où est la dernière info : ça n'arrive pas souvent mais c'est le piège quand quelqu'un de nouveau arrive dans l'équipe et rejoint progressivement les outils. C'est facile de laisser dériver un process ou une convention d'utilisation et à distance, il est d'autant plus nécessaire de remettre au plus vite les règles au clair, car ce sont les points de repère de tous pour savoir où est l'info
• La collaboration PO-UX est un peu limitée par le décalage temporel et la distance, qui poussent à une séparation des tâches plus qu'une mise en commun, par souci d'efficacité. Nous essayons de trouver le juste milieu

***

Voici, en somme, l'organisation et l’outillage que nous avons mis en place et adaptés progressivement dans le contexte spécifique de ce produit. Nous réfléchissons en début de projet à différents scénarios, puis test & learn ! Nous ajustons en fonction de ce qui fonctionne ou non avec les équipes. Il n’y a pas une règle, mais de bonnes manières pour réussir collectivement le développement d’un produit. Puisse cet exemple servir de source d’inspiration pour vos propres contextes, à tester, décliner, améliorer.

Ça vous inspire ? Vous vous posez des questions sur comment mettre en place le remote ? Vous aimeriez en savoir plus ? Contactez-nous ;)