Parmi les expérimentations organisationnelles les plus intéressantes que j’ai pu accompagner, la mise en place de feature teams temporaires tient une place à part. Pensée pour allier agilité, transversalité et efficacité, cette approche a montré autant de promesses que de dérives si elle n’est pas rigoureusement encadrée. Voici un retour d’expérience sur ce modèle hybride, que j’ai vu se déployer dans un grand site de vente en ligne.

Pourquoi des feature teams temporaires ?

L’objectif initial était clair : permettre à l’organisation de continuer à gérer le Business As Usual (BAU) tout en accélérant le déploiement de nouvelles fonctionnalités transverses, sans créer de dépendances techniques ou humaines sur le long terme.

En d’autres termes : comment livrer vite des projets prioritaires, sans désorganiser le quotidien ni spécialiser des individus sur des sujets éphémères ? La réponse : créer des feature teams temporaires, composées de membres issus de différentes équipes socles, réunis pour développer un MVP.

Une fois la fonctionnalité livrée, les membres retournaient dans leurs équipes respectives, devenant garants de la montée en compétence collective sur ce sujet.

Comment ça fonctionnait concrètement ?

Deux approches cohabitaient :

• Le volontariat : des membres se proposaient pour rejoindre une feature team.
• L’affectation managériale : souvent discutée collectivement, mais impulsée par les managers ou responsables produits, avec un système de roulement.
  

Le transfert de compétence se faisait ensuite à travers :

• Des sessions de pair programming (notamment sur la correction d’anomalies ou les évolutions),
• Et la mise à jour de documentations spécifiques par équipe socle.
  

Les bénéfices observés

Le modèle, bien que temporaire, a apporté plusieurs bénéfices notables :

• Une capacité accrue à livrer des projets transverses rapidement, tout en maintenant le rythme des équipes socles (ou presque).
• Une responsabilisation distribuée de la connaissance fonctionnelle, grâce au retour des “spécialistes” dans leur équipe d’origine.
• Et de façon moins tangible, mais tout aussi importante : un meilleur relationnel inter-équipes, favorisé par le brassage des profils.
  

Les limites rencontrées

Mais comme souvent, la mécanique s’enraye quand le cadre n’est pas solidement posé :

Trop de projets, trop de feature teams

Avec plus de deux projets transverses en simultané, la quasi-totalité des membres des équipes socles se retrouvaient mobilisés ailleurs. Résultat : les équipes socles perdaient leur capacité de production, voire leur raison d’être.

Dilution de l’identité des équipes socles

À force de naviguer d’une feature team à une autre, le sentiment d’appartenance s’est étiolé. Et sans ancrage fort, la transmission de compétences est devenue marginale, voire inexistante.

Un modèle vite abandonné… faute de cadre

En l’absence de gouvernance solide, la promesse s’est vite effondrée.

L’incapacité à prioriser globalement les projets a mené à une inflation des feature teams, sans limite de FIP (Feature In Progress) ni synchronisation globale.

À terme, l’organisation a basculé vers une structure plus “à l’échelle” (type SAFe), avec des PI Plannings et une gestion explicite des dépendances… mais a-t-elle perdu cette capacité d’agilité transverse qu’elle avait initialement visée ?

Un modèle viable… sous conditions strictes

Plutôt que de ranger cette expérience dans la catégorie “erreurs à ne pas reproduire”, je pense que le modèle de feature teams temporaires peut avoir du sens, à condition d’un cadre rigoureux, notamment :

Un portefeuille centralisé des projets transverses, avec une priorisation uniforme

Une limite stricte de WIP (ou FIP) sur le nombre de feature teams actives

Un suivi actif des compétences et des rotations, pour éviter les “usual suspects” toujours appelés à partir en mission

En résumé

Les feature teams temporaires ont quelque chose d’élégant : elles s’attaquent à la complexité des projets transverses sans figer l’organisation. Mais sans garde-fous solides, elles deviennent vite un piège où les équipes socles s’effacent, les compétences se figent, et l’illusion d’agilité masque une perte de contrôle.

Alors, solution miracle ou fausse bonne idée ? Comme souvent… ça dépend du contexte 😉

Dans le prochain article je vous proposerais d’explorer la disparition de l’entité « équipe ».

Cet article a été rédigé en utilisant ChatGPT comme sparring partner.