Team Topologies – Organizing Business and Technology Teams for Fast Flow

Je viens de finir la lecture “Team Topologies” écrit en 2019 par Matthew Skelton et Manuel Pais. Ce livre, que j’ai beaucoup apprécié, est parfois cité sur les thèmes d’agilité à l’échelle, la culture agile dans l’entreprise, etc.. comme un outil indispensable. Cela m’a donné envie de partager avec vous les grandes thématiques de l’ouvrage (sans en dévoiler tous les détails) afin de vous donner envie de le lire.

En effet, ce livre donne des clés de compréhension, des retours de terrain et une proposition de cadre. Tout cela avec un objectif : réinventer la façon dont les entreprises organisent leurs équipes.

D’après les auteurs, il s’agit de voir l’entreprise comme un système vivant qui se transforme et s’adapte à un rythme équilibré entre les besoins du business (délivrer de la valeur plus vite) et les besoins de créer une culture d’équipe en interne (créer de la confiance dans la durée).

Principes

Une première partie du livre détaille certains principes généraux :

• La Loi de Conway : la façon dont les équipes sont organisées et interagissent entre elles détermine la façon dont les produits et services délivrés sont conçus
• Le nombre de Dunbar sur la taille d’une équipe, impact sur le niveau de confiance développé
• Pourquoi minimiser la charge cognitive d’une équipe
• La culture “Team-First” 
• Les principes d’une architecture / design : couplage faible & cohésion forte : minimiser les dépendances entre équipes, maximiser la cohésion au sein des équipes
• Les conséquences parfois négatives à déplacer les personnes d’équipe en équipe, à ne pas laisser du temps pour créer la confiance

4 Typologies

La seconde partie du livre introduit les 4 types d’équipes suivantes :

• “Stream-Aligned Team” : équipe pluridisciplinaire en charge de délivrer un service/produit à des clients/utilisateurs. C’est en quelque sorte l’équipe “agile” qui possède les compétences et la responsabilité pour livrer un produit/service terminé.
• “Enabling Team” : équipe en charge de faire grandir les équipes “Stream-Aligned”, c’est-à-dire développer leur autonomie et leurs compétences en prenant le temps nécessaire à la veille, à la recherche, etc… Attention cette équipe est bien au service des autres équipes et n’impose pas ses choix de façon unilatérale.
• “Complicated-subsystem Team” : une équipe qui prend en charge un élément du système afin de diminuer la charge cognitive des autres équipes “Stream-Aligned”
• “Platform Team” : équipe en charge de délivrer une plateforme à d’autres équipes “Stream-Aligned” : on peut voir ce type d’équipe comme étant au service de clients internes (qui sont les autres équipes). Cela suppose une étroite collaboration entre équipes pour s’assurer de la valeur du service rendu.

La description de cette typologie est accompagnée de conseils, de retours d’expérience, notamment sur le passage d’une organisation traditionnelle à une organisation exploitant cette typologie, dans le but d’obtenir un flux de valeur plus efficace. Les retours de terrain recommandent que le nombre de “Stream-Aligned Teams” soit plus grande que la somme des autres types d’équipes (rapport au moins 5 pour 1).

Responsabilités des Équipes

Il s’en suit des considérations sur comment définir la responsabilité de chaque équipe (périmètre, scope ou frontières “boundaries”). Ce travail de définition de responsabilité revient plus ou moins à faire le “design” (ou architecture) de l’organisation des équipes. 

Définir des frontières claires est un prérequis à une bonne communication entre les équipes et une forte responsabilisation de celles-ci. Mais alors comment définir ces frontières ?

Les auteurs utilisent le terme suivant “plan de fracture naturelle” pour illustrer des axes possibles de découpage (des responsabilités) et qui sont inhérents à chaque contexte et entreprise. Il faut se rappeler que ce découpage doit coller à l’architecture du produit/service et devrait minimiser le couplage (inter-équipe) et maximiser la cohésion (intra-équipe). Par conséquent, il est tout à fait possible de créer des designs d’équipes – en apparence efficaces – mais qui délivrent un produit finalement monolithique (cas des microservices développés par des équipes différentes, mais dont le nombre d’interdépendances est élevé).

Ci-dessous une figure qui illustre un cas de design d’équipe qui vise à minimiser dépendances et charge cognitive pour l’équipe initialement en place.

Interactions entre Équipes

La troisième partie du livre concerne les interactions entre équipes et comment les faire évoluer pour accélérer l’innovation et les livraisons de valeur.

Les auteurs définissent 3 modes d’interactions entre les équipes :

• Collaboration : les 2 équipes collaborent, co-développent la solution. C’est un mode très utile dans les phases complexes de découverte.
• X-as-a-service : une des 2 équipes fournit un service/produit à l’autre équipe. Ce mode pourrait être l’évolution retenue après une phase de découverte s’appuyant sur un mode “Collaboration”.
• Facilitating : une des 2 équipes fournit de l’aide à l’autre équipe (résolution d’obstacles).

A titre d’exemple, une équipe de type “Platform Team” est souvent en mode “as-a-service” pour plusieurs “Stream-Aligned teams”.

Les auteurs dressent un inventaire des avantages et inconvénients des 3 différents modes d’interaction. Ils donnent aussi des clés pour comprendre les “déclencheurs” (triggers) qui feraient qu’un mode d’interaction serait remplacé par un autre, car plus adapté à la situation.

Mise en place

Enfin, à la fin de cette troisième partie, les auteurs donnent des détails pratiques pour mettre en place et faire vivre une approche qui intègre cette proposition de “Typologie d’équipes”. Comment démarrer ? Quelle organisation minimale mettre en place ? Comment prendre soin et faire évoluer l’existant ? Attention, les auteurs ne prétendent pas que ce modèle de typologie d’équipe est la clé du succès. Leur démarche s’intègre avec d’autres démarches et pratiques qui vont dans le même sens (voir les références et suggestions de lecture à la fin du livre).

Conclusion

Le livre s’appuie principalement sur des entreprises du digital (IT) mais j’imagine sans peine que les principes et grandes lignes du modèle restent valides pour une entreprise qui délivre aussi des biens matériels (et non exclusivement logiciels).

Voici les points qui m’ont marqué à la lecture de ce livre :

• le modèle “Team Topologies” lui-même (les 4 types d’équipe et les 3 modes d’interactions) pour sa clarté. Je pense même que je vais l’utiliser comme outil d’analyse chez mes clients
• les retours d’expérience qui aident à assimiler ce modèle
• la richesse des références et les suggestions de lecture pour approfondir le sujet

J’espère vous avoir donné envie de lire cet ouvrage à votre tour, ou bien de partager vos retours si vous l’avez déjà lu 😉