¿Qué es Nexus en Scrum?

Nexus es un marco de trabajo creado por Ken Schwaber y scrum.org para escalar Scrum cuando un único equipo no basta para construir un producto. Reúne a varios Equipos Scrum que comparten un mismo objetivo y, sobre todo, pone el foco en lo que más duele al crecer: las dependencias entre equipos y la integración del trabajo en un único resultado entregable.

La idea central es simple. Scrum funciona bien con un equipo pequeño; cuando metes a cinco, ocho o nueve equipos en el mismo producto, no necesitas reinventar Scrum, sino añadir el mínimo de estructura para que esos equipos no se pisen entre sí. Nexus es exactamente eso: Scrum con unas pocas reglas, roles y eventos extra para coordinar a varios equipos sin perder agilidad.

El problema de escalar no es repartir tareas, es la integración. Cinco equipos pueden ir rapidísimo por separado y, aun así, fallar si al final de cada sprint sus trozos de software no encajan. Lo que en un equipo era una conversación de pasillo, con muchos equipos se convierte en dependencias ocultas, código que choca y un "ya lo integraremos al final" que casi siempre acaba mal.

Nexus importa porque hace visibles esas dependencias antes de que exploten y obliga a integrar de forma continua, no en el último día. Su métrica de éxito no es cuántas historias cierra cada equipo, sino si al cierre del sprint existe un Incremento Integrado: una sola versión del producto, probada en conjunto y potencialmente desplegable. Si eso no existe, el escalado es una ilusión.

Nexus parte de un grupo de tres a nueve Equipos Scrum trabajando sobre un único producto, con un solo Product Backlog compartido y un único sprint sincronizado. Sobre esa base añade tres piezas:

• Nexus Integration Team (NIT): un equipo responsable de que el trabajo combinado quede integrado y listo para desplegar al final de cada ciclo. No hace el trabajo de los demás; vela por las herramientas, las prácticas y el coaching necesarios para integrar. Lo forman el Product Owner, un Scrum Master y miembros que aportan conocimiento técnico.
• Un único Product Owner para todo el producto, que mantiene un backlog ordenado para todos los equipos.
• Eventos a nivel de Nexus que envuelven a los eventos de cada equipo.

Los eventos siguen el latido de Scrum, pero con una capa de coordinación:

1. Refinamiento entre equipos: se descomponen los ítems del backlog lo suficiente para detectar qué equipo depende de qué antes de planificar. Es la pieza diferencial de Nexus.
2. Nexus Sprint Planning: representantes de todos los equipos planifican juntos para acordar el Objetivo del Nexus y repartir el trabajo evitando dependencias cruzadas peligrosas.
3. Nexus Daily Scrum: representantes de los equipos se sincronizan a diario sobre el estado de la integración y los bloqueos que afectan a varios equipos.
4. Nexus Sprint Review: se revisa el Incremento Integrado completo, no las entregas sueltas de cada equipo.
5. Nexus Sprint Retrospective: retrospectiva en dos niveles, primero el conjunto y luego cada equipo, para mejorar la colaboración global.

El artefacto estrella es el Nexus Sprint Backlog, que muestra el trabajo de todos los equipos resaltando las dependencias, de forma que cualquiera pueda ver dónde un equipo espera a otro.

Imagina cinco equipos construyendo la misma app de banca. Sin un marco de escalado, cada equipo planifica por su cuenta y al integrar aparecen conflictos: el equipo de pagos asume una API que el equipo de cuentas aún no ha terminado, y el viernes nadie puede hacer deploy. Con Nexus, en el refinamiento conjunto se detecta esa dependencia, en el Nexus Sprint Planning se ordena el trabajo para que la API esté lista antes, y el Nexus Integration Team se asegura de que cada día el código se integra y se prueba en conjunto. Al cierre del sprint hay un solo Incremento Integrado de la app, no cinco mitades que alguien tendrá que pegar. Es la respuesta de scrum.org cuando un único equipo de Scrum, o un tablero Kanban por equipo, se queda corto para coordinar a tanta gente.

• Confundir Nexus con "muchos Scrums sueltos". Tener cinco equipos haciendo Scrum no es Nexus; sin un backlog único, un Objetivo de Nexus y la integración continua, solo tienes silos sincronizados de boca.
• Tratar el Nexus Integration Team como un equipo de QA al final. El NIT no es un cuello de botella que "valida" lo de los demás; su trabajo es que todos integren de forma continua durante todo el sprint.
• Saltarse el refinamiento entre equipos. Es justo la actividad que evita las sorpresas; si la recortas, las dependencias reaparecen en el peor momento.
• Escalar antes de tiempo. Si un solo equipo todavía no domina Scrum, añadir más equipos multiplica el caos. Nexus asume una base de Scrum sana.
• Medir por equipo y no por el conjunto. Premiar la velocidad individual de cada equipo incentiva optimizar el silo y descuidar el Incremento Integrado.

Nexus es una de varias respuestas al escalado ágil. Conviene compararlo con LeSS (Large Scale Scrum), SAFe y la técnica ligera de coordinación Scrum of Scrums. Para entender bien las piezas de las que parte, repasa el Scrum básico, el papel del Scrum Master, el Product Backlog y el ritmo del sprint.