Tres equipos, un producto: lo que Nexus le enseñó a un programa en recuperación
Cuando una organización de servicios regionales reactivó a principios de 2021 un programa de software detenido, contaba con tres equipos Scrum que funcionaban bien cada uno por su cuenta. El problema era que estaban construyendo un solo producto, y «cada uno por su cuenta» se había convertido, sin que nadie lo notara, en la dificultad misma. Entregas que antes tomaban dos semanas tardaban ahora seis. Cada Sprint terminaba con una semana frenética de fusiones de código, pruebas y reproches. Los equipos no eran malos en Scrum; eran buenos en aislamiento, que es algo muy distinto.
La dirección leyó el marco Nexus de Scrum.org y decidió probarlo en lugar de inventar otra capa de coordinación casera. Nexus es deliberadamente ligero: toma de tres a nueve equipos Scrum que trabajan en un único producto, añade una nueva responsabilidad —el Equipo de Integración Nexus— y un nuevo foco de eventos, y pide a todos que traten la integración como una preocupación de primer orden y no como una sorpresa de fin de Sprint. Lo que sigue es lo que de verdad cambió, contado con sencillez, porque el marco sobre el papel y el marco en un taller híbrido, en parte remoto, no son la misma experiencia.
Primera lección dura: la integración es tarea de todos, pero alguien debe responder por ella
El Equipo de Integración Nexus no es un equipo aparte de especialistas que quita trabajo a los demás. Es una responsabilidad de coordinación, normalmente cubierta por personas que también forman parte de los equipos Scrum habituales, incluidos el Product Owner y a menudo los ingenieros más experimentados. Su labor es asegurar que el incremento combinado realmente se una. En el programa en recuperación, el error inicial fue tratar esto como un añadido a tiempo parcial. El trabajo de integración siempre perdía frente al de funcionalidades, porque este último tenía un dueño visible y la integración no. Una vez que la organización nombró a personas concretas, les dio tiempo protegido e hizo del incremento integrado lo único que contaba como «terminado», las entregas de seis semanas empezaron a acortarse de nuevo.
Ayudó replantear la época que vivían. Saliendo de la disrupción del año anterior, con gente aún repartida entre la casa y la oficina y plazos de suministro poco fiables, la tentación era dejar que cada equipo optimizara su pequeño mundo. Nexus se opone a ese instinto a propósito.
Las dependencias entre equipos salen a la luz en la planificación, o te emboscan más tarde
Nexus adelanta el descubrimiento de las dependencias. Antes de que los equipos planifiquen sus Sprints individuales, los representantes se reúnen para revisar juntos el Product Backlog e identificar dónde el trabajo de un equipo depende del de otro. No es una ceremonia pesada; es una sesión de trabajo que produce una visión compartida de qué debe integrarse y en qué orden.
Haga visibles las dependencias pronto. Refine y descomponga los elementos del backlog lo suficiente para que los vínculos entre equipos sean obvios antes de la Planificación del Sprint, no descubiertos a mitad de Sprint.
Secuencie primero las integraciones arriesgadas. Si dos equipos deben conectar un servicio compartido, programe esa conexión al inicio del Sprint para que un fallo deje tiempo de recuperarse.
Integre con frecuencia, no al final. Apunte a un incremento integrado al menos a diario; el Daily Scrum de Nexus existe para detectar problemas de integración, no solo para seguir el progreso individual.
Mantenga el incremento entregable en todo momento. Una única Definición de Terminado para todos los equipos mantiene una calidad constante e impide que los atajos de un equipo rompan el conjunto.
Lo que mostraron tanto los números como la sala
En pocos Sprints cambiaron las señales visibles. El Daily Scrum de Nexus —donde los representantes se centran en los problemas de integración antes de que los equipos celebren sus propios Daily Scrums— detectaba los problemas cuando aún era barato corregirlos. La Revisión del Sprint de Nexus mostraba a las partes interesadas un producto integrado en vez de tres demostraciones que no encajaban del todo. La retrospectiva dejó de ser una lista de agravios entre equipos y pasó a ser una conversación sobre el sistema que compartían.
Escalar no significó añadir proceso; significó eliminar los puntos ciegos entre equipos.
El incremento integrado, y no la producción de cada equipo, es la única medida honesta del progreso.
El trabajo híbrido convirtió la comunicación abundante en una virtud, no en un coste: dependencias compartidas y visibles superan a la coordinación de pasillo que ya no existía.
La organización no se convirtió en un modelo de Nexus de la noche a la mañana, ni le hacía falta. El propósito del marco es modesto y útil: conservar el espíritu ligero de Scrum dando a varios equipos una forma disciplinada de entregar una sola cosa juntos. La disciplina está en la integración, y la integración es el trabajo.
Si su programa tiene buenos equipos que luchan por entregar como uno solo, la asesoría de entrega de programas y proyectos de XNM puede ayudarle a establecer la coordinación —y la responsabilidad— adecuadas.