Il n’est pas toujours possible d’intégrer dans chaque squad l’ensemble des compétences nécessaires pour lui donner une autonomie totale. Dans certaines organisations, pour des raisons pratiques ou budgétaires, des compétences sont maintenues en transverse, que ce soit au niveau de la tribu ou au niveau de l’organisation Produit elle-même : Product Designers, Data Analysts, testeurs, Data Scientists, développeurs mobiles…
C'est ce que nous appelons des organisations hybrides.
Nous rencontrons souvent lors de nos missions des organisations hybrides présentant tout ou partie des caractéristiques, adhérences et dépendances présentées ci-dessous :
Cette situation crée automatiquement une forte dépendance entre les squads et ces entités transverses, allongeant le time to market dès que toutes les squads Produits sollicitent en même temps la même équipe transverse. Les leviers présentés plus haut restent bien sûr applicables pour la plupart, et vous permettront de résoudre une partie des dépendances que vous allez rencontrer ; néanmoins nous avons des recommandations spécifiques à ces situations, en fonction de la typologie de votre organisation.
1. Gestion des dépendances avec une équipe back-end transverse
Il est fréquent - même s’il s’agit selon nous d’un anti-pattern - de voir des équipes back-end indépendantes ayant comme mission de servir des squads Produit très orientées “front-end”.
L’équipe back-end devra créer des API servant plusieurs squads et ne pourra s’adapter pleinement aux demandes de chacune et au rythme de développement nécessaire côté front-end. Ne sachant pas quand la fonctionnalité servie par le back-end sera prête, les squads développent souvent une certaine frustration de dépendre d’autres équipes pour accomplir leurs objectifs, tandis que les équipes back-end se retrouvent à jongler entre des priorités externes qu’elles ne maîtrisent pas ; ce type d’organisation peut générer à terme un turnover important.
Tout n’est pas perdu, cependant. Au-delà des solutions déjà mises en avant plus haut, vous pouvez essayer différents palliatifs pour remédier à ces problèmes.
Palliatif 1 : Intégrer ponctuellement des développeurs back-end aux squads
Dans le cadre de la coexistence de 2 back-ends, situation fréquemment rencontrée lors de la refonte d’un back-end vieillissant (legacy), nous préconisons, d’une part, d’intégrer les ressources dédiées au nouveau back-end dans chacune des squads afin d’amorcer la transition vers une organisation plus verticale ; et d’autre part, de conserver une équipe back-end dédiée assurant la maintenance des API existantes et la disponibilité des données le temps que la transition soit complète.
Les squads vont construire petit à petit un nouveau back-end, chacune créant ses nouveaux services sur une architecture neuve, tout en continuant de dépendre du legacy pour tous les services pas encore redéveloppés. Mais en intégrant les développeurs back au sein des squads, votre organisation gagnera fortement en vélocité pour tous les développements n’impactant pas le legacy.
Palliatif 2 : Définir des contrats d’interface entre les équipes back-end et front-end
Une API n’étant autre qu’une interface qui permet à deux systèmes complètement indépendants de se parler de façon automatisée, les contrats d’interface permettent à des équipes travaillant en mode “fournisseur-client” (ce qui est le cas d’une équipe back-end vis-à-vis de squads Produit) de paralléliser les développements. Ainsi une équipe front-end travaillant sur une fonctionnalité va se mettre d’accord et définir conjointement avec l’équipe back-end les données dont elle aura besoin, la façon dont elle les requêtera et le format sous lequel elle les recevra.
Ce contrat d’interface permet à l’équipe front-end de développer la partie émergée de l’iceberg en “bouchonnant” les données reçues par le back-end, puis converger le plus rapidement possible vers un livrable commun.
Palliatif 3 : Mettre en place une architecture de microservices
Si vous intégrez des ressources back-end au sein des squads comme recommandé précédemment, il serait logique de mettre également en place une architecture en microservices. Cette architecture permet de découper le back-end “monolithique” en différents petits services indépendants qui servent des domaines fonctionnels différents. Ainsi, chaque Feature Team comme son nom l’indique maîtrisera de bout en bout son domaine fonctionnel, sera chargée de développer ses propres microservices et de les rendre interopérables avec les autres squads.
Notez qu’avec une architecture de ce type, vous créerez de facto de nouvelles adhérences entre chacune des Feature Teams (puisque chacune sera responsable de ses propres services) ; mais ces adhérences sont plus faciles à traiter que la relation client-fournisseur entre une équipe back-end unique et de nombreuses équipes front-end.
2. Gestion des dépendances avec une équipe Ops
Tout comme le dispositif décrit auparavant, il est fréquent de voir l’équipe “Ops” travailler indépendamment des squads et ne pas y être intégrée directement.
Cette dépendance concerne en grande partie la mise en place des outils de développement mais surtout la mise en production de nouvelles fonctionnalités. Ainsi, après avoir développé un ensemble de fonctionnalités, les squads doivent envoyer leur livrable afin qu’il soit déployé sur les différents environnements appropriés par une équipe “Ops” qui reçoit les demandes de mise en production des différentes équipes et qui les priorise. Autant la dépendance précédente avec les équipes back-end peut facilement être contournée, autant la dépendance avec les équipes Ops peut mener à des situations de bloquage.
En plus des effets précédemment cités, que sont l’allongement du time to market, la baisse de prédictibilité et la lassitude des membres des squads, s’ajoute la mise en danger des livraisons. Bien des équipes travaillant dans un tel modèle ont vu des fonctionnalités nécessiter 3 à 6 mois avant de partir en production, devenant caduques en perdant toute leur valeur pour l’utilisateur ; voire ne jamais partir en production, le lot de fonctionnalités revenant en arrière pour la correction d’une anomalie ou l’intégration d’une nouvelle contrainte d’exploitation.
Nous ne prétendons pas être des experts techniques ni des experts du DevOps, c’est pour cela que nous nous contenterons de récapituler des solutions Ops et DevOps rencontrées lors de nos différentes interventions.
Solution 1 :
Mettre en place un management visuel (ex : kanban) représentant le pipeline des livraisons et les règles de priorisation de ces mises en production.
Solution 2 :
Intégrer les exigences de l’équipe “Ops” dans le travail quotidien des squads en faisant des user stories “Ops ready”. Les équipes intègrent les contraintes imposées par les équipes Ops et Sécurité (machines disponibles, routage correct, firewall bien configuré, etc.) à la Definition of Ready des users stories.
Solution 3 :
Proposer aux squads et notamment aux développeurs qui les composent des usines logicielles as a Service, par exemple : aider les équipes de développement à mettre en place un outil d’intégration continue tel que Jenkins.
Nous restons néanmoins convaincus que la meilleure solution pour promouvoir l’agilité et faciliter le processus de Product Development reste la mise en place d’une vraie culture DevOps au sein de l’organisation, en intégrant un Ops directement dans chacune des squads afin de rendre les équipes réellement indépendantes de la conception à la mise en production.
3. Gestion des dépendances avec une équipe composant indépendante (souvent mobile)
Nous avons constaté dans de nombreuses organisations la présence d’une équipe mobile indépendante des squads. En effet, les spécificités techniques des outils et plateformes de développement mobile poussent souvent à regrouper les développeurs disposant de ces compétences dans la même équipe. De même, les Product Managers et Product Designers mobiles doivent bien maîtriser les guidelines de Google (Android) et Apple (iOS) qui changent très souvent, et connaître les spécificités de la conception de Produits mobiles.
Enfin, la plupart des Produits étant déclinés à la fois sur iOS et sur Android,
il n’est pas toujours pertinent ou possible en terme de coûts d’intégrer à chaque squad un développeur mobile spécialiste de chaque OS.
Les leviers que nous proposons pour gérer cette situation :
Levier 1 : Conserver les équipes mobiles (ou autres composants) et adopter une logique d’équipe “éclaireuse” vis-à-vis des squads
Si vous avez dans votre organisation des équipes orientées fonctionnalités d’un côté et plusieurs équipes composants orientées plateformes (iOS, android, objet connecté...), un bon moyen de traiter les inévitables adhérences entre ces squads consiste à adopter une logique d’équipe “éclaireuse”. Concrètement, les squads verticales développeront leur fonctionnalité en partenariat avec une seule des équipes composants pour commencer, ce qui permettra de structurer le travail de conception, d’aplanir les difficultés et d’obtenir rapidement des retours utilisateurs. Une fois la fonctionnalité déployée sur l’un des supports, les autres équipes composants déclineront la fonctionnalité sur leur propre plateforme, en bénéficiant directement du travail déjà réalisé.
Cette approche est par exemple celle adoptée chez Evernote, un Produit qui est conçu dès le départ pour fonctionner sur un maximum de plateformes différentes. Ce rôle d’équipe “éclaireuse” peut bien entendu tourner, en fonction du contexte et des fonctionnalités.
Levier 2 : Dissoudre l’équipe mobile une fois le périmètre fonctionnel de l’application équivalent à la version web
Le développement des applications mobiles intervient souvent après le lancement d’un Produit web à succès, une fois le Product Market Fit atteint et un usage récurrent créé.
Dans ce cas, les entreprises créent en général une équipe mobile dédiée, même si elles sont par ailleurs organisées verticalement.
Sauf si l’application propose un jeu de fonctionnalités complètement différent de la version web, cette équipe doit “rattraper” dans la version mobile le périmètre fonctionnel existant sur le site. Dans ce cadre là, avoir une équipe dédiée à ce sujet peut permettre d’avancer plus vite en minimisant les adhérences (le Product Owner de cette squad mobile bénéficiant du travail de conception déjà effectué au sein des autres squads web).
Une fois la parité atteinte entre les fonctionnalités de l’application mobile et celles du web, on peut envisager de dissoudre la squad mobile et répartir ses membres dans diverses squads verticales, où ils pourront continuer de développer les fonctionnalités existantes et créer de nouvelles fonctionnalités.
4. Présence d’équipes regroupant des compétences transverses au sein de la tribu : Product Designers, Data Scientists, testeurs, etc.
Pour les mêmes raisons exposées ci-dessus à propos des équipes mobiles, il n’est pas toujours possible de disséminer dans chaque squad l’ensemble des compétences nécessaires : faute de talents disponibles, le Product Design, la Data Science ou encore la QA sont parfois regroupés au niveau de la tribu voire de l’organisation Produit, et travaillent pour le compte de l’ensemble des squads. Bien que parfois inévitable, ce schéma génère de nombreuses adhérences souvent extrêmement préjudiciables à l’efficience des squads. Nous préconisons les solutions suivantes afin de limiter les frictions et les goulots d’étranglement :
Solution 1 : “Agiliser” les équipes transverses
Etant donné que ces équipes travaillent en forte proximité avec des squads fonctionnant souvent en mode sprint, nous préconisons qu’elles s’organisent selon le même rythme afin de pouvoir :
- se synchroniser sur les moments forts de la vie des squads
- ménager du temps pour l’itération
- promouvoir une logique MVP en travaillant sur des sujets livrables dans un sprint plutôt que des projets de grande taille dont on ne voit pas le bout
- éviter l’effet tunnel et faire en sorte que l’équipe transverse ne se concentre pas sur la production de livrables pour une seule squad tout en ignorant les autres
- faire prendre conscience aux squads de la charge de travail au sein des équipes transverses, et que leurs demandes ne constituent qu’une partie du backlog de ces équipes
Nous proposons également de transposer les cérémonies agiles à ces équipes de la sorte :
- Sprint plannings : organiser des sprint plannings en compagnie d’un représentant de chaque squad, le Product Manager par exemple, afin de s’engager sur un objectif et un périmètre de sprint viables et atteignables. Chacune des tâches composant le sprint de l’équipe transverse ne doit pas obligatoirement être chiffré (en fonction de la nature du travail produit par l’équipe, ce n’est pas forcément possible), mais au moins priorisé par rapport au reste des tâches. La présence du CPO peut être nécessaire lors de ce sprint planning afin d’aider à la priorisation commune.
- Daily meetings : les équipes transverses peuvent se présenter aux daily des équipes concernées par leur travail de la veille ou leur travail du jour afin de les tenir au courant des avancements.
- Points de synchronisation : afin de tenir le Product Manager au courant de l’avancement de ses sujets, des points de synchronisation informels peuvent être organisés.
- Démo : une démo par équipe transverse peut être organisée afin de tenir au courant les squads de ce qui a été réalisé. Cette démo permettra de présenter les maquettes ou les résultats d’une recherche utilisateurs par l’équipe de Product Design, présenter un nouvel outil de test automatisé par l’équipe QA, ou résumer une analyse réalisée par l’équipe de Data Science.
Solution 2 : Rendre les squads de plus en plus autonomes
Cette autonomisation des squads passe d’abord par la formation des Product Managers aux compétences transverses nécessaires pour gérer un Produit de A à Z. Ainsi un Product Manager peut se former au Product Design, aux analytics, voire aux outils et processus de qualité (voir le chapitre 5 “Quels profils Produit recruter lorsque mon organisation passe à l'échelle ?”).
Cette autonomie des squads passe également par le choix d’outils qui facilitent leur travail : la mise en place d’un design kit tel que décrit précédemment ou des outils d’analytics tels que Segment permettent de simplifier et de standardiser la collecte et l’analyse des données utilisateur au sein des squads, en minimisant la dépendance vis à vis des équipes transverses qui peuvent se concentrer sur du travail de fond ou de long terme.
Conclusion
Les adhérences et dépendances sont inhérentes à tout modèle d’organisation, que ce soit entre squads de type Feature Teams ou entre des équipes transverses dans des organisations hybrides.
Pour nous, l’essentiel reste de trouver les leviers à mettre en place afin de limiter les effets des dépendances en terme d’allongement du time to market, de baisse de la prédictibilité et de démotivation des équipes. Néanmoins, nous restons persuadés que les organisations verticales avec des équipes pluri-disciplinaires et autonomes sont non seulement plus compatibles avec la vision que nous portons sur le Product Management, mais conduisent également à de meilleurs arbitrages et à une gestion des relations entre équipes plus aisée : les adhérences sont certes multipliées, mais les dépendances minimisées, et ce sont bien ces dernières qui posent le plus de problème.
Nous pensons qu’il est important pour une organisation de se rapprocher progressivement de ce modèle en investissant dans un maximum de profils pluridisciplinaires, en recrutant des Product Managers et des développeurs full-stack, en les formant constamment pour maintenir ou créer cette pluri-disciplinarité et en insistant sur la nécessité d’un état d’esprit ouvert au changement et à l'itération organisationnelle. Plus vous valoriserez la pluri-disciplinarité, et plus la gestion des dépendances sera aisée.
Ressources - pour aller plus loin :
How to Organize a Team that Designs End-to-End Experiences : Katie Dill, Head of Experience Design chez Airbnb, explique comment maintenir une expérience utilisateur cohérente de bout en bout avec une organisation Feature Teams.
PI Planning - Scaled Agile Framework : le site officiel de SAFe détaille les prérequis et le fonctionnement précis d’un PI Planning.
