Depuis que j’accompagne les équipes agiles, je rencontre toutes sortes de configurations organisationnelles. Des modèles parfois très différents, mis en place pour répondre à des besoins bien spécifiques, dans des contextes très concrets. Et pourtant, malgré des intentions louables, beaucoup de ces organisations finissent par générer de nouvelles tensions, de nouveaux freins.

Je vous propose, à travers cette série d’articles, d’explorer plusieurs modèles d’organisation d’équipes et de gestion des compétences. Mon intention n’est pas de prescrire un modèle parfait – je doute qu’il existe – mais de partager des retours d’expérience, des observations et des pistes de réflexion pour adapter ces modèles à votre propre contexte.

Une équipe, un produit… le modèle idéal ?

Quoi de plus simple que cet adage ? Avoir une équipe unique, multi-compétente, capable de répondre à l’ensemble des besoins de son produit. Une équipe auto-organisée, capable de construire, faire évoluer et maintenir un produit dans la durée. Bref, le fonctionnement SCRUM dans sa forme la plus pure.

Ce modèle a beaucoup d’atouts :

• Une forte proximité avec le produit et ces utilisateurs
  
• Un backlog clair, centré sur un objectif commun
  
• Des compétences partagées au sein de l’équipe
  
• Une grande réactivité face aux besoins métiers / utilisateurs
  

À tout moment, l’équipe est en capacité de livrer de la valeur. Les fameuses notions de “team ownership” et de “truck factor” sont bien traitées : la connaissance est partagée, les responsabilités sont collectives. L’équipe est soudée, efficace, agile au sens noble du terme.

Oui mais… la réalité revient vite frapper à la porte

À force de produire de la nouveauté, de devoir aller toujours plus vite, l’équipe finit par ne plus suffire.

Elle ne suffit plus à gérer le RUN dans le cadre d’un fonctionnement SCRUM classique.

Elle ne suffit plus à livrer les nouveautés les plus attendues dans des délais décents.

Elle ne suffit plus à faire face à la croissance du produit, du nombre d’utilisateurs, des dépendances.

On pourra toujours dire que c’est au PO de faire son travail de priorisation. Mais lorsque les contraintes deviennent trop fortes, lorsque les demandes s’accumulent, la taille limitée de l’équipe devient une contrainte structurelle.

Même si, dans sa version la plus récente, SCRUM ne met plus vraiment de limite à la taille de l’équipe, la faire grossir n’est pas si simple :

• Plus l’équipe grandit, plus la synchronisation devient complexe (loi de Brooks)
  
• Les compétences se spécialisent, parfois de manière informelle
  
• Le RUN s’accumule et prend de plus en plus de place
  
• Le temps passé à communiquer, se coordonner, arbitrer augmente
  

Le modèle “une équipe, un produit” devient alors difficile à maintenir à l’échelle. Il montre ses limites face à la réalité du terrain… ou plutôt à celle du marché.

Et maintenant, on fait quoi ?

C’est souvent à ce moment-là que les organisations basculent vers d’autres modèles :

👉 des feature teams,

👉 des squads,

👉 des équipes build/run séparées,

👉 ou des modèles plus hybrides et adaptatifs.

Mais là encore, chaque solution apporte son lot de nouvelles problématiques.

Et c’est ce que je vous propose d’explorer dans les prochains articles de cette série.

---

🔜 À venir dans l’article 2 :

“Feature teams : quand les fonctionnalités deviennent des silos”

On parlera de découpage fonctionnel, de chasse gardée, de code partagé (ou pas), et de ce qu’il se passe quand les équipes deviennent un peu trop… spécialisées.

Article créé avec l’assistance de ChatGPT en sparring partner…