Dans l’article précédent, je vous parlais du modèle “une équipe, un produit” : séduisant sur le papier, efficace à court terme… mais vite rattrapé par la réalité de la croissance.

Alors, naturellement, pour répondre à l’élargissement du périmètre, beaucoup d’organisations font le pas suivant : passer à des Feature Teams.

Feature Teams : une réponse logique (au début)

L’idée est simple et plutôt saine :
“Si notre produit devient trop gros pour une seule équipe, créons plusieurs équipes, chacune responsable d’un pan fonctionnel.”

Chaque équipe est alors autonome sur une feature ou un domaine fonctionnel :

• Équipe “Recherche”
• Équipe “Commande”
• Équipe “Catalogue”
• Équipe “Paiement”
• …
  

Au début, ça fonctionne bien :

• Les équipes viennent souvent d’une même équipe initiale → culture commune
• Le code est encore partagé → standards techniques similaires
• Le PO garde une vue d’ensemble → il répartit les sujets selon les priorités et les mandats de chaque équipe
  

Tout le monde avance.
Chaque équipe livre de la valeur.
La vélocité est bonne.
La coordination tient… à peu près.

Puis, petit à petit… les frontières s’installent

Avec le temps (et la pression), plusieurs phénomènes émergent :

Le code se territorialise

Chaque équipe commence à “posséder” son morceau de code.

La base commune se fragmente, et devient une collection de modules “à ne pas toucher si c’est pas ton équipe”.

“Ah non, ça c’est le domaine de l’équipe paiement, faut leur demander…”

Les PO s’essoufflent

Un seul PO pour plusieurs équipes ? Mission quasi impossible.

Les arbitrages deviennent flous, les synchronisations pénibles, les dépendances mal gérées. Sans parler de la disponibilité du PO qui se réduit à peau de chagrin pour chaque équipe.
On en vient à multiplier les PO, chacun focalisé sur “sa” feature.
Et là… chacun commence à tirer la couverture.

L’entraide diminue

Quand une équipe est en feu ?

Les autres veulent aider… mais ne peuvent plus :

• “On connaît pas ce code”
• “On n’a pas le droit d’y toucher”
• “On n’a pas le contexte”
  

L’entraide se transforme en frustration.
Et la connaissance devient silencieusement silotée.

Les Feature Teams deviennent des Feature Silos

Ce modèle, pourtant pensé pour répartir la charge, finit par recréer les travers qu’on essayait d’éviter :

• Des spécialisations rigides
• Une perte de la vision d’ensemble
• Une dilution du sentiment d’équipe “produit”
• Des dépendances inter-équipes de plus en plus complexes
• Une surcharge des rôles de coordination (Scrum Master, PO, Lead Tech…)
  

Alors quoi, on jette tout à la poubelle ?

Non. Comme toujours, le modèle n’est pas mauvais en soi.

Il répond à un besoin précis, dans un contexte donné. S’il veut perdurer, il a besoin d’évoluer ou du moins faire en sorte que les compétences / individus puissent passer d’une équipe à l’autre, au gré des envies / besoins…

Mais il faut le faire vivre, adapter, et surtout observer les signaux faibles :

• Trop de dépendances ?
• Moins de communication entre équipes ?
• Difficulté à maintenir une qualité de code homogène ?
• Montée de l’expertise individuelle au détriment de la collaboration ?
  

Alors c’est peut-être le moment de repenser l’organisation…

Et d’explorer de nouvelles options (qu’on verra dans les prochains articles 😉).

---

🔜 À suivre :

“1 équipe, plusieurs produits : quand la logique produit éclate”

On parlera de mutualisation, de context switching, de fragmentation de la vision produit… et des limites du modèle “équipe couteau-suisse”.

Article rédigé en utilisant ChatGPT comme sparring partner.