El Nexus Integration Team es un nuevo rol dentro de Nexus, el framework de referencia para escalar Scrum. A diferencia de el Scrum of Scrums, que es solamente una reunión ad-hoc, el NIT, como rol, cumple la función de asegurar que al final de cada Sprint, en el Sprint Review, el Nexus entrega un incremento integrado que cumpla la definition of Done mínima para el Nexus.
Nexus, el framework de escalado usando Scrum de Ken Schwaber y Scrum.org, se presentó hace casi dos años. Después de un intenso trabajo previo por parte de la comunidad de trainers, que han aportado su experiencia al framework y a la clase de Scaled Professional Scrum.
La gran novedad de Scrum a escala usando Nexus es la del Nexus Integration Team, abreviado como NIT. La responsabilidad de este rol, formado por representantes de los equipos, el Scrum Master y el Product Owner es asegurar que se produce la integración de producto.
Los retos del desarrollo de software a escala
Cuando trabajamos a escala, tenemos dos retos que abordar: Las dependencias y la integración de producto.
Ambas se controlan a través del NIT, que mediante sus representantes, que van cambiando conforme es necesario cada Sprint, trazan un plan de acción para ponerles freno.
Durante el Sprint, el NIT se reúne en el Nexus Daily Scrum para inspeccionar el progreso hacia un incremento integrado y llevar las acciones necesarias a los Daily Scrums de cada equipo.
La función del NIT es actuar como facilitador a la integración favoreciendo la comunicación de miembros que trabajan en equipos Scrum. Si un arquitecto forma parte del NIT, debe a la vez de formar parte de un equipo Scrum. Si alguien de QA forma parte del NIT es porque forman parte de un equipo Scrum.
¿Quien realiza la integración?
Aunque el NIT no realice la integración directamente, es responsable de la que integración se haga a lo largo de todos los incrementos de los equipos Scrum.
El NIT es un equipo virtual formado por representantes adecuados de cada uno de los equipos Scrum. El NIT incorpora a personas ajenas al Nexus (personas que no trabajan en ningún equipo Scrum) solamente cuando estos son necesarios para asegurar la integración.
Por tanto, las personas que forman el NIT tienen que ser aquellas que, dentro del contexto de los problemas de integración que pueden surgir el próximo Sprint, pueden facilitar que se eliminen los impedimentos relativos a la integración.
NIT: Dos caras de la misma moneda
El NIT como coach de los equipos de desarrollo
En un entorno normal donde se produce integración de producto, el NIT se comporta como elemento de cohesión entre distintos equipos Scrum. Al estar formado por representantes de esos equipos, la comunicación fluye desde el NIT a los equipos a través del Daily Scrum de cada uno de los equipos.
Además, el NIT mantiene una visión más estratégica de la evolución del producto a través de cada Sprint, asegurando que se cumple los requisitos de arquitectura, entorno, puesta en producción, requisitos no funcionales o calidad.
El NIT como equipo Scrum
En los casos donde no hay un contexto normal, el NIT actúa como un equipo Scrum. Por ejemplo, en el caso de que el Nexus sea incapaz de entregar un incremento terminado e integrado al final del Sprint, el Nexus toma las riendas del desarrollo. Las acciones pueden ir desde parar todo el desarrollo nuevo hasta marcar junto al Product Owner cual debe ser el alcance del Nexus Sprint Goal.
Equipo fijo vs Equipo virtual
El hecho de que haya personas fijas en el Nexus Integration Team puede significar que:
- Los miembros de la organización ven el NIT como una estructura de poder. Que se encarga de dirigir el Nexus. Nada más alejado de la realidad. El Nexus se dirige sólo y exclusivamente a través de un Product Backlog ordenado y prioridad por el Product Owner.
- Hay impedimentos a la integración que no son capaces de resolverse en un sólo Sprint. En este caso, cabe hacerse la pregunta: ¿Merece la pena que sigamos otro Sprint desarrollando si somos incapaces de producir un incremento integrado y terminado al final de cada Sprint?
¿Cuando se decide la composición del NIT?
El momento más adecuado es durante el Nexus Sprint Planning. En esta reunión, los equipos junto al Product Owner deciden que elementos van a realizar de cara a ofrecer un incremento integrado al final del Sprint.
Durante el Sprint Planning, los equipos ponen de manifiesto que problemas de integración y dependencias pueden encontrar en el próximo Sprint y acuerdan que personas formaran parte del NIT, que será responsable de la integración durante el Sprint.
Por último, recuerda que el NIT no hace la integración directamente -sería imposible-, sino que facilita que sean los equipos del Nexus los que consigan una integración terminada.
Algunos ejemplos del Nexus Integration Team en acción
Durante el Sprint Planning, los equipos ponen de manifiesto que no pueden conseguir un incremento integrado porque no disponen de un sistema de branching, control de versiones y calidad del código que asegure que se cumple la definition of done.
Así, cada uno de los equipos nomina a un desarrollador que se va a encargar de coordinarse con el resto y con su equipo para que el desarrollo se haga contra BitBucket.
Durante el Sprint, el NIT se reúne en el Nexus Daily Scrum para que estos miembros puedan llevar a sus equipos los problemas surgidos y ver como hacer un plan de 24h para resolverlos.
Veamos otro caso real.
Durante otro Sprint, un equipo detecta que tiene una dependencia de arquitectura con otro equipo. Lo ponen de manifiesto al NIT durante el siguiente Nexus Daily Scrum.
El NIT entonces incorpora a un arquitecto que trabaja en otro equipo Scrum y junto con los representantes de estos equipos, averiguan como resolver este problema de dependencias para poder integrar el product al final del Sprint.