Feature teams : au service de la transformation digitale

Il y a 1 mois, nous avons publié cet article dans IT Expert. Vous l’avez manqué ? Pas de soucis, le revoilà !

Les transformations digitales sont omniprésentes. L’apparition de nouveaux modèles économiques centrés sur le client imposent une remise en cause à la fois organisationnelle, économique, technologique, managériale et culturelle.

En 2015, même les grosses structures se doivent d’être réactives face à une concurrence qui émerge chaque jour avec des approches totalement disruptives. Il faut considérer qu’aucun marché n’en est à l’abri. Des start-ups comme Uber, Blablacar ou CapitaineTrain, qui proposent de nouveaux usages à vitesse grand V, en sont les meilleures exemples.

Au centre du débat se côtoient des enjeux de diminution du TTM (Time To Market), de réduction du coût d’un nouveau service, d’augmentation de qualité des produits, d’amélioration du bien-être des collaborateurs et d’innovation.

Dans bien des cas, les modèles organisationnels actuellement en place, fruit de la rationalisation des systèmes d’information depuis plus de dix ans, ne le permettent plus. Les organisations orientées « composants » ont fait sens dans des environnements où la spécialisation des collaborateurs était le maître mot. Ce fût particulièrement le cas à l’âge d’or des applications N-tiers, où le choix prédominant consistait à confier la responsabilité d’une couche applicative à une équipe dédiée. Aujourd’hui, nous constatons souvent que les plateaux de développement organisés selon ce schéma (les component teams) ne délivrent plus. La complexité du pilotage et de la synchronisation de ces équipes dites « contributeurs », dépendantes les unes des autres, sclérose littéralement la capacité de delivery.

Cela peut paraître simpliste, mais aujourd’hui, si vous voulez sortir des fonctionnalités (features) rapidement, il convient de mettre en place une organisation qui permettent de les confier à un groupe de personnes responsabilisées avec une culture produit : des Feature Teams. Ce modèle n’est ni nouveau ni une solution miracle. Il est actuellement remis au goût du jour car il constitue une solution viable face aux nouveaux challenges.

Le concept : exemple de Spotify

Vous pensez qu’il n’est pas utile de vous présenter Spotify ? Ce service de streaming musical a changé notre manière de consommer de la musique. Il est le compagnon quotidien de 60 millions d’utilisateurs dont 15 millions d’abonnés. 25 % de profils payants pour un business model freemium, c’est une réussite insolente. La société n’existe « que » depuis 2008.

Pour supporter sa croissance organique, essentiellement en R&D et réussir à conserver ce qui fait la force des start-ups (agilité, réactivité, qualité des développements, solutions techniques state-of-the-art), Spotify s’est appuyé sur les Feature Teams. Ils n’ont pas hésité à le faire savoir dans la communauté agile par le biais d’Henrik Kniberg grâce à une publication diffusée en octobre 2012 qui décrivait leur implémentation du modèle : Scaling Agile @ spotify. Il présente le schéma organisationnel global suivant :

Schéma organisationnel du modèle Spotify

Ce modèle s’appuie sur le vocabulaire qui a cours chez Spotify : Squad, Tribe, Chapter et Guild.

Les squads sont les équipes de développement. Leur définition est très imprégnée de ce qu’est une équipe agile selon le cadre Scrum. Une squad fonctionne comme une mini-startup, elle dispose d’une grande autonomie et est responsable d’un pan fonctionnel bien délimité, de l’idée à sa mise en production, pendant une période de temps suffisamment longue. L’équipe stable, colocalisée, auto-organisée, dispose de toutes les compétences et outils nécessaires pour concevoir, développer, tester et livrer.

Elle est constituée de 5 à 9 personnes, dont le Product Owner qui est le garant de la vision fonctionnelle pour cette équipe.

Les tribus (tribes) sont un agrégat de plusieurs squads. Là encore, la colocalisation est un choix fort : toutes les squads d’une même tribu sont réunies en un même endroit. Une tribu est mûe par un plus grand objectif fonctionnel, cela signifie que les squads travaillent sur des domaines intimement liés. Il s’agit, par cette proximité, de limiter les dépendances entre les équipes et idéalement de les supprimer entre tribus.

Une tribu est composée d’au maximum 100 personnes pour respecter le nombre de Dunbar. Pour rappel, le principe du nombre de Dunbar assume qu’au sein d’un groupe, au-delà de 148 personnes, il est difficile de maintenir des relations sociales stables. Au-dessus de ce nombre, la confiance mutuelle et la communication ne suffisent plus à assurer le fonctionnement du groupe. Il faut ensuite passer à une hiérarchie plus complexe, avec une structure et des règles importantes.

Enfin, une tribu est menée par un « servant leader ». Sur ce point, il est possible d’entrevoir une rupture d’approche du management. En effet, en repoussant au maximum les responsabilités au sein de la squad et en promouvant l’auto-organisation, il est nécessaire que le manager opère un changement de posture. Il doit se mettre à la disposition de la tribu pour s’assurer qu’elle est capable d’amélioration continue et qu’elle bénéficie de tous les moyens nécessaires à l’accomplissement de sa mission.

Tribus et squads sont là pour garantir une capacité de delivery fonctionnel. Une fois cela défini, comment s’assurer de la cohérence du système dans son ensemble ? C’est pour répondre à ces besoins que les chapters et les guilds entrent en jeu.

Les chapters sont les ensembles de personnes d’une même tribu qui travaillent sur un domaine d’expertise commun. En français, on parle souvent de communautés de pratique. Chapoté par un leader issu d’une squad et élu par ses pairs, c’est une cérémonie opérationnelle. A intervalle régulier, ces communautés se réunissent afin d’assurer le partage, l’alignement, la mutualisation des efforts, bref la montée en compétence de ses membres. Alors que les PO alimentent les squads de fonctionnalités, les chapters identifient et négocient la planification des travaux nécessaires au règlement de la dette technique. L’enjeu est de s’assurer de la pérennité des solutions techniques mises en place.

Les guildes (guilds) sont là pour adresser la mise à l’échelle des communautés de pratique et diffuser les bonnes pratiques au-delà d’une simple tribu. Bien souvent, elles rassemblent les chapters des tribus pour garantir un partage de connaissance plus large. Il n’est alors plus question de dette technique mais bel et bien d’amélioration continue globale, tant au niveau des pratiques que des outils.

Exemple de mise en pratique du modèle Spotify

Les impacts de l’implémentation du modèle

Une transformation en Feature Teams ne s’improvise pas et il est crucial de connaître les impacts du modèle.

Les éléments pour réussir

Le modèle Spotify met en avant l’importance d’adopter une culture produit. Il requiert d’avoir et de maintenir une véritable vision produit à moyen et long terme. Cependant dans les structures françaises, le mode projet est profondément ancré dans nos manières de faire. La maîtrise du cycle de vie du produit fait émerger de nouveaux rôles encore incompris comme celui, stratégique, du Product Manager.

Cela facilite un nécessaire rapprochement entre les métiers et l’IT. L’idéal étant de l’embarquer au sein même des squads et des tribus, pour pouvoir à terme mettre fin au mode client / fournisseur qui est souvent de mise.

Afin de sortir du mode projet, la gestion du budget doit également être reconsidérée. Il s’agit de passer à un mode capacitaire. Cela n’est pas l’option la plus naturelle et signifie la fin des allocations de budget par projet / programme qui s’appuient sur des estimations le plus souvent discutables. Pourquoi ? Une équipe qui a l’habitude de travailler ensemble est plus efficace. C’est la raison pour laquelle la stabilité des équipes est un autre pré-requis du modèle. Cela permet de capitaliser sur le fonctionnement d’équipes en place sur de longues périodes de temps au travers de l’amélioration continue. De ce point de vue, le mode projet où les ressources sont réallouées en cours ou à la fin du projet est un anti-pattern.

Cela revient donc à fixer le budget pour faire fonctionner une structure stable et à rendre flexible le périmètre. La priorisation par la valeur est d’ailleurs une approche extrêmement populaire chez les agilistes. Il faut par contre être en mesure d’alimenter toutes ses équipes en continu. La structure y gagne sur sa visibilité à moyen terme, le pilotage, etc. Ce qui facilite la gestion du budget ! La boucle est bouclée.

La colocalisation est un parti pris fort. Comme écrit plus haut, il faut être en mesure de proposer un tel environnement. Cela peut être coûteux pour des structures qui ont fait, à un moment de leur histoire, le choix de la décentralisation. La colocalisation est la voie de la simplicité : proches les unes des autres, les équipes communiquent mieux car l’effort à consentir est moindre. Les personnes se connaissent, se mettent dans une logique collaborative, le travail quotidien s’en trouve facilité. Ne pas respecter ce principe fondamental revient à s’exposer à un risque important de ne pas atteindre ses objectifs. Cela peut même être contre-productif !

Le problème est récurrent dans les grandes entreprises aujourd’hui. Il n’y a pas si longtemps, le recours à l’off-shoring était « tendance ». Bon nombre d’entreprises en reviennent, déçues à juste titre d’une approche pas si économique et qui, bien souvent, ne fonctionne pas. Mais même sans parler d’off-shore, réorganiser les plateaux pour casser les silos implique de la logistique, des déménagements et même de prendre en compte l’impact social. En effet, séparer des groupes de personnes établis n’est pas simple ! Il faudra alors prendre en compte et convaincre les instances sociales. L’accompagnement au changement doit également jouer pleinement son rôle pour faire face à la naturelle résistance au changement.

Le modèle met également en avant une très grande autonomie des équipes. Une des idées directrices est de permettre aux équipes de disposer de toutes les compétences et moyens nécessaires pour remplir leur mission, à savoir développer une fonctionnalité de bout en bout. Ainsi, les équipes ne sont pas dépendantes d’intervenants extérieurs que ce soit une autre équipe ou un expert technique. Les implications sont nombreuses. L’équipe ne doit plus se retrouver dans l’attente de la fin d’un travail externe car incapable de le mener elle-même. Cela nécessite alors de construire des équipes pluridisciplinaires.

La polyvalence des équipiers est également une des composantes qui fait que ce type de transformation a des conséquences culturelles. Il faut en effet accepter de faire confiance aux équipiers dans leur capacité à assurer leur montée en compétence. Cela n’est pas toujours évident dans des environnements « classiques » où il n’y a pas de culture d’ingénierie du développement informatique. Pourtant en 2015, il est de plus en plus aisé de trouver des ingénieurs en développement curieux et avec l’envie de sans cesse progresser. Cela se fait par le biais des communautés de pratique, mais également dans le partage quotidien au sein d’une équipe en étant ouvert au binomage (pair-programming). Enfin, le recours à la formation continue est fortement conseillé.

De la même manière qu’il faut être en mesure d’avoir un environnement logistique propice, le modèle requiert un environnement technique exigeant. L’utilisation de bonnes pratiques d’ingénierie est inévitable pour garantir le succès du modèle.

En effet, il peut être complexe de faire travailler plusieurs équipes sur un même produit, en mettant en place des livraisons très fréquentes dans le but de réduire encore et toujours la boucle de feedback avec nos utilisateurs. Mettre en place des trains de release, du feature branching, du feature toggle, de l’infra as code et automatiser toute sorte de tests pour pouvoir découpler les livraisons sont autant de challenges techniques. Réduire la distance entre les Devs et les Ops, faire en sorte que la mise en production soit un non-évènement en sont d’autres. La mise en place de ses bonnes pratiques constituent un pré-requis à la mise en place des Feature Teams et doit être prise en compte dans la planification de la transformation.

A quelles difficultés se préparer

Chaque modèle a ses faiblesses, Feature Team ne déroge pas à cette règle. Abandonner un modèle d’équipes composants peut revenir à rendre inmaintenable les couches applicatives et s’exposer à la perte d’homogénéité et de maîtrise du SI. L’alignement n’est pas inné sur ces points. Il est important de mettre en place un cérémonial qui permette de répondre au besoin d’échanger et de capitaliser sur les manières de faire, mais aussi de répartir les efforts à fournir pour combattre la dette technique. Les communautés de pratique ont cette mission et constituent en quelque sorte la garantie de pérennité de nos solutions logicielles.

Un autre impact important concerne le changement culturel des cellules d’architectures face à ces communautés de pratique. Par essence, une communauté de pratique favorise les architectures émergentes et collaboratives. Le modèle est donc en rupture face au côté « tour d’ivoire » d’une cellule d’architecture classique. Attention, nous ne sommes pas en train de dire que les architectes n’ont pas de place dans le modèle. Par contre, ils devront prendre une place importante au sein des communautés.

Par ailleurs, il faut être particulièrement pédagogue vis-à-vis du management. Pour certains d’entre eux, manager signifie avoir la main sur la destinée d’un groupe de gens. Fidèle à la mouvance agile, le modèle Spotify promeut la fin du Command and Control et préconise le Test and Learn, donc le droit à l’erreur. La source d’inspiration est plus à chercher du côté du servant leadership. Le manager doit se rendre disponible vis-à-vis de ses équipiers pour que d’autres valeurs prennent la place : confiance, transparence et autonomie. Ainsi, la motivation intrinsèque des équipes leur permettra de donner leur plein potentiel. Les concepts et outils du Management 3.0 constituent un bon point de départ

L’impact sur la dimension RH d’une telle transformation ne doit pas non plus être sous-estimé. L’adoption d’une approche produit plutôt qu’une approche projet légitime la mise en avant de nouveaux postes, parfois au détriment d’autres. Cela implique donc un soin particulier et un embarquement des services idoines pour la gestion des plans de carrière et des reconversions nécessaires. Des mutations internes sont à prévoir, il faut alors assurer une forme de « service après-vente » auprès de certains managers. Dans des sociétés où l’importance d’un manager peut se juger à l’aune du nombre de personnes qui doivent lui rendre des comptes, promouvoir ce genre de modèles est contre-intuitif.

Enfin, un dernier impact à bien prendre en compte est celui sur les achats. Le modèle Feature Team peut être implémenté de bien des manières et notamment pour des sociétés qui ont recours à la sous-traitance. Il faut alors envisager une forme d’engagement différent, et peut-être même sacrifier les forfaits qui restent appréciés. Changer de mode de contractualisation préférentiel n’est pas anodin, et avoir recours à des formes de contrats agiles restent assez marginal. Il faut pourtant privilégier cette hypothèse si un sous-ensemble d’équipes n’est pas interne.

Comment se transformer ?

Vous l’avez probablement compris, une telle transformation ne s’improvise pas. L’ensemble de ses impacts est important, mais ne vous y trompez pas : les bénéfices sont réels !

La publication en 2012 de Kniberg et les vidéos sur la culture Spotify ne disent pas comment faire. Elles décrivent le modèle dans ses grandes lignes, donnent de nombreux indices et des principes directeurs mais n’expliquent pas sa mise en musique, ce qui ouvre la porte à de nombreuses interprétations. Tenter de plaquer le modèle sans réflexion, de le transposer dans votre environnement sans un bagage de compétences et d’expériences y ressemblant est une garantie d’échec lourd de conséquences.

De manière plus globale, il existe relativement peu de littérature et de retour d’expérience sur sa mise en place dans d’autres environnements.

Dès lors, comment faire ? Par où commencer ? Mon entreprise est-elle prête pour le modèle Spotify ? Quelques recommandations d’usage pour conclure. Répondez d’abord à ces questions :

• Pourquoi passer en Feature Teams ? Méfiez-vous du buzz ! Vous avez forcément des sources d’insatisfaction et des objectifs à atteindre. Une fois formalisés, assurez-vous que le modèle Spotify y répond. D’autres solutions sont parfois mieux adaptées.
• Dans mon environnement, qu’est-ce qu’un produit ? Cette question anodine, facile pour un éditeur, peut s’avérer complexe et source de nombreuses discussions dans une grande entreprise. La réponse vous permettra de démarrer la réflexion sur l’axe de découpe organisationnel. Attention, cette décision est structurante et il est souvent difficile de pivoter.
• Où en êtes-vous dans vos bonnes pratiques de développement et de mise en production ? Un état des lieux vous permettra d’identifier cette « dette » et quantifier l’effort à fournir pour être éligible aux Feature Teams. Le planning de la transformation en découlera.

Dans tous les cas, il faut envisager la transformation progressivement. Commencez petit, mais sans demi-mesure. La démarche en 8 étapes de John Kotter pour transformer une entreprise constitue une bonne source d’inspiration. Mais ça, c’est une autre histoire…