6 min lectura • Guide 421 of 877
Coordinación Multi-Equipo
La coordinación multi-equipo permite iniciativas más grandes de lo que un equipo puede manejar. Buena coordinación alinea equipos sin crear burocracia. Mala coordinación crea reuniones, retrasos, y frustración. Esta guía cubre coordinación cross-team efectiva.
Patrones de Coordinación
| Patrón | Mejor Para |
|---|---|
| Scrum of Scrums | Sync diario |
| Planning conjunto | Sprint/PI planning |
| Board de dependencias | Visibilidad |
| Demo cross-team | Alineación |
Scrum of Scrums
SCRUM OF SCRUMS
═══════════════
ESTRUCTURA:
┌─────────────────────────────────────────────────────────────┐
│ ├── Un rep por equipo │
│ ├── Diario o 2-3x/semana │
│ ├── 15 minutos máximo │
│ ├── Foco en blockers/dependencias │
│ ├── No es reporte de status │
│ └── Sync rápido │
└─────────────────────────────────────────────────────────────┘
PREGUNTAS:
┌─────────────────────────────────────────────────────────────┐
│ Cada rep de equipo responde: │
│ ├── ¿Qué logró el equipo? │
│ ├── ¿Qué está planeado después? │
│ ├── ¿Qué nos está bloqueando? │
│ ├── ¿Qué necesitamos de otros equipos? │
│ └── Foco inter-equipo │
└─────────────────────────────────────────────────────────────┘
FORMATO:
┌─────────────────────────────────────────────────────────────┐
│ Rep Equipo A: │
│ ├── "Terminamos los endpoints del API" │
│ ├── "Comenzando integración front-end" │
│ ├── "Necesitamos que Equipo B deploye auth service" │
│ └── Rápido, específico │
└─────────────────────────────────────────────────────────────┘
FOLLOW-UP:
┌─────────────────────────────────────────────────────────────┐
│ ├── Blockers se discuten offline │
│ ├── No se resuelven en la reunión │
│ ├── Las personas correctas conectan después │
│ ├── La reunión surfacea, no resuelve │
│ └── Uso eficiente del tiempo │
└─────────────────────────────────────────────────────────────┘
Gestión de Dependencias
GESTIÓN DE DEPENDENCIAS
═══════════════════════
BOARD DE DEPENDENCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Equipo A Equipo B Equipo C │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Auth │─────►│ API │─────►│ UI │ │
│ │ Service│ │ Gateway│ │ Login │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ Dependencia: C necesita B, B necesita A │
│ │
│ STATUS: │
│ ├── Auth Service: ✅ Listo Sprint 5 │
│ ├── API Gateway: 🔄 En progreso Sprint 6 │
│ └── UI Login: ⏳ Esperando API │
│ │
└─────────────────────────────────────────────────────────────┘
TIPOS DE DEPENDENCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 🔴 BLOQUEANTE: │
│ No podemos continuar sin el deliverable │
│ Requiere coordinación activa │
│ │
│ 🟡 SOFT: │
│ Podemos hacer workaround temporal │
│ Coordinar timeline preferido │
│ │
│ 🟢 INFORMATIVA: │
│ Solo necesitamos saber cuándo está listo │
│ Mínima coordinación requerida │
│ │
└─────────────────────────────────────────────────────────────┘
Planning Conjunto
PLANNING MULTI-EQUIPO
═════════════════════
BIG ROOM PLANNING (PI PLANNING):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Frecuencia: Cada 8-12 semanas │
│ Duración: 1-2 días │
│ Participantes: Todos los equipos involucrados │
│ │
│ AGENDA: │
│ ├── Vision y contexto de negocio │
│ ├── Architecture overview │
│ ├── Teams breakout para planning │
│ ├── Draft plans review │
│ ├── Identificar dependencias │
│ ├── Risk identification │
│ ├── Management review │
│ └── Commit final │
│ │
└─────────────────────────────────────────────────────────────┘
OUTPUT ESPERADO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ├── Objetivos del Program Increment │
│ ├── Plan de cada equipo para PI │
│ ├── Dependencias mapeadas │
│ ├── Riesgos identificados con mitigación │
│ └── Confidence vote (fist of five) │
│ │
└─────────────────────────────────────────────────────────────┘
Comunicación Cross-Team
CANALES DE COMUNICACIÓN
═══════════════════════
ESTRUCTURA RECOMENDADA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ASÍNCRONO: │
│ ├── Slack/Teams: #program-updates │
│ ├── Wiki: Decisiones y arquitectura │
│ ├── Board compartido: Estado de dependencias │
│ └── Newsletter semanal de programa │
│ │
│ SÍNCRONO: │
│ ├── Scrum of Scrums: Diario/3x semana │
│ ├── Demo de Programa: Cada sprint │
│ ├── Retrospectiva de Programa: Mensual │
│ └── PI Planning: Cada 8-12 semanas │
│ │
│ AD-HOC: │
│ ├── Escalation path claro │
│ ├── Owners de dependencias identificados │
│ └── Horarios de oficina para preguntas │
│ │
└─────────────────────────────────────────────────────────────┘
GitScrum para Multi-Equipo
CONFIGURACIÓN EN GITSCRUM
═════════════════════════
ESTRUCTURA DE PROYECTOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OPCIÓN 1: Proyectos separados + Epic compartido │
│ ├── Proyecto: Team Alpha │
│ ├── Proyecto: Team Beta │
│ ├── Proyecto: Team Gamma │
│ └── Epic: "Initiative X" linkea stories de todos │
│ │
│ OPCIÓN 2: Proyecto de programa + sub-proyectos │
│ ├── Proyecto: Program Level │
│ │ └── Milestones, Epics, Dependencias │
│ └── Sub-proyectos: Team boards │
│ │
└─────────────────────────────────────────────────────────────┘
LABELS CROSS-TEAM:
┌─────────────────────────────────────────────────────────────┐
│ 🔗 dependency │ Tiene dependencia externa │
│ ⏳ waiting-on-X │ Esperando equipo específico │
│ 🎯 program-goal │ Contribuye a objetivo de programa │
│ 🚨 blocker │ Bloqueando otro equipo │
└─────────────────────────────────────────────────────────────┘
TRACKING DE DEPENDENCIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Story: Implementar checkout flow │
│ │
│ Dependencias: │
│ ├── [Team B] Payment API - Sprint 5 │
│ ├── [Team C] Inventory check - Sprint 4 ✅ │
│ └── [External] Stripe integration - En progreso │
│ │
│ Status: Puede comenzar en Sprint 5 cuando Payment listo │
│ │
└─────────────────────────────────────────────────────────────┘
Resolución de Conflictos
CUANDO HAY CONFLICTO DE PRIORIDADES
═══════════════════════════════════
PROCESO DE ESCALACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. Los teams intentan resolver directamente │
│ └── 80% de conflictos se resuelven aquí │
│ │
│ 2. Escalar a Product Owners │
│ └── Negociar prioridades de backlog │
│ │
│ 3. Escalar a Release Train Engineer / Program Manager │
│ └── Decisión considerando programa completo │
│ │
│ 4. Escalar a stakeholders de negocio │
│ └── Decisión de trade-off de negocio │
│ │
│ REGLA: Escalar rápido es mejor que estar bloqueado │
│ │
└─────────────────────────────────────────────────────────────┘