Carte Context Mapping #10 : Mutually Dependent Teams

📇 Carte #10 : Mutually Dependent Teams (Team Relationship)

Vue Rapide

🎯 Objectif : Deux équipes ont besoin l’une de l’autre - même poids politique

💼 Type de relation : Équipes au même niveau hiérarchique

🔗 Nature : Interdépendance inévitable

Concept

Deux équipes où ni l’une ne peut progresser indépendamment de l’autre.

Team A ←→ Team B
  Equal weight
  Mutual need
  Symmetric relationship

Caractéristiques

Ce qui les Définit

  • ✓ Même niveau hiérarchique : pas de subordination
  • ✓ Codépendance : l’une ne peut pas avancer sans l’autre
  • ✓ Poids politique équivalent : les deux ont du poids
  • ✓ Besoin mutuel : pas d’asymétrie

Ce qui les Différencie des Autres

VS. Upstream/Downstream:
  → Upstream/Downstream = asymétrique
  → Mutually Dependent = symétrique

VS. Independent:
  → Independent = zéro dépendance
  → Mutually Dependent = dépendance totale

Exemplesmonde réel

Frontend Team ↔ Backend Team (pour un même produit)
Catalog Service ↔ Inventory Service (interconnectés)
Platform ↔ Billing (même valeur critique)
Client Support ↔ Product Management (input/output)

Implications Organisationnelles

Coordination Nécessaire

  • 📅 Sprint planning ensemble
  • 🤝 Dailies synchronisées
  • 🎯 OKRs alignés
  • 📋 Dépendance tracking

Processus de Synchronisation

Decision/Change needed
    ↓
Both teams discuss
    ↓
Agree on approach
    ↓
Implement together
    ↓
Verify integration

Escalation

Désaccord?
    ↓
Try to negotiate (48h)
    ↓
If stuck: escalate to common manager
    ↓
Manager arbitrates

Patterns Associés aux Mutual Dependency

La plupart des patterns requièrent cette relation:

  1. Partnership → Mutually Dependent teams

    • Exemple: Frontend ↔ Backend

  2. Shared Kernel → Mutually Dependent teams

    • Exemple: Catalog ↔ Inventory (partagent Product)

  3. Customer/Supplier Development → Upstream/Downstream (asymétrique!)

    • Mais Customer peut devenir Supplier ailleurs

Gouvernance

Ownership Partagé

Code: Partagé (les deux sont responsables)
Data: Potentiellement partagée
Decisions: Consensus requis
Conflicts: Escalade rapide

Métriques

  • Response time à l’autre équipe
  • Incident resolution time
  • Feature delivery aligned/misaligned
  • Team happiness scores

Défis Typiques

Conflit de Priorités

Frontend: "On a besoin du Feature X urgently"
Backend: "On travaille sur performance fix, pas disponible"
    ↓
Must compromise and sync

Taille d’Équipe

Si Frontend a 10 personnes et Backend a 2:
    → Frustration Frontend
    → Bottleneck Backend
    → Besoin de rééquilibrer ou réarchitecturer

Communication Overload

Trop de réunions de sync?
    → Signal: peut-être trop couplées
    → Solution: découpler (Anticorruption Layer)

Indicateurs de Santé

Sain ✅

✓ Réunions courtes (30 min bi-weekly)
✓ Changements coordonnés (0-1 semaine délai)
✓ Équipes happy
✓ Peu d'incidents liés à l'intégration

Malsain ❌

❌ Réunions longues/fréquentes
❌ Changements unilatéraux
❌ Blaming entre équipes
❌ Incidents fréquents à l'intégration

Stratégie de Transition

Si Trop de Friction

Mutually Dependent
    ↓
Considérer Partnership (co-ownership)
    ↓
Ou Shared Kernel (code partagé)
    ↓
Ou découpler vers Separate Ways

Si Besoin de Meilleure Scalabilité

Mutually Dependent (2 équipes)
    ↓
Extraire 3ème équipe (Published Language)
    ↓
Chacune a sa relation avec les autres

Checklist pour Équipes Mutuellement Dépendantes ✓

  • Niveaux hiérarchiques clairement équivalents
  • Process de coordination régulier établi
  • Escalation path défini
  • Métriques pour tracker la santé
  • OKRs alignés ou en tension intentionnelle
  • Communication plan pour les changements

Ressources