La plupart des difficultés de la mise à l'échelle viennent des dépendances : une équipe qui attend une autre. Plutôt que d'ajouter des réunions pour les gérer, on cherche d'abord à en avoir moins.

Équipes par composant vs équipes par fonctionnalité

• Équipe par composant : chacune possède une brique technique (la base de données, l'interface, le moteur de calcul). Toute fonctionnalité un peu large traverse plusieurs équipes : dépendances garanties.
• Équipe par fonctionnalité (feature team) : chacune peut livrer une fonctionnalité de bout en bout, en touchant à toutes les briques nécessaires. Beaucoup moins de dépendances.

Organiser les équipes autour de la valeur livrée, pas autour de la technique, est le levier le plus puissant pour réduire les dépendances.

Découper le produit en morceaux indépendants

Quand deux parties du produit n'ont presque pas besoin de communiquer, deux équipes peuvent avancer en parallèle sans se coordonner en permanence. On investit dans des frontières nettes entre ces parties.

Le contrat d'interface

Quand une dépendance est inévitable, les deux équipes se mettent d'accord tôt sur comment elles vont communiquer (le format des échanges), puis chacune avance de son côté contre ce contrat. La dépendance devient un rendez-vous unique, pas une coordination continue.

Rendre les dépendances visibles

Un tableau des dépendances inter-équipes, revu au Scrum of Scrums : qui attend quoi, de qui, pour quand. Une dépendance vue est une dépendance qu'on peut anticiper.

Exemple concret : la plateforme de fidélité passe de trois équipes par composant à deux équipes par fonctionnalité : « parcours cliente » et « outils marchand ». Chacune touche à l'interface, au back-end et aux données. Le nombre de dépendances à coordonner chaque sprint chute de moitié.

À vous de jouer : expliquez la différence entre une équipe par composant et une équipe par fonctionnalité, et laquelle réduit les dépendances.