Component team vs feature team — Que choisir ?

Cet article suite à ma présentation aux équipes internes chez @Renault Digital à Boulogne Billancourt en novembre 2017.

Les nouvelles technologies ont profondément bouleversé nos mode de vies et depuis ces dernières années le monde de l’entreprise. Avec la course aux nouvelles technologies, à l’innovation, pas un jour ne passe sans que l’on ne parle de transformation digitale ou de nouveau modèle d’organisation d’entreprise (agile, apprenante etc). Le sujet que j’aborde aujourd’hui s’inscrit dans cette tendance et concerne surtout l’organisation des équipes internes de développement de produits digitaux. Sujet qui n’est pas forcément bien anticipé lors d’un plan de transformation digitale mais qui s’avère à mon sens assez structurant pour le fonctionnement de l’équipe et le produit développé.

Cet article est le reflet de mon expérience au travers des divers postes que j’ai occupé, je suis bien entendu preneur de vos retours et avis personnels pour l’enrichir.

Pour les plus novices et pour partager une compréhension globale de ces problématiques, je vous propose de repartir de la base de la gestion de projet dans l’univers numérique.

Développer un produit digital de façon très macroscopique :

Les développements de produits digitaux suivent plus au moins la même structure dont voici les différentes phases :

1. Avoir une idée de produit ou de fonctionnalité, généralement basée sur des besoins utilisateurs à la croisé d’opportunités business.
2. Etudier ces besoins pendant une phase de cadrage afin d’identifier des opportunités de faisabilité : définir ce que l’on va faire qui va apporter le plus de valeur à notre utilisateur final. On parle également ici de timing et de budget en fonction de la taille et du mode de fonctionnement de la structure.
3. Quand on sait quel est le premier lotissement et découpage (notion de MVP) du projet, on réalise la conception technico fonctionnelle du projet : on va aller découper de façon logique, rationnelle et indépendante le besoin afin qu’il soit délivrable de façon itérative par une équipe de développement (en agile : on rédige des users stories dans un product backlog). On sait également à cette étape combien “coûte” en terme de développement chaque fonctionnalité.
4. On réalise les développements, en vérifiant à chaque itération la bonne priorisation des fonctionnalités en gardant en tête la valeur utilisateur vs les enjeux business du produit.
5. Les incréments de chaque itération sont testés. A la fin d’une grosse fonctionnalité on vérifie l’ensemble de la feature et on réajuste le tir si nécéssaire à la prochaine itération de développement.
6. On repart sur une nouvelle itération (on livre en production au fil de l’eau).

Une méthodologie de travail autour de cette façon de faire :

On va avoir une équipe projet avec des rôles bien définis, en méthodologie Agile Scrum on peut distinguer les rôles suivants :

• PO
• Scrum Master
• Equipe de développement (dans laquelle on peut inclure la Q&A et autre rôle gravitant autour du développement du produit )
• AOP….

Cette équipe va communiquer et évoluer autour de cérémonies bien définies permettant de découper / prévoir / communiquer sur le produit et son évolution, les itérations et les incréments à livrer tout en étant dans une démarche d’amélioration continue.

Pour plus d’information sur les rôles et les cérémonies, je vous recommande le scrum guide, une trentaine de pages, qui se lit très rapidement : https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf

Comment organiser ces équipes / quels profils recruter ?

Première solution : les feature teams

Le but de l’équipe est de développer une feature (ou un projet) au global, pour se faire on recrute des développeurs backend et des développeurs frontend pour avoir une équipe technique pluri-disciplinaire.

Seconde solution : les component teams

Le but de l’équipe est de délivrer un composant du produit, avec des spécialités par technologie : on va avoir par exemple une équipe Frontend web / une équipe frontend mobile IOS / une équipe frontend Android / une équipe Backend.

1) Les feature teams : l’exemple Spotify

Source de l’image : Henrik Kniberg

On a un découpage du produit par feature, et une équipe projet (en méthodologie scrum ou autre) qui est dédiée à chaque feature.

Ce mode d’organisation suit de grands principes :

• Auto-organisation : chaque équipe est auto-organisée et a sa propre façon de fonctionner.
• Indépendance : chaque équipe est indépendante sur sa roadmap de développement, elle dispose de l’ensemble des compétences techniques pour ne pas avoir à attendre des éléments bloquants d’autres équipes.
• Taille humaine : en découpant le produit en feature, on conserve des équipes de petite taille.
• Optimisation du TTM produit : chaque équipe peut livrer sans impacter les autres équipes, cela permet une mise en ligne de certains composants très rapidement.

Les feature teams, comment ça fonctionne concrètement ?

Source schéma : Charles Miglietti

• Chaque équipe (en gris de façon verticale) prend en charge une feature. Exemple : la brique des recommandations de lecture.
• Chaque tribu prend en charge une problématique fonctionnelle. Exemple : la fidélisation client dans le produit.
• Chaque guilde est un pôle de compétences technologiques (le front / le back).
• Chaque chapitre regroupe les personnes d’une même fonction. Exemple : les PO.

Le but de ce découpage est de permettre au feature team d’être indépendantes sur leur produit mais aussi de ne pas silloter la structure en maximisant le partage de connaissances entre les personnes ayant le même rôle, les mêmes centres d’intérêts…

Ce qui fonctionne plutôt bien chez spotify :

>Les équipes apprécient l’autonomie qu’elles ont sur des objectifs long terme.

>Les tribus permettent aux équipes de se renvoyer la balle sur des problématiques techniques, innovations ou autre : le partage de connaissance créé de l’émulation.

>Les équipes multi-fonction et notamment back-front permettent d’éviter les dépendances à d’autres équipes (on n’attend pas la livraison de telle ou telle brique côté backend pour démarrer les développements front)

Les feature teams, le revers de la médaille :

Nous l’avons vu juste avant, les features team permettent à une équipe d’être autonome, cependant elles ont des contraintes et des inconvénients qui sont clairs :

• Synchronisation globale : il est nécessaire de mettre en place de la synchronisation entre équipe (scrum de scrum, LESS…) entre équipe pour conserver une vue d’ensemble du produit.
• L’expertise technique est moins poussée : c’est mon retour terrain personnel, une équipe pluridisciplinaire oblige à recruter des développeurs full-stack. Lorsqu’on recrute quelqu’un de vraiment spécialisé dans le front et l’intégration par exemple, il aura plus de compétences sur son domaine d’expertise qu’un profil plus généraliste (full-stack).En théorie, la guilde est la pour renforcer le partage de connaissances entre profils d’une même technologie mais ce que j’ai constaté c’est que les équipes passent la majorité du temps ensemble ce qui renforce le vase-clos…
• Planification moins précise : en méthode agile, dans une feature team il est plus difficile de déterminer une vélocité d’équipe fiable. En effet, naturellement les développeurs plus à l’aise avec les technologies backend auront tendance à chiffrer les US backend et les développeurs plutôt front feront de même sur les US front (quelle légitimité pour un développeur backend de chiffrer du front ?…) C’est ce type de problématique opérationnelle auquelle on est confronté sur le terrain.
• Souplesse technique indispensable : si les équipes sont indépendantes sur leur feature, afin de conserver une cohérence d’ensemble sur leur produit il est nécessaire de parfois coordonner les équipes lors de phases de grosses refontes graphiques. Dans ce sens et afin de ne pas perturber un cycle de production en déploiement continu il est nécéssaire que l’équipe maîtrise au mieux les technologies de type “feature flipping” (excellent article d’Octo sur le sujet : https://blog.octo.com/feature-flipping/ ) pour livrer sans montrer la fonctionnalité dans sa nouvelle version en attendant les copains de l’équipe d’à côté.
• Expérience utilisateur moins poussée : si on souhaite développer une feature mais qu’elle est multi-plateforme (une page d’authentification sur mobile par exemple), le fait d’avoir des profils full-stack et non spécialisés par plateforme vont généralement faire tendre le produit à un produit unique pour l’ensemble des plateformes. Difficile opérationnellement d’aller chercher l’équipe sur des spécificités par plateforme (force touch sur IOS par exemple…)

2) Les component teams : l’exemple 6Play

Source : https://www.6play.fr — plateforme web

Si on part du principe opposé, au lieu de distribuer les features du produit à des équipes, on va découper le produit par technologie et par plateforme :

• Une plateforme (le web par exemple) = une équipe = un PO = un backlog.
• Chaque équipe développe l’ensemble du produit sur sa plateforme.
• Auto-organisation : chaque équipe est auto-organisée et a sa propre façon de fonctionner liée aux spécificités de sa plateforme.
• Indépendance : chaque équipe est indépendante dans sa manière de fonctionner mais le produit étant multiplateforme elle est dépendante des autres équipes pour l’aboutissement des projets.
• Taille : la taille des équipes est variable en fonction des besoins par plateforme (nécessité d’appel à la prestation extérieure pour les technologies plus exotiques)

Les component teams, comment ça fonctionne concrètement ?

Schéma : exemple d’organisation d’une structure de component teams

Grands principes :

• Chaque plateforme ayant une équipe associée, on va retrouver l’ensemble de l’univers agile qui va être dédié à chaque team.
• Les plateformes sont autonomes dans leur méthode de fonctionnement et dans leur cycle de delivery, cependant les PM (product manager) sont les grands garants de la stratégie multi canal et de la cohérence d’ensemble.
• Des rôles transverses sont obligatoires et mutualisés : PM / UI, parfois certains scrummasters. Ils sont la clef de voute qui permet la communication entre l’ensemble des équipes.

Ce qui fonctionne plutôt bien dans les équipes 6Play :

>Les équipes sont expertes dans leurs technologies respectives.

>Les estimations des équipes sont très réalistes : on arrive à avoir des planning prévisionnels fiables car les développeurs sont experts dans leur technologie.

>Les équipes peuvent adapter leurs plans de charge pour développer des projets non prévus (type événement sportif …) — forte capacité d’adaptation des plateformes aux changements de priorités.

Les component teams, le revers de la médaille :

Ce mode d’organisation propose des avantages mais aussi des inconvénients :

• Rapport front / back : les équipes front sont tributaires des équipes backend pour finaliser le développement (DoD) d’une feature. Pour une nouvelle demande front qui a besoin d’un end-point, tant que celui-ci n’est pas livré par l’équipe backend on ne peut pas finaliser les développements front.
• Découpage des US : il est nécessaire d’avoir un PO technico-fonctionnel. En effet c’est le PO qui va aller alimenter aussi bien l’équipe frontend web que l’équipe backend web. Ce type de profil n’est pas forcément courant sur un marché déja tendu côté RH.
• Backend évolutif : le backend étant transverse à l’ensemble des frontaux, il est nécessaire de s’assurer de la compatibilité permanente des anciennes versions de l’API avec les différents frontaux. Cela demande beaucoup de mise en place de tests automatisés de non régression. Cette approche est à mon sens la plus efficace car le testing manuel est très chronophage humainement et nécessite d’avoir des environnements et des JDD en permanence à jour, difficile en pratique…
• Cohérence de l’UX/ la spécialisation des équipes par plateforme engendre une multiplicité des écrans produits (la conception se fait par plateforme…), il est nécéssaire de mettre en place un PO central qui va garantir une uniformité du produit développé malgré l’exploitation des spécificités des plateformes par écran.
• Recrutement : il est actuellement très difficile de pérenniser dans les équipes des profils d’experts sur une technologie du fait du marché très tendu sur la partie développement.

En résumé

Les feature teams :

• Avantage : j’ai constaté que c’était très efficace pour un projet en mode « rush » : opération événementielle etc…
• Avantage : au quotidien j’ai pu voir que dans les cérémonies agiles le partage de connaissance était important du fait du mélange des technologies et des profils. Vu que l’ensemble de l’équipe était ensemble en temps réel il n’y avait pas de problèmes de synchronisation entre front et back
• Inconvénient : l’équipe respectant la règle 1 équipe = 1 backlog = 1 PO, le staffing était restreint (facteur limitant = le PO). Je pense qu’il est difficile de dépasser 6 développeurs pour un PO.
• Inconvénient : j’ai eu beaucoup de mal à avoir des chiffrages fiables par mes équipes en feature team (vu dans diverses entreprises) : entre les profils mélangés (front et back) & la personnalité de chacun dans l’équipe, c’était souvent les mêmes personnes qui influaient le chiffrage et nous avions des vélocités d’équipes assez aléatoires.

Je vous recommande ce mode d’organisation sur des produits avec des équipes restreintes (<6 personnes par exemple). En effet il serait compliqué de gérer des équipes de 2 personnes (si on découpait en component team) pour des questions évidentes de relecture de code, tests etc…

Les component teams :

• Avantage : a chaque fois que j’ai expérimenté ce type d’organisation, j’ai vu la qualité des développements augmenter de façon significative. L’équipe d’experts par plateforme / technologies se donnait le change pour s’améliorer et au fil des relecture de code cela permettait à l’équipe de tendre vers l’excellence.
• Avantage : les experts dans leurs domaines étaient beaucoup plus précis sur les chiffrages et nous avions des projections de planning réalistes.
• Inconvénient : j’ai pu observer que le rapport de dépendance back / front entrainait de l’inertie dans les développements (1 mois de délais pour un besoin émis à l’autre équipe au début de son sprint pour des sprints de 15 jours)
• Inconvénient : la multiplicité des expériences utilisateurs par plateforme engendre une cohérence d’ensemble compliquée à maintenir car chaque équipe veut aller au plus loin dans les dernières innovations que propose sa technologie.

Je vous recommande ce mode d’organisation sur des produits plus dimensionnés en terme de budget et d’équipes. Un produit ou l’on souhaite pousser l’expérience utilisateur au maximum de ce qu’il est possible de faire sur un device ou une plateforme sera particulièrement adapté.

Au global chaque mode d’organisation présente de réels avantages et inconvénients. Il n’y a pas de voie royale : à vous de choisir en fonction de vos contraintes =)

Merci de votre lecture.

Lakmeche Rémi

Avec les conseils et la bienveillance de @Fatima Katafer / @Nicolas Thouanel