Trois façons pour les équipes de collaborer sans créer de goulots d'étranglement

Vous avez une équipe plateforme qui a construit un excellent pipeline CI/CD. Une équipe alignée sur le flux doit l'utiliser. Mais au lieu de simplement exécuter leurs déploiements, ils ne cessent de poser des questions à l'équipe plateforme. L'équipe plateforme se retrouve impliquée dans chaque release. Rapidement, plus personne ne fait son travail.

C'est le moment où connaître les types d'équipes ne suffit plus. Vous devez aussi savoir comment les équipes interagissent. Team Topologies décrit trois modèles d'interaction qui aident les équipes à collaborer sans créer de nouvelles dépendances ni se ralentir mutuellement. Chaque modèle correspond à une situation différente, et savoir lequel utiliser – et quand changer – fait la différence entre un delivery fluide et une surcharge constante de coordination.

Collaboration : Travailler ensemble sur des problèmes flous

La collaboration se produit lorsque deux équipes travaillent en étroite collaboration pendant une période définie. Elles partagent des canaux de communication, se synchronisent fréquemment et sont souvent situées dans le même espace. Ce modèle est utile lorsque le problème n'est pas encore bien compris et nécessite l'expertise des deux équipes.

Imaginez une équipe alignée sur le flux qui souhaite ajouter une fonctionnalité nécessitant des modifications dans un sous-système géré par une équipe de sous-système complexe. Aucune des deux équipes ne peut résoudre cela seule. L'équipe alignée sur le flux connaît les exigences fonctionnelles. L'équipe de sous-système complexe connaît l'architecture interne. Elles doivent travailler ensemble pour trouver la bonne conception, écrire du code connecté et vérifier que rien ne casse.

La collaboration est puissante, mais elle a un coût. Elle consomme l'attention des deux équipes. Elle crée des dépendances temporaires. C'est pourquoi la collaboration ne devrait pas durer éternellement. Une fois le problème résolu et le modèle devenu clair, l'interaction devrait passer à un modèle plus léger. Une collaboration prolongée rend les équipes dépendantes les unes des autres et les distrait de leurs propres flux de valeur.

La question clé à se poser : Avons-nous encore besoin d'un travail conjoint approfondi, ou pouvons-nous maintenant documenter ce que nous avons appris et passer à autre chose ?

X-as-a-Service : Fournir des capacités sans assistance

Dans le modèle X-as-a-Service, une équipe fournit une capacité que d'autres équipes peuvent consommer sans connaître les détails d'implémentation. L'équipe fournisseuse possède l'interface, la disponibilité et la qualité. L'équipe consommatrice l'utilise simplement – comme appeler une API ou exécuter un pipeline pré-construit.

C'est l'interaction naturelle entre une équipe plateforme et des équipes alignées sur le flux. L'équipe plateforme fournit des environnements, des pipelines CI/CD ou des outils de monitoring en tant que services. Les équipes alignées sur le flux n'ont pas besoin de comprendre comment le pipeline est construit ou maintenu. Elles l'utilisent simplement.

Le succès de ce modèle dépend d'une chose : une interface stable et claire. Si le service change fréquemment, ou si la documentation est incomplète, les équipes consommatrices sont frustrées. Elles commencent à construire leurs propres solutions. Cela va à l'encontre de l'objectif d'avoir une équipe plateforme.

X-as-a-Service réduit la surcharge de communication et permet à chaque équipe d'avancer à son propre rythme. Mais cela ne fonctionne que lorsque l'équipe fournisseuse traite l'interface comme un produit, et non comme une réflexion après coup.

Facilitation : Apprendre aux équipes à être autonomes

La facilitation est le modèle où une équipe aide une autre à améliorer une capacité spécifique sans prendre le contrôle du travail. C'est le modèle central pour les équipes de type enabling.

Une équipe enabling ne vient pas faire le travail à la place d'une équipe alignée sur le flux. Elle vient enseigner, coacher et fournir des exemples ou des guides. Par exemple, une équipe enabling spécialisée en sécurité applicative peut aider une équipe alignée sur le flux à comprendre comment écrire du code sécurisé, gérer les secrets ou intégrer un scan de sécurité dans leur pipeline. Une fois que l'équipe alignée sur le flux peut le faire seule, l'équipe enabling se retire et passe à une autre équipe qui a besoin d'aide.

La facilitation est différente de la collaboration car l'équipe enabling ne construit pas le produit. Elle est différente du X-as-a-Service car l'équipe enabling ne fournit pas un service permanent. L'objectif de la facilitation est de rendre les autres équipes indépendantes.

Le piège ici est une facilitation sans fin. Si une équipe enabling reste trop longtemps avec une seule équipe, elle devient une nounou permanente. L'équipe n'apprend jamais à fonctionner sans elle.

Les trois modèles peuvent fonctionner en parallèle

Ces trois modèles ne sont pas exclusifs. Dans une organisation saine, ils fonctionnent tous en même temps. Une équipe alignée sur le flux peut utiliser les services de l'équipe plateforme via X-as-a-Service, collaborer avec une équipe de sous-système complexe sur une fonctionnalité délicate, et recevoir une facilitation d'une équipe enabling sur les pratiques de test.

L'important est d'être conscient du modèle actif et du moment où il faut changer. Une collaboration qui se poursuit sans raison claire crée de nouvelles dépendances. Un X-as-a-Service avec une interface instable détruit la confiance. Une facilitation qui ne se termine jamais empêche les équipes de devenir autonomes.

Checklist pratique pour choisir les modèles d'interaction

Avant de mettre en place une nouvelle interaction entre équipes, parcourez cette checklist rapide :

Le diagramme suivant résume les points de décision clés de la checklist :

flowchart TD A[Nouvelle interaction d'équipe nécessaire] --> B{Problème bien compris ?} B -- Non --> C[Collaboration] C --> D[Définir une date de fin] B -- Oui --> E{La capacité peut-elle être fournie sans assistance ?} E -- Oui --> F[X-as-a-Service] F --> G[Traiter l'interface comme un produit] E -- Non --> H[Facilitation] H --> I[Planifier la sortie de l'équipe enabling]
  • Le problème est-il flou et nécessite une découverte conjointe ? Utilisez la collaboration, mais fixez une date de fin.
  • Une équipe a-t-elle une capacité stable dont d'autres ont besoin ? Utilisez le X-as-a-Service et traitez l'interface comme un produit.
  • Une équipe doit-elle acquérir une nouvelle compétence ? Utilisez la facilitation et planifiez la sortie de l'équipe enabling.
  • La collaboration dure-t-elle plus longtemps que prévu ? Demandez-vous si le modèle est devenu une habitude plutôt qu'une nécessité.
  • L'interface X-as-a-Service cause-t-elle de la frustration ? Corrigez l'interface ou la documentation avant d'ajouter d'autres fonctionnalités.
  • L'équipe enabling est-elle encore nécessaire après plusieurs mois ? L'équipe n'apprend peut-être pas. Passez à une approche différente.

L'essentiel à retenir

Les modèles d'interaction ne sont pas que de la théorie. Ce sont des outils pratiques pour décider quelle quantité de coordination est saine et laquelle est du gaspillage. La collaboration résout les problèmes difficiles mais doit être temporaire. Le X-as-a-Service accélère le delivery mais nécessite des interfaces stables. La facilitation renforce les compétences mais doit avoir un plan de sortie.

Les équipes qui livrent bien ne sont pas celles qui collaborent sur tout. Ce sont celles qui savent quand travailler ensemble, quand fournir un service, et quand enseigner puis s'effacer.