Escalado y colaboración organizacional
Este dominio pregunta cómo colaboran varios equipos y la organización sin destruir la autogestión ni multiplicar la burocracia.
Escalar es simplificar primero
Antes de adoptar un marco de escalado, elimina dependencias: equipos con un producto y un backlog comunes, componentes compartidos con dueño claro, interfaces definidas. Escalar sin reducir dependencias solo añade reuniones.
Marcos habituales
Nexus añade el Nexus Integration Team y una Sprint Review conjunta para varios equipos que trabajan sobre un producto. LeSS mantiene un único Product Backlog, un Product Owner y una Sprint Review para varios equipos. SAFe organiza trenes de liberación (ART) con PI Planning y niveles de planificación. Scrum@Scale usa Scrum of Scrums y comunidades. Ninguno sustituye la autogestión de los equipos.
Colaboración organizacional
Comunidades de práctica, contratos que permiten iterar, y alineación con legal, finanzas y recursos humanos evitan que las áreas de soporte bloqueen la entrega. El liderazgo debe cambiar métricas e incentivos, no solo el organigrama.
Ejemplo razonado
Dos equipos dependen cada Sprint de un mismo componente, y cada integración rompe el trabajo del otro. Antes de crear un comité de coordinación semanal, el análisis muestra que el componente no tiene dueño claro. Opciones: asignarlo a un equipo, definir un contrato de API estable o fusionar ambos equipos. Reducir la dependencia resuelve la causa; el comité solo gestiona el síntoma.
Errores que cuestan puntos
Creer que SAFe es "Scrum para muchos equipos" sin más; suponer que un comité resuelve dependencias; tolerar Product Owners proxy sin autoridad; y adoptar un marco por decreto sin cambiar incentivos ni estructura.