Scrum nos dice que los equipos tienen que estar formados como mucho por nueve desarrolladores(¿Qué son los Roles de Scrum?), pero ¿qué pasa cuando el producto requiere un equipo mucho más grande? Para esto, Scrum tiene una solución: Pues se crean más equipos Scrum. El problema que se presenta entonces, es cómo se coordina la actividad de distintos equipos Scrum, trabajando en el mismo proyecto.
En este sentido hay varias formas de “escalar”, es decir, de organizar y aunar los esfuerzos de los distintos equipos: Scrum of scrum, LEss, SAfe, scrum@scale, DAD, spotify model, DSDM, Nexus…
El problema principal que surge, cuando varios equipos trabajan sobre el mismo producto, son las dependencias que aparecen. Hay dos factores en las dependencias que podemos identificar:
- Dimensiones: comunicación entre personas, requisitos de negocio, tecnología, infraestructura, etc…
- Donde están: intra-equipo, iter-equipos, externas.
Principalmente, lo que define la habilidad para escalar, es la habilidad para identificar y resolver dependencias y de integrar el trabajo en todos los niveles. Para ello no hay recetas, no hay una solución única que se adapte a todas las iniciativas de escalado y de ahí, la cantidad de aproximaciones que han surgido en los últimos años.
Voy a comenzar esta serie de post hablando de Nexus, que está desarrollado de forma colaborativa por Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber, and Gunther Verheyen. Recuerda que Ken Schwaber es uno de los dos autores de la guía Scrum, por lo que me parece que Nexus es la manera natural de escalar Scrum, si bien cada enfoque tiene sus pros y sus contras.
NEXUS
Nexus es una palabra inglesa que se traduce como una relación o conexión entre personas o cosas, y da nombre a este marco metodológico que consiste en roles, eventos, artefactos y las reglas que los unen, al igual que la definición de Scrum.
Básicamente Nexus, es un Scrum a escala: Si un Scrum Team lo forman entre 3 y 9 personas, un Nexus lo forman entre 3 y 9 equipos Scrum. Además se añaden:
- 1 rol nuevo: el NIT(Nexus Integration Team) que es el encargado de facilitar la integración entre el trabajo de los distintos equipos Scrum. Recuerda que el objetivo de Scrum es tener un Incremento entregable de producto al finalizar cada Sprint, por lo tanto el objetivo de Nexus es tener un Incremento Integrado de producto. El NIT está formado por el Product Owner, un Scrum Master y los miembros del equipo Nexus. Puede estar formado por personas que pertenecen a los equipos Scrum y a veces, si es necesario, por personas que no pertenecen a ningún equipo. Su formación suele definirse durante el Nexus Sprint Planning.
- 1 artefacto nuevo: Nexus Sprint Backlog, donde se puede visualizar todo el trabajo de forma integrada. Está formado por todos los Sprint Backlog de todos los equipos Scrum.
- 4 eventos nuevos: Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review y Nexus Sprint Retrospective, que básicamente son el equivalente escalado de los eventos de Scrum ( ¿Qué Eventos forman parte de Scrum?). Estos eventos se anexan o incluso reemplazan, llegado el caso, a los eventos propios de Scrum.
Principalmente, la manera de abordar las dependencias y la integración del trabajo es a traves del NIT, que se reune en el Nexus Daily Scrum previo al Daily Scrum de cada equipo, con el fin de llevar a estos las acciones necesarias para conseguir progresar hacia el Incremento Integrado. Durante dicho Nexus Daily Scrum se responden tres preguntas:
- El trabajo que se hizo ayer ¿fué satisfactoriamente integrado? Si la respuesta es no, ¿Por qué?
- ¿Qué nuevas dependencias o impactos han sido identificados?
- ¿Qué información necesita ser compartida entre todos los equipos?
Habitualmente, la Retrospectiva Scrum suele incluirse dentro del Nexus Sprint Retrospective, como una de las partes que conforman el evento.
Espero que esta entrada te haya clarificado algo sobre Nexus. Si quieres seguir aprendiendo, te recomiendo que te pases por la guía Nexus de Scrum.org.
