Implémenter les méthodes agiles à l'échelle de l'entreprise met l'organisation des équipes au centre des réflexions. Beaucoup de personnes parlent alors de "feature teams"... mais oublient bien souvent ce que signifient réellement ces deux mots !

Vous souhaitez changer votre organisation d'équipes et comprendre la différence entre une équipe cross-fonctionnelle et une Feature team ? Cet article propose quelques axes de réflexion pour savoir de quel modèle s'inspirer et surtout comprendre ces modèles !

1) Identifier les douleurs qui poussent à changer d'organisation

La mise-en-place d'une nouvelle organisation est un processus humain complexe qui prend du temps et dont la difficulté ne doit pas être sous-estimée. Première étape avant toute considération de solution : revenir aux problèmes rencontrés et s'assurer que le changement est une solution.

-> Quelles sont les douleurs qui poussent à réfléchir à un changement d'organisation d'équipe ? -> Est-ce qu'un tel changement d'organisation est bien la solution à ces douleurs ?

Voici à titre d'exemple certaines difficultés que nous avons rencontrées dans des contextes client où les équipes sont traditionnellement réparties en silos (IT, métier, prod...) :

• un Time-To-Market considéré comme trop long,
• une difficulté récurrente à synchroniser des gros projets nécessitant la coordination de plusieurs équipes,
• une difficulté à innover efficacement, travailler en rupture,
• des problèmes de qualité dûs à une segmentation des équipes IT (ex : qui gère la qualité : dev ou QA ?),
• des problèmes de communication inter-équipes / silos métier (ex : IT vs Métier)

Dans ces contextes, une réorganisation des équipes ayant pour but de rassembler les compétences a du sens.

2) Créer des équipes cross-fonctionnelles

Une équipe cross-fonctionnelle est une équipe regroupant toutes les compétences nécessaires, de l'idée à la mise en production, pour pouvoir réaliser le produit. C'est le modèle poussé notamment par la méthodologie SCRUM. Dans cette équipe, plus de silo : toutes les personnes travaillent ensemble et sont colocalisées afin de favoriser une communication optimale. Pour la même raison, on privilégie une taille réduite : 6 à 12 personnes par équipe (pizza-team).

Une telle équipe étant composée des personnes suffisantes pour réaliser le projet, on cherchera à lui donner l'autonomie nécessaire pour prendre ses décisions en accord avec la stratégie de l'entreprise, et également la responsabilité de parvenir à réaliser les objectifs qui lui sont proposés (qui devront bien entendu être réalisables).

Voici une représentation possible d'une équipe cross-fonctionnelle agile et des intervenants avec lesquels elle interagit de manière privilégiée :

Les questions suivantes sont intéressantes à se poser ici :

-> Est-ce que l'entreprise est prête à créer des petites équipes mêlant le métier et l'IT (dev, tests, et même prod) au même endroit, dans le but de travailler ensemble au quotidien ? -> Les acteurs de ces équipes sont-ils motivés par le rapprochement et la communication directe qu'elle permet ?

Selon la culture de l'entreprise, la mise-en-place d'une telle typologie d'équipe n'est pas chose aisée, notamment sur le plan de la communication. Auparavant réglementée par documents, elle devient plus directe, les problèmes et la discussion des solutions deviennent responsabilité de l'équipe qui doit se créer un nouveau mode de fonctionnement.

Un autre sujet de réflexion apparaît également : la diffusion de la connaissance entre personnes du même métier (par exemple, les développeurs front-end) qui sont alors séparés dans différentes équipes. Une solution possible est la création de communautés de pratique permettant à ces acteurs de se retrouver régulièrement pour partager sur leur domaine d'expertise et échanger leurs bonnes pratiques.

Enfin, sujet délicat de toute transformation : la (re)définition des rôles dans les équipes, et notamment la nouvelle place du middle management qui permettait entre autres auparavant la bonne circulation des informations... Nous préconisons pour aborder ces sujets importants de tester ce type d'organisation avec 2 équipes cross-fonctionnelles composées de personnes motivées par l'expérience, et ce sur une durée de plusieurs mois (6 mois nous apparait le minimum). À l'issue de cette phase pilote, les participants auront pu appréhender et adapter les rôles au mieux selon leur contexte et fournir un retour d'expérience.

3) : Créer des équipes orientées "Feature" ou "Component"

Feature team

Afin de limiter les dépendances entre équipes cross-fonctionnelles, certaines organisations les dédient au développement et support d’un périmètre fonctionnel bien défini. Ce sont des équipes orientées "Feature" ou Feature teams.

Voici un exemple que nous donne Henrik Kniberg des Feature teams mises en place chez Spotify :

_

-> Est-ce que l'entreprise voit dans son activité des fonctionnalités "du sol au plafond" indépendantes qui pourraient être gérées par des équipes sans adhérence entre elles ? -> Est-ce que l'architecture le permet aujourd'hui ?

_

Il est important de noter que les Feature teams sont autant que possible indépendantes sur le plan organisationnel mais également au niveau de l’architecture du produit : une feature team doit être capable de livrer une nouvelle version de son périmètre sans impacter les autres équipes, ce qui lui permet d'avoir un TTM optimal.

Component team

Les équipes orientées "composant" sont des équipes qui ont :

• une importante spécialité technologique (ex : langage à la marge, progiciel,... ), maîtrisée par un petit groupe de personnes,
• et/ou gèrent un "service" utilisé par de nombreuses équipes (ex : socle de paiement, service d'emailing) qui ne devrait pas être dissocié pour des raisons de cohérence du service ou de Service Level Agreement

Dean Leffingwell (auteur du framework SAFe) présente ici cette différence entre Feature et Component teams :

_

-> L'entreprise possède-t-elle des équipes "orientées composant" qui ont vocation à rester organisées tel quel ?

_

Component team et Features team ne sont pas incompatibles. Cependant, une Component team rencontrera certaines limites :

• Son TTM est plus important que celui d'une Feature team car elle gère des demandes venant de divers acteurs et doit donc synchroniser ses réalisations pour livrer de manière équitable ces interlocuteurs
• Pour répondre à ces équipes en demande, elle a tendance à les inciter à une surconception très (trop ?) tôt
• Enfin, en tant que silo de compétence, elle peut constituer un frein à l'innovation car toute idée venant d'une autre équipe doit faire l'objet d'une demande "administrative" pour être admise en développement

Pour limiter ces problèmes ainsi que le TTM global d'une organisation, on veillera à garder donc le nombre de Component teams inférieur au nombre de Feature teams. Nous estimons la proportion privilégiée à : Feature team [70-80%] vs Component team [20-30%].

Conclusion

Une organisation en équipes cross-fonctionnelles spécialisées permet d'influer positivement sur beaucoup de problèmes constatés dans des entreprises divisées en silos métier.

De nombreux exemples et ressources peuvent se trouver sur cette thématique sur la toile (notamment cet article de Craig Larman sur les Feature teams, ou cette vidéo traitant de l'agilité chez Spotify). Néanmoins, au delà de l'organisation théorique choisie, le véritable challenge réside dans la mise-en-place du nouveau mode de communication entre les personnes. Une phase d'expérimentation avec des employés motivés par le changement sera un excellent moyen d'initier ce type de transformation.

Et vous, quel format d'équipe avez-vous mis en place ?