Votre squad agile nearshore est en place, les rituels Scrum tournent, et pourtant la roadmap avance moins vite que prévu. Tickets bloqués en attente de validation, dépendances entre équipes, sprint reviews qui découvrent les problèmes trop tard : c’est souvent l’organisation, et non le nombre de développeurs, qui freine la livraison.
Bien organisée, une squad lève une grande partie de ces freins. Il s’agit d’une petite équipe autonome et pluridisciplinaire, responsable d’un périmètre produit de bout en bout. Bien structurée, elle livre plus régulièrement, avec moins d’allers-retours entre la France et le site nearshore.
Comment organiser une squad répartie entre deux pays ? Que signifie vraiment « gagner en vélocité » ? Quelles erreurs ralentissent les équipes distribuées ? Voici les points essentiels pour les CTO, responsables IT et Product Owners.
Sommaire
- Qu’est-ce qu’une squad agile nearshore ?
- Vélocité : ce qu’il faut vraiment améliorer
- 6 leviers pour accélérer une squad nearshore
- Les erreurs qui ralentissent les équipes distribuées
- Mettre en place une squad performante en 4 étapes
- Cas clients : des squads intégrées aux rituels Scrum
- FAQ
- Conclusion
Qu’est-ce qu’une squad agile nearshore ?
Le principe de la squad
Le terme a été popularisé par le livre blanc Scaling Agile @ Spotify d’Henrik Kniberg et Anders Ivarsson (2012). Une squad y est décrite comme une équipe auto-organisée qui dispose de toutes les compétences et de tous les outils nécessaires pour concevoir, développer, tester et mettre en production.
Concrètement, une squad réunit généralement des développeurs, un profil QA, parfois un profil DevOps ou UX, et un Product Owner qui porte les priorités. Le Scrum Guide recommande des équipes de 10 personnes ou moins : au-delà, la communication devient plus difficile et l’équipe gagne à être scindée.
La squad appliquée au nearshore
Une squad agile nearshore est une squad dont tout ou partie des membres travaille depuis un pays proche, comme le Maroc pour la France. Deux organisations sont courantes :
- la squad mixte, avec des membres en France et au Maroc qui partagent le même backlog et les mêmes rituels ;
- la squad nearshore complète, entièrement basée au Maroc, avec un Product Owner côté client.
Le faible décalage horaire (0 à 1 heure) permet de tenir les rituels en temps réel, ce qui distingue nettement ce modèle de l’offshore. Pour approfondir cette différence, consultez notre article nearshore ou offshore : quelle différence pour un CTO ?
Si vous n’avez pas encore constitué votre équipe, commencez par notre guide pour constituer et renforcer votre équipe agile grâce au nearshoring. Cet article porte sur l’étape suivante : faire livrer cette équipe plus vite.
Vélocité : ce qu’il faut vraiment améliorer
La vélocité est un outil de planification, pas un objectif
Dans Scrum, la vélocité désigne le nombre de points d’effort qu’une équipe termine en un sprint. Elle sert à prévoir ce que l’équipe peut raisonnablement livrer. Comme le rappelle Scrum.org, elle n’est pas conçue pour mesurer le succès : chaque équipe a sa propre échelle de points, et une pression sur ce chiffre pousse simplement à surestimer les tâches.
Autrement dit, une squad qui passe de 30 à 45 points par sprint ne livre pas forcément plus de valeur. Elle a peut-être seulement changé sa manière d’estimer.
Mesurer le flux de livraison
Améliorer la vélocité d’une équipe agile signifie en réalité livrer plus de valeur, plus souvent et de façon plus prévisible. Pour le suivre, quelques indicateurs de flux sont plus fiables que les story points :
- le lead time : le délai entre la prise en charge d’un sujet et sa mise à disposition des utilisateurs ;
- le débit : le nombre d’éléments réellement livrés par sprint ou par semaine ;
- le travail en cours : le nombre de sujets ouverts en parallèle, souvent responsable des ralentissements ;
- la prévisibilité : l’écart entre ce que l’équipe s’engage à livrer et ce qu’elle livre ;
- les défauts après livraison : pour vérifier que la vitesse ne se fait pas au détriment de la qualité.
6 leviers pour accélérer une squad agile nearshore
1. Donner à la squad un périmètre produit clair
Une squad avance plus vite quand elle est responsable d’un domaine fonctionnel précis plutôt que d’une liste de tickets dispersés. Ce périmètre lui permet de comprendre le contexte métier, de prendre des décisions sans attendre et de limiter les dépendances avec les autres équipes.
2. Réunir toutes les compétences nécessaires dans la squad
Chaque compétence manquante crée une file d’attente : une fonctionnalité terminée qui attend un testeur, un déploiement qui attend l’équipe infrastructure. Intégrer la QA et, si besoin, un profil DevOps dans la squad supprime ces temps morts. Sur ce sujet, découvrez comment le DevOps nearshore réduit les délais de mise en production.
3. Rendre le Product Owner disponible
Dans une équipe distribuée, un Product Owner peu disponible devient vite le principal goulet d’étranglement. Il doit pouvoir répondre aux questions dans la journée, affiner le backlog avec la squad et valider les livraisons sans attendre la sprint review.
4. Limiter le travail en cours
Ouvrir trop de sujets en parallèle allonge le délai de chacun. Une squad qui termine ses tâches avant d’en commencer de nouvelles livre plus régulièrement. Fixer une limite de travail en cours, à la manière de Kanban, est l’un des leviers les plus simples et les plus efficaces.
5. Intégrer la qualité au sprint
Les bugs découverts après le sprint reviennent dans le backlog et consomment la capacité des sprints suivants. Automatiser les tests et définir une « Definition of Done » exigeante permettent de livrer plus vite sur la durée. Pour structurer cet aspect, consultez notre guide complet de la Testing Factory.
La dette technique produit le même effet à plus long terme : apprenez à identifier et mesurer la dette technique dans votre produit.
6. Garder une équipe stable
Chaque départ ou changement de composition fait perdre du contexte et oblige l’équipe à retrouver son rythme. Une squad stable, qui travaille ensemble sur plusieurs mois, accumule une connaissance du produit qui accélère chaque sprint. C’est aussi un critère important dans le choix d’un partenaire nearshore.
Les erreurs qui ralentissent les squads distribuées
Piloter la squad par les story points
Fixer un objectif de vélocité ou comparer les équipes entre elles sur ce critère pousse à gonfler les estimations, sans aucun gain réel de livraison. Les indicateurs de flux présentés plus haut donnent une image beaucoup plus fidèle.
Séparer « ceux qui spécifient » et « ceux qui codent »
Une organisation où la France conçoit et le Maroc exécute recrée les silos que l’agilité cherche à supprimer. Les développeurs nearshore doivent participer à l’affinage du backlog, aux choix techniques et aux démonstrations.
Réduire les rituels au strict minimum
Supprimer la rétrospective ou écourter le sprint planning pour « gagner du temps » prive l’équipe de ses moments d’amélioration. Dans une équipe distribuée, ces rituels sont au contraire les principaux espaces d’alignement.
Ajouter des développeurs pour accélérer
Renforcer une squad en cours de route semble logique, mais chaque nouvel arrivant doit être formé et augmente le nombre d’échanges nécessaires. À court terme, l’équipe ralentit souvent avant d’accélérer. Au-delà de 9 ou 10 personnes, mieux vaut créer une seconde squad. Pour faire grandir votre capacité, consultez notre article sur la manière de renforcer rapidement son équipe dev grâce au nearshoring.
Adopter l’IA sans cadre
Les assistants de code peuvent accélérer le développement, mais un usage non encadré produit du code hétérogène et des revues plus longues. Nous détaillons ce risque dans notre article sur le coût caché de l’adoption opportuniste de l’IA.
Mettre en place une squad agile nearshore performante en 4 étapes
1. Mesurer la situation de départ
Avant de changer quoi que ce soit, relevez le lead time, le débit, le travail en cours et les défauts après livraison sur les derniers sprints. Ces chiffres serviront de référence pour mesurer les progrès réels.
2. Définir le périmètre et la composition de la squad
Choisissez le domaine produit confié à la squad, puis vérifiez qu’elle réunit toutes les compétences nécessaires pour le livrer en autonomie : développement, QA, DevOps et accès à un Product Owner disponible.
3. Aligner les rituels et les outils
Un même backlog, les mêmes outils (Jira, GitLab, Confluence…), un même rythme de sprint et des rituels communs : la squad nearshore doit fonctionner exactement comme une équipe interne. Un Scrum Master externalisé peut faciliter cette synchronisation dans les organisations réparties entre deux sites.
4. Améliorer en continu
Analysez les indicateurs de flux à chaque rétrospective et traitez en priorité ce qui bloque le plus le travail : dépendances, validations lentes, tests manuels. Un échange en présentiel régulier, en France ou à Rabat, renforce aussi la cohésion de l’équipe.
Chez Go&Dev, cette démarche s’appuie sur notre expertise Agilité IT & Scrum, forte de plus de 20 missions Agiles menées dans les secteurs SaaS, assurance et santé, avec des coachs certifiés PSM et SAFe : diagnostic, mise en place des fondamentaux, coaching des équipes et suivi d’indicateurs comme le lead time et la qualité.
Cas clients : des squads intégrées aux rituels Scrum
Lemonway : une équipe intégrée aux rituels existants
La fintech Lemonway devait renforcer sa capacité de développement tout en réduisant sa dette technique. Go&Dev a constitué en quelques semaines une équipe maîtrisant Vue.js et les environnements fintech.
Comme cette équipe fonctionnait en Scrum, comme celles de Lemonway, elle s’est intégrée directement aux rituels existants. Sprints coordonnés, communication continue et documentation rigoureuse ont permis d’accélérer le delivery sans rupture. Découvrez le cas client Lemonway en détail.
Cleva : une équipe pluridisciplinaire au service de la R&D
Pour accélérer la roadmap de ses projets R&D, l’éditeur Cleva s’est appuyé sur une équipe Go&Dev de 12 personnes réunissant développement, QA et MOA, constituée en quelques mois.
« Go & Dev a mis sur pied en quelques mois une équipe de 12 personnes en Développement, QA et MOA pour accélérer la roadmap de nos projets R&D. »
Rodolphe Peim, VP Groupe, Cleva
Découvrez le cas client Cleva en détail.
FAQ : squads agiles nearshore
Quelle est la taille idéale d’une squad agile ?
Le Scrum Guide recommande des équipes de 10 personnes ou moins. En pratique, une squad de 5 à 9 personnes offre un bon équilibre entre autonomie et fluidité des échanges.
Faut-il augmenter la vélocité d’une squad ?
Pas en tant qu’objectif. La vélocité sert à planifier. Pour mesurer un vrai gain de livraison, suivez plutôt le lead time, le débit et les défauts après livraison.
Une squad peut-elle être répartie entre la France et le Maroc ?
Oui. Le faible décalage horaire permet de tenir tous les rituels en temps réel. La condition est de partager le même backlog, les mêmes outils et le même Product Owner.
Qui joue le rôle de Product Owner dans une squad nearshore ?
Le plus souvent, une personne côté client, qui connaît le produit et les priorités métier. Elle doit rester suffisamment disponible pour ne pas bloquer l’équipe.
Squad et équipe Scrum, est-ce la même chose ?
Presque. Une squad est une équipe agile pluridisciplinaire et autonome sur un périmètre produit. Elle peut travailler en Scrum, en Kanban ou en combinant les deux.
Conclusion : la squad agile nearshore, un levier pour livrer plus vite
Une squad agile nearshore peut accélérer nettement vos livraisons, à condition de lui confier un périmètre clair, de réunir toutes les compétences nécessaires, de limiter le travail en cours et de mesurer le flux plutôt que les story points.
Pour les éditeurs de logiciels qui travaillent entre la France et le Maroc, ce modèle permet de combiner proximité, autonomie des équipes et prévisibilité de la roadmap.
Depuis 2017, Go&Dev accompagne les éditeurs de logiciels avec des squads de développement, de QA et de DevOps basées à Rabat, intégrées aux rituels de leurs équipes.
Vous souhaitez accélérer la livraison de vos équipes ? Contactez Go&Dev pour échanger sur vos besoins.
