Soyons en contact

 

Une Product Team est une long-lived team, et non pas une équipe éphémère, assemblée à une date définie et démantelée à une autre date définie

This page is still under construction

14-12-2015 - 13:3205-01-2017 - 16:41

Une Product Team n'est pas une équipe éphémère, assemblée le temps d'un projet. Elle existera tant que le(s) produit(s) dont elle s'occupe est(sont) supportés(s) par l'entreprise, et elle s'en occupera sur un mode end-to-end en traversant toute la Value Stream (châine de valeur) qui prend le(s)dit(s) produit(s) en charge. Pour autant que je puisse en juger, les entreprises qui déclarent mettre en place des Product Teams n'ont pas vraiment toutes saisi la portée de cette définition et continuent à être engluées dans des mécanismes de fonctionnement, de supervision et décision, et budgétaires inadaptés qui les empêchent de se mouvoir à l'heure du digital.

L'équipe est assemblée le jour où un nouveau besoin, ou problème, est ressenti que l'entreprise souhaite étudier et pour lequel elle souhaite, le cas échéant, apporter une réponse sur le marché. Le terme “produit“, en l'occurrence, couvre donc la notion de produit ou service.

Tant que le produit (ou service, je ne ferai plus la distinction) dont une Product Team a la charge doit être maintenu et supporté, la Product Team existe. Elle existe depuis le moment où le produit est ressenti, elle construit le produit, elle le lance sur le marché, elle en assure la maintenance, tant corrective que perfective, et elle le supporte, et, cela, d'année en année. Le jour où le produit est décommissionné, c'est encore cette même équipe qui le décommissionne, la plupart du temps en collaboration avec d'autres équipes qui sont en charge de produits et/ou services de substitution et en bonne collaboration avec les Opérations et l'Architecture : le Catalogue de services et produits est adapté.

Pour pouvoir traverser l'ensemble de la chaîne de valeur (VS), l'équipe doit pouvoir réunir toutes les compétences nécessaires : définition du besoin, définition de la solution, construction de la solution, lancement de la solution, opérer la solution, la maintenir et la supporter.

C'est là où les Product Teams sont confrontées à la réalité du contexte dans lequel elles se développent, mais encore à la théorie de l'Agilité. Prenons d'ailleurs ce second biais car il m'apparaît être le plus simple à résoudre.

Product Team et Agilité

En général la mise au point de Product Teams entre en conflit avec les préceptes de l'agilité sur essentuellement deux terrains :

  • La nécessité de garder de petites équipes (mais alors comment rassembler tant de compétences différentes au sein de si petites équipes?)
  • L'opposition avec les Component Teams (un sujet qui fâche, tenants des méthodes agiles ou plus traditionnelles)

Pour ce qui est du premier volet, la taille des équipes, il est de bon ton de savoir qu'une Product Team est en fait un noyau. C'est un peu comme au football où un club possède un noyeau de joueurs même si ne jouent simultanément que 11 joueurs : tout le monde n'est pas sur le terrain en même temps, ni avec la même implication. Par ailleurs, car les analogies ne peuvent souvent pas être menées jusqu'au bout, il n'est pas interdit de s'adjoindre les services, compétences et expertises au moment où elles sont nécessaires, avec un peu de délai néanmoins. Enfin, une Product Team peut très bien représenter plusieurs équipes agiles.

C'est ce que nous avons essayé de représenter avec SAM de la manière suivante :

Une Product Team en SAM

Dans le modèle SAM on rassemble les équipes DevOps au sein d'équipes "produit", si nécessaire. On essaye néanmoins de garder les équipes produit à une taille raisonnable en n'acceptant pas davantage que 7 équipes agiles (DevOps). Souvent, on remarque que la taille d'une équipe "produit" n'est pas supérieure à une trentaine de personnes, encore faut-il que je reconnaisse que ce nombre est basé sur les seules observations des auteurs de SAM.

Vient ensuite la vieille opposition entre Product Team et Component Team, plus exactement entre Feature Team et Component Team. Je ne vais pas démonter le m?canisme encore une fois : que le lecteur veuille bien se rendre sur le billet Feature Teams et Component Teams pour y voir déroulé mon point de vue. Selon moi, c'est un faux débat qui ne devrait même pas avoir sa place dans la question : il ne s'agit pas de traquer les Component Teams au bénéfice des Feature Teams, il s'agit plutôt de trouver le moyen de les faire collaborer sans créer de forte dépendance, en permettant ultimement qu'elles soient indépendantes les unes des autres.

CE BILLET N'EST PAS FINI, CHER LECTEUR. J'EN SUIS DÉSOLÉ.

Top
Le Blog Apocryphe utilise des cookies pour sauver vos préférences et RIEN d'autre. Je vous demande de bien vouloir accepter les cookies qui sont positionnés sur mon blog et je vous promets en retour de ne RIEN laisser transparaître de votre parcours de visite, dont d'ailleurs vous me faites l'honneur. Au cas où néanmoins vous n'accepteriez pas d'utiliser les cookies, vous aurez probablement une navigation LÉGÈREMENT dégradée sur le Blog Apocryphe. Bonne visite!X