Tel que précisé dans notre article sur 4 grands modèles d'organisation Produit, il n’y a pas de découpage idéal. Pour autant, chaque type de découpage a ses points forts et ses points faibles ; qui peuvent être plus ou moins intéressants en fonction du contexte. On a essayé de les formaliser afin de vous aider à choisir votre modèle d'organisation Produit en temps voulu.
Afin de profiter un maximum de cet article, nous vous recommandons, si ce n'est pas déjà fait, de commencer par lire l'article "4 grands modèles d'organisation Produit" qui aborde les modèles organisationnels majeurs d'aujourd'hui.
Nous avons fait l’exercice d’évaluer ces différents modèles selon les critères qui nous semblent important pour une organisation Produit. Nous nous sommes appuyés sur les expériences pratiques des Thiguys et des CPOs interviewés.
Choisir votre modèle d'organisation Produit dépend donc majoritairement de ces 8 axes :
- Responsabilisation des squads
- Orientation utilisateur
- Spécialisation des compétences
- Autonomie des équipes et gestion des dépendances
- Mutualisation et réutilisation du code
- Capacité à passer l’organisation à l’échelle
- Amélioration continue du Produit
- Coût
Responsabilisation des squads
C’est une évidence, mais toute équipe et tout individu est plus efficace quand son travail a un but, du sens, un impact concret sur le Produit final.
Dans une logique de Component Team, les équipes gèrent souvent une petite partie du Produit, guidée par un découpage technique. Par exemple, les équipes front-end définissent des interfaces, mais doivent généralement composer avec des API créées par d’autres équipes (back-end).
Comme les responsabilités sont diluées (la qualité d’une fonctionnalité développée dépend de la qualité du travail d’au moins 3 ou 4 équipes différentes), les équipes organisées dans ce modèle peuvent avoir tendance à rejeter la responsabilité sur d’autres. Les équipes back se plaindront que les fonctionnalités front ont été mal pensées et mal codées ; les développeurs front se plaindront d’avoir dû composer avec un modèle de données mal conçu, et ainsi de suite. Pour éviter ces problèmes, il faut promouvoir en interne la co-construction entre équipes et lutter contre les relations client-fournisseur. Ces dernières ont tendance à resurgir à intervalles réguliers lorsqu’on travaille en Component Teams.
Sur ce point, le modèle Component Teams serait selon nous à éviter lorsque vous aurez à choisir votre organisation Produit. En effet, une seule Component Team peut dans ce modèle paralyser les autres.
Les modèles verticaux (Feature Teams, Impact Teams...) sont plutôt responsabilisants pour les squads. Elles doivent définir leurs propres objectifs, leur vision, leur backlog, toujours dans une logique d’apporter de la valeur à l’utilisateur. La plupart des décisions importantes se prennent au sein des équipes “qui font”, même si elles agissent toujours dans un cadre stratégique donné.
Le modèle SAFe représente selon nous une approche intermédiaire en matière de responsabilisation. Les squads sont normalement autonomes et responsabilisées au niveau du Program Increment. Cependant, en fonction de l’implémentation du modèle et du nombre de couches hiérarchiques au-dessus des squads, il peut arriver qu’elles se retrouvent coupées à la fois des utilisateurs et de la stratégie Produit.
Orientation utilisateur
Par nature, les équipes verticales (qu’on parle de fonctionnalités ou d’objectifs) s'orientent vers l’utilisateur ; puisque leur mode de découpage est pensé en fonction de problématiques utilisateur. Le modèle d’équipes organisées par objectif présente cet avantage par rapport à la Feature Team de ne pas pérenniser telle ou telle fonctionnalité. Une fois une Feature Team créée, la squad peut avoir tendance à continuer à développer coûte que coûte la fonctionnalité en question même si elle cesse à terme de répondre aux objectifs du Produit, pour justifier sa propre existence.
Les équipes verticales intègrent également toutes les compétences nécessaires pour mener des activités de recherche utilisateur sur leur périmètre (voir chapitre 6 “Comment industrialiser le Product Discovery” de notre livre sur les organisations orientées Produit).
A l’inverse, les Component Teams sont peu orientées utilisateur par nature, car elles reflètent davantage une organisation technique. Par ailleurs, la recherche utilisateur n’est pas portée par chacune des équipe, mais souvent effectuée à un autre niveau de l’organisation au sein d’équipes dédiées (les équipes back-end par exemple étant complètement coupées du contact avec les utilisateurs).
Spécialisation des compétences
Ici, les différents modèles sont en opposition frontale. Les Component Teams sont un environnement favorisant les spécialistes, qui souhaitent approfondir une expertise particulière ; elles sont donc particulièrement appropriées à des contextes techniques complexes ou faisant appel à des compétences très spécifiques (technologie ou langage de programmation particulier), qu’il vaut mieux regrouper au sein de la même équipe. Par exemple, une équipe dédiée à la Data Science.
A l’inverse, les Feature Teams et les modèles d’agile à l’échelle verticaux tels que SAFe privilégient les profils “en T” ; excellant dans une compétence mais ayant une capacité à étendre ponctuellement leur champ d’action à d’autres domaines. Le modèle du développeur “full stack” capable d’assurer du développement front, back, voire du DevOps se révèle complètement adapté à ce genre de squad ; on a vu que la taille d’équipe cible est assez réduite. La squad verticale ne peut donc pas accumuler les profils de spécialiste. Par ailleurs, ce type de squad a comme vertu non négligeable de réduire considérablement les risques de grippage liés à l’absence d’un ou plusieurs coéquipiers.
Autonomie des équipes et gestion des dépendances
Les Component Teams sont rarement autonomes sur leur domaine. Elles fournissent en général des briques qui servent à d’autres équipes ; pour compléter tout ou partie d’un Produit ou parcours utilisateur. Elles s’appuient aussi sur des éléments développés ailleurs dans l’organisation. On retrouve une logique de client-fournisseur où chaque squad peut devenir un goulot d’étranglement pour l’ensemble du processus. Par exemple, si les développeurs back-end ont fini de créer toutes les API mais que l’équipe front-end a du retard, toute la fonctionnalité s’en trouve bloquée. Elles sont également tributaires de projets et d’initiatives imposés par d’autres entités dans l’organisation, sans réel contrôle sur leur backlog. La synchronisation des backlogs et chaînes de décision associées rendent chronophage et fastidieuse la gestion des dépendances en Component Teams. La qualité des arbitrages effectués dans ce modèle est rarement optimale, générant des frustrations.
A l’inverse, la Feature Team et les modèles verticaux en général plaident pour une autonomie complète des squads. Cette orientation permet de :
- dégager fréquemment de la valeur pour l’utilisateur
- valoriser la créativité et l’expertise de chaque équipe
- rapprocher la prise de décision des équipes opérationnelles.
Chaque équipe peut théoriquement avancer à son rythme, sans attendre des développements effectués par d’autres. Bien sûr, cette autonomie a des limites, et certaines adhérences sont inévitables. Les équipes verticales doivent s’aligner entre elles de manière fréquente. L'objectif est d'éviter de développer des fonctionnalités redondantes, ou de prendre des options contradictoires. C’est d’autant plus le cas pour les squads organisées par objectifs, qui peuvent toutes impacter la même fonctionnalité du Produit.
Cette synchronisation entre squads, et la gestion additionnelle des projets transverses impactant toutes les équipes, est consommatrice en temps et en énergie. Pour autant, nous avons vu plus haut qu’il est possible de simplifier ce processus grâce aux tribus, chapters et guilds. SAFe fait également une place très importante aux activités de planification, qui permettent d’anticiper les dépendances et d’aligner les squads.
Mutualisation et réutilisation du code
Les défenseurs du modèle Component Teams arguent que la réutilisation du code constitue l’un de ses avantages. Par nature, chaque équipe component a un périmètre clairement délimité. Elle a tendance à réutiliser et optimiser ses propres composants, qu’elle fait évoluer selon les besoins des autres équipes.
Les Feature Teams vont avoir plus de latitude pour développer leurs propres solutions. Ainsi, le modèle peut générer donc plus de travail en double et moins de mutualisation. Cependant, les guilds et chapters peuvent tout à fait promouvoir la réutilisation de composants ou identifier du refactoring de code à prioriser ensuite par chaque Product Owner. Le code source du Produit appartenant à tous, il est de la responsabilité de chaque équipe d’y contribuer correctement (en identifiant les opportunités de réutilisation de l’existant).
Cet argument souvent entendu ne devrait donc, selon nous, pas être considéré lorsque vous aurez à choisir votre organisation Produit.
Capacité à passer l’organisation à l’échelle
Les organisations qui adoptent le modèle Feature Team ont parfois du mal à gérer le passage à l’échelle, mais aussi les changements de priorité. Si une Feature Team est provisoirement débordée, faut-il en créer une autre ? Dans ce cas, que contiendra son backlog ? Faut-il couper la fonctionnalité en deux ? Et si finalement la fonctionnalité sur laquelle travaillait l’équipe se révèle moins pertinente que prévu, que faire ?
Le modèle Feature Team fonctionne bien pour des problématiques sur lesquelles l’entreprise souhaite investir de manière pérenne. Néanmoins, il n’est pas forcément si facile à piloter en cas de brusque croissance ou de changements rapides de priorité.
Quand vous choisirez votre modèle d'organisation Produit, il faudra tenir compte de la nature et de l'impact de votre activité sur ce critère.
Le modèle Component Team pose moins de problèmes, car son périmètre est par nature durable ; un composant ne disparaît pas du jour au lendemain. Par ailleurs, l’équipe component, par nature non pluridisciplinaire et donc moins collaborative qu’une équipe verticale, souffre peut-être moins de la contrainte de taille ; dans une certaine mesure, on peut juste ponctuellement ajouter des développeurs à l’équipe. Si celle-ci devient vraiment trop grosse, la question de diviser l’équipe component en deux peut se poser.
Dans le modèle SAFe, les squads étant (en grande partie) indifférenciées, le passage à l’échelle est normalement plus simple. On peut ajouter des collaborateurs à une équipe donnée jusqu’à atteindre la taille maximale d’une pizza team ; après quoi il suffit de créer une autre équipe. Plus l’entreprise aura de squads, plus la capacité à délivrer augmente automatiquement ; tout en maintenant (si le framework s'applique bien) la vélocité de chaque squad.
Amélioration continue du Produit
L’amélioration continue est l’une des activités clés d’une équipe Produit. Il ne suffit pas d’enchaîner le développement et la mise en production de nouvelles fonctionnalités. Il vaut parfois mieux améliorer l’existant que de commencer quelque chose de nouveau.
Le modèle de découpage vertical est clairement le plus adapté si l’équipe Produit souhaite favoriser l’amélioration continue. Chaque squad étant autonome sur un périmètre et responsable de son backlog, le Product Owner ou Product Manager est libre de prioriser avec son équipe l’amélioration de l’existant ou la création de nouvelles fonctionnalités selon des critères de valeur. Le système limite ainsi la tentation de ne faire que des nouveautés (au retour sur investissement souvent très incertain) aux dépens d’améliorations rapides apportant beaucoup de valeur qui ne sont jamais priorisées en mode projet.
Dans le modèle component, chaque équipe composant porte indépendamment l’amélioration. Elle doit faire l’objet d’une synchronisation pour éviter que les efforts des uns soient totalement ignorés par les autres. D’après notre expérience, comme les roadmaps de chaque composant sont souvent déjà pleines de besoins urgents identifiés par d’autres équipes, la part d’amélioration continue est en général réduite à la portion congrue (ou au bon vouloir du Product Owner). Enfin, comme ce modèle pousse souvent à un découpage des tâches préalables en mode projet, les petites tâches d’amélioration se voient souvent indéfiniment reportées.
Enfin, les framework comme SAFe comptent sur chaque Product Manager ou Product Owner pour prioriser dans les Program Increments des logiques d’amélioration. Le Product Owner a notamment la capacité à négocier une réduction de sa capacité à développer de nouvelles fonctionnalités pour faire davantage de gestion des incidents, de réduction de dette technique ou d’amélioration de l’existant.
Lorsque vous aurez à choisir votre modèle d'organisation Produit, si l'amélioration continue est un critère important dans votre activité, le modèle component ne devrait donc pas correspondre à votre besoin.
Coût
A priori, aucun modèle n’est par nature plus coûteux qu’un autre. Choisir vôtre modèle d'organisation Produit ne devrait donc pas tenir compte de ce critère à première vue.
Cependant, le passage d’une organisation découpée horizontalement à une organisation verticale peut effectivement entraîner une hausse des coûts, pour peu que l’on veuille intégrer à chaque squad l’ensemble des compétences nécessaires. Par exemple, une organisation avec une équipe web de 20 développeurs et une équipe mobile de 4 développeurs pourrait se transformer en 5 Feature Teams de 5 développeurs chacune (ce qui entraînerait le recrutement d’un développeur supplémentaire).
Le passage à un modèle SAFe peut aussi se faire à effectif constant ; ou nécessiter de muscler les compétences sur la partie Product Management (couche portfolio et programme). C’est d’ailleurs souvent le cas ; l’un des objectifs de ce Framework étant de provoquer une transformation globale au niveau de l’organisation.
C’est l’une des raisons pour lesquelles le modèle hybride peut se révéler adapté dans certains cas, en conservant les compétences rares ou certains applicatifs socle dans leur propre Component Team et en transformant le reste de l’organisation en équipes verticales orientées utilisateur.
Enfin, il faut noter que les pertes de temps et inefficiences potentiellement générées par un modèle de découpage inadapté peuvent constituer des coûts cachés : si un modèle vertical se révèle plus efficace au niveau de la gouvernance (en minimisant les réunions, le time to market) ou de la qualité délivrée (grâce à de meilleures décisions prises sur le terrain), il peut largement justifier le recrutement de quelques compétences supplémentaires par rapport à un modèle horizontal.
Conclusion
Le modèle dit “Spotify” organisé verticalement en Feature Teams est aujourd’hui le favori des pure players. De nombreuses DSI de grandes entreprises l'ont adopté ou expérimentent des modèles d’agilité à l’échelle tels que SAFe ou LeSS. Cependant, aucune de ces solutions ne représente une solution miracle. Pour bien choisir votre modèle d'organisation Produit, il faut avant tout penser à votre contexte et vos besoins.
Pour nous, l’essentiel consiste à trouver un découpage qui donne du sens au travail effectué par les équipes. Il doit aussi limiter les dépendances entre les squads (et donc le temps perdu en réunions) et s’appuie sur des équipes de taille assez réduites (pizza teams).
Ainsi, le modèle Feature Team nous semble par nature plus compatible avec notre vision sur le Product Management. Nous considérons chez Thiga qu’une équipe 100% organisée par Components ne permettra pas d’être aussi efficace à long terme.
Mais le découpage vertical pose également des problématiques pas toujours évidentes à résoudre ; sur la gestion du transverse, l’alignement des équipes, le management des compétences…
La création de modèles hybrides mélangeant des Feature Teams complètement verticales et indépendantes, et quelques Component Teams sur des sujets ciblés peut représenter une voie médiane intéressante, si ce n’est une solution de transition.
Des Component Teams peuvent également se constituer de façon temporaire, par exemple pour faire du rattrapage fonctionnel. Dans le cas du lancement d’une application mobile, une squad dédiée peut développer d’un seul coup toutes les fonctionnalités disponibles sur le web et aujourd’hui portées par des Feature Teams ; une fois que l’application a rattrapé son retard fonctionnel, on peut envisager de démanteler l’équipe pour rapatrier ses compétences dans les diverses squads Produit.
Pour aller plus loin : Télécharger notre livre sur les Organisations Produit
