Une squad ne tient pas la durée grâce à des "coups d'éclat". Elle tient parce que chacun sait exactement ce qu'il doit faire, pourquoi il le fait, et comment ça s'articule avec les trois autres qui travaillent à côté.
Pendant trois ans, nous avons vu des squads de cinq personnes livrer deux fois plus que des squads de huit. Pas parce qu'elles avaient mieux codé. Parce qu'elles passaient 60% moins de temps à se reposer, à se revalider, ou à attendre une validation qui ne venait pas.
La confusion des rôles, c'est le premier frein à la vélocité. Pas le manque de compétences. Pas la tech mal choisie. La confusion.
La taille idéale et pourquoi elle compte
Le nombre magique c'est 5-7 personnes : un Product Owner (ou Product Manager), un Tech Lead, deux à trois développeurs, un designer UX/UI, et optionnellement un data analyst qui joue aussi le rôle de QA.
Pourquoi 5-7 ? Trois raisons.
D'abord, c'est la limite de la communication sans dégradation. Au-delà, vous avez besoin de coordinateurs. Les coordinateurs ne livrent rien. Elles mettent de l'ordre. C'est utile, mais à 8+ personnes, c'est déjà 15-20% de capacité brûlée juste pour que tout le monde se comprenne.
Deuxième : c'est la taille où tout le monde est responsable du résultat. À 3 personnes, chacun porte le poids. À 12, il y a toujours quelqu'un pour dire "ce n'était pas ma partie". À 5-7, c'est juste assez pour avoir des spécialistes, mais pas assez pour diluer la responsabilité.
Troisième : c'est la taille où un ritual de 30 min (stand-up) ou 1h30 (planning) reste efficace. Au-delà, soit vous faites des réunions plus longues (temps perdu), soit vous fragmentez (deux canaux de communication différents, ça crée des failles).
Équipes que nous avons vu exploser : 2 squads de 7, pas 1 squad de 14. Équipes qu'on a vu stagner : 1 squad de 12 où personne ne sait vraiment qui decide.
👉 Si vous êtes à 9+ personnes aujourd'hui et que vous trouvez ça lent, la réponse n'est pas plus de management. C'est une deuxième squad.
Les rôles qui font tenir debout (et ce qui explose quand ils manquent)
| Rôle | Responsabilité critique | Signal d'alerte |
|---|---|---|
| Product Owner | Priorisation weekly, arbitrage rapide sur les conflits, feed utilisateurs remontée en backlog | Backlog jamais mis à jour, décisions qui flottent 3 jours, l'équipe "attend" plus d'une fois par semaine |
| Tech Lead | Architecture décisions, cohérence technique, dette technique tracée, code review des critiques, plan de scaling | Pull requests sans context, aucune doc d'architecture, la même erreur rappaît deux fois |
| Développeurs (2-3) | Exécution, test, premier level de review, alerter rapidement sur les surprises tech | Livraisons tardives sans raison communiquée, bugs répétitifs en production, aucun escalade quand ça bloque |
| Designer | Flot UX validé avant dev, cohérence visuelle, testabilité UX, feedback utilisateur intégré | UI livrée sans avoir été testée, confusion "jolie" vs "marche bien", itérations tard en sprintparce que personne n'a validé avant |
Le piège classique : penser qu'on peut "sauter" un rôle. Genre "le PO fera aussi du design" ou "on n'a pas besoin de Tech Lead, tout le monde peut review". C'est techniquement possible. Vous allez livrer pendant 6-8 semaines, puis la dette s'accumule : plus personne ne sait comment ça marche, les designs sont cassés, les priorités flottent.
Trois mois plus tard, vous avez perdu plus de temps en réunions de clarification que vous n'en aviez gagné.
Les rituels qui fonctionnent (et ceux qui sont du théâtre)
| Rituel | Fréquence | Durée | Objectif | Succès = |
|---|---|---|---|---|
| Standup async | 5j/semaine, matin | 10 min par personne | Signaler blocages, se voir avancer | Zéro surprise en réunion, blocages remontés 4h avant standup |
| Refinement | Hebdo | 1h30 | Casser les user stories, estimer, identifier risques | Aucune story au planning n'est un "OK on verra" |
| Sprint Planning | Bi-hebdo | 1h | Choisir quoi livrer, accepter les risques connus | L'équipe dit "on peut livrer X" ou "on peut livrer Y", pas "on essaie" |
| Demo + Retro | Bi-hebdo | 1h | Montrer ce qui a été livré, apprendre ensemble | On change minimum une chose chaque retro, pas "c'était bon" tout le temps |
| Tech Sync | Hebdo, 30 min | Async ou sync | Dettes techniques, scaling, refactoring priority | Une action claire par semaine, sinon c'est du blabla |
| 1-on-1 PO/TechLead | Hebdo | 30 min | Clarifier blocages, ajuster priorités discrètement | Les conflits restent entre vous deux, pas aérés en stand-up |
Les rituels qui disparaissent vite : daily standup en personne (remplacé par un message Slack le matin), réunion "on verra ce qu'on fait aujourd'hui" sans backlog, retro où on dit "tout va bien" (c'est un mensonge, vous apprenez rien).
"Les bonnes équipes itèrent sur leurs rituels chaque mois. Les équipes bloquées gardent les mêmes réunions depuis deux ans."
Comment les décisions se prennent (sans réunion)
La vraie vitesse, c'est moins de réunions, pas plus. Comment ça marche ?
Les petites décisions (un choix de tech, une copie UI, un changement de données) : le propriétaire de la fonctionnalité décide et ping les deux personnes concernées en async. Délai : 2-4 heures, pas une réunion.
Les décisions moyennes (architecture d'une feature, trade-off de temps, design majeur) : le PO + Tech Lead + Designer = 30 min de sync. Les autres voient le résumé dans un Slack thread. Délai : 1 journée, c'est ok.
Les grosse décisions (nouvelle direction produit, refactoring majeur, pivot de tech) : full squad meeting une fois par semaine. Pas plus. Vous ne prenez que les trois décisions vraiment critiques. Le reste attend.
Le piège : mettre tout en réunion "on verra ensemble". Résultat : 1h de réunion pour une décision qui aurait pris 10 min en async. Multiplié par 15 décisions par semaine, c'est 15 heures perdues.
Les meilleures squads qu'on a vues avaient une règle simple : tout est async par défaut, synchro seulement si l'async est en train de traîner depuis 4h. Ça crée une urgence naturelle. Les gens décrochent de la réunion dès qu'ils ont la réponse.
👉 Comptez les heures de réunion chaque semaine. Si c'est plus de 6-8h, vous avez un problème de clarté organisationnelle, pas un problème de talent.
L'ownership explicite (et pourquoi c'est le vrai multiplicateur)
Le plus grand tue-la-vélocité : "on va partager ça". Un feature est "de tous" = elle est "de personne". Trois semaines plus tard, elle n'est pas livrée, personne ne sait qui la suivait.
Voici comment on crée l'ownership qui marche :
Chaque epic ou grosse feature a un propriétaire critique. C'est souvent un développeur. Ça peut être le PO pour du pur produit. Jamais deux. Cette personne :
- reçoit tous les messages à ce sujet
- escalade si ça bloque après 4h
- donne des updates toutes les 48h
- fait le QA avant de crier "livré"
Deuxième cercle : le Tech Lead (si pas propriétaire) et un autre dev. Ils connaissent le contexte, peuvent prendre le relais en 30 min si le propriétaire est malade, et font la première review.
Tout le monde sait qui call. C'est pas "demandez à quelqu'un", c'est "demandez à Alice".
Résultat : aucune ambiguïté. Aucune "oh, je pensais que tu faisais ça". La coordination coûte 5% du temps, pas 30%.
Les signaux d'une squad en bonne santé
Vous pouvez vérifier ça une fois par mois :
Vélocité stable (pas en montée, pas en crash). Si elle oscille de 40% chaque sprint, quelque chose dans les rituels ou l'organisation crée du chaos.
Aucune feature " bloatée". Si vous avez une story qui prend 4 semaines parce qu'elle n'était pas bien cadrée, c'est un problème de refinement ou de clarté.
Bugs rares en production (< 3 par sprint). Pas zéro (c'est pas réaliste), mais pas 15 non plus.
Turnover très bas. Les gens veulent rester. Si quelqu'un part après 6 mois, demandez pourquoi. Souvent c'est "trop de réunions", "personne ne savait qui décidait", "on ne livre rien".
Zéro "surprises" en démo. Ce que vous livrez, c'est ce qui avait été promis. Pas de "oh, on a changé un truc" au dernier moment.
Une idée claire du backlog pour les 3 prochaines semaines. Pas parfait, mais clair. L'équipe sait à quoi s'attendre.
Si vous avez 4 sur 6 de ces signaux, c'est bon. Vous êtes au-dessus de la moyenne. Si vous en avez 2, il y a quelque chose à réparer dans l'organisation elle-même.
Les anti-patterns qui tuent (et comment les reconnaître tôt)
| Anti-pattern | Signe classique | Pourquoi ça paraît normal au départ | Durée avant crash |
|---|---|---|---|
| Aucune retro (ou retro théâtre) | "Tout va bien" chaque fois | C'est plus rapide | 8-12 semaines |
| PO absent (décisions qui flottent) | L'équipe propose 3 solutions et attend | "On est autonomes" | 4-6 semaines |
| Tech debt non tracé | "On va le faire plus tard" | C'est plus rapide short-term | 6-10 semaines |
| Refactoring jamais fait | Plus de tests = plus lent | Vrai. Mais le debt explose | 10-16 semaines |
| Trop de meetings | "On aligne mieux" | Court-term alignment | 8-12 semaines |
| Aucune accountability | "On ne savait pas qui faisait quoi" | Pas d'escalade rapide | 6-8 semaines |
La bonne nouvelle : vous avez 6-12 semaines avant que ça devienne un problème sérieux. Vous pouvez le voir venir et le corriger.
Résultat : stabilité + vélocité
Une squad bien organisée livre 2x plus qu'une squad de même taille sans organisation claire.
Pas parce qu'elle code mieux. Parce qu'elle perd moins de temps à se réaligner, à attendre une décision, ou à paniquer quand une crisis arrive.
La clarté c'est un multiplicateur de vitesse. C'est ça qui change tout.
👉 Si votre squad est en chaos aujourd'hui, vous n'avez pas besoin de plus de monde. Vous avez besoin d'une journée de planning pour clarifier les rôles, les rituels, et les décisions. Une journée. Ça paraît rien. Ça change six mois.
Si vous avez une équipe qui explose ou qui stagne, et que vous trouvez que c'est un problème d'organisation plutôt que de talent, on peut vous aider à structurer ça. C'est souvent 2-3 semaines pour avoir un cadre propre qui tient la distance.