[su_column size=»2/3″ center=»yes»]
Durante los últimos tres años, hemos asistido a una proliferación de metodologías y frameworks que intentan resolver los problemas que se presentan al escalar Scrum. Scaled Agile Framework (SAFe) y LessWorks son los más representativos. Nexus es la propuesta del creador de Scrum, Ken Schwaber, junto con el equipo de Scrum.org para escalar Scrum usando Scrum, cuya guía saldrá en Otoño
Mientras que Scrum ya es utilizado por el 90% de los equipos que desarrollan Software en el mundo, muchas organizaciones buscan modelos que les permita escalar los beneficios obtenidos por uno o dos equipos a toda la organización. Nexus es la propuesta de Ken Schwaber, creador de Scrum, para conseguir estos beneficios.
Definición de Nexus
La guía oficial de Nexus lo define como una Unidad de desarrollo. Si en Scrum la unidad son los equipos Scrum, en el caso de Nexus la unidad se compone de 3 a 9 equipos Scrum junto con un equipo de integración Nexus trabajando en un unido Product Backlog, que integra su trabajo al final de cada Sprint.
Entendiendo la razon de ser de Nexus
Scrum es, de acuerdo con el 9º informe sobre el estado del desarrollo ágil de Software (descarga gratuita con registro, en Inglés) que todos los años elabora VersionOne, el método de desarrollo preferido por compañías que adoptan métodos ágiles de desarrollo de software, con un 56% de cuota, seguido por XP, con casi un 25%.
Nexus sigue la misma filosofía de Scrum: Escalar mientras se entrega Software debe ser un proceso orgánico, en el que se eliminan impedimentos al mismo tiempo que se miden las limitaciones que permiten seguir creciendo. Nexus se basa en la inteligencia de las personas que forman el sistema.El gran problema de Scrum es que proporciona unas reglas de uso que no tienen en cuenta muchas de las estructuras existentes en empresas ya establecidas. Eso ha dado lugar a muchas innovaciones a lo largo de los anos (como el Scrum of Scrums) que han mitigado la problemática de integrar el trabajo de varios equipos que trabajan en el mismo producto.
Precisamente ese problema es la gran ventaja de Scrum. A diferencia de otros métodos como SAFe, donde prácticamente todo viene prescrito, al igual que anteriormente ocurrió con RUP (también de Dean Lefingwell), dando lugar a una rigidez que Scrum quería evitar. Es por tanto no un problema de diseño del framework, sino una decisión de sus creadores para dar espacio a generar soluciones a medida de las organizaciones que lo adoptaban.
Hace más de cinco años, se hizo evidente que mas empresas y organizaciones estaban dispuestas a pagar por soluciones out-of-the-box que a pensar como resolver sus problemas, lo que dio lugar al boom al que estamos asistiendo hoy. Es por eso que Ken, junto con Scrum.org, decidieron empezar a darle forma a Nexus. Había que recuperar el mismo espíritu que hizo a Scrum popular para elaborar una solución coherente de escalado.
Los comienzos de Nexus
En Diciembre de 2014, asistí con otros 20 Professional Scrum Trainers a la primera versión de Scaled Professional Scrum en las instalaciones de Prowareness en Holanda. Por aquel entonces, después de dos días, era evidente que el acercamiento que Scrum.org había querido darle al programa, no era suficiente.
¿Y cual era este enfoque? Pues uno tan simple como: «Usa Scrum para escalar Scrum», «Usa Scrum para hacer visibles tus problemas» y «Inspecciona y adapta para resolverlos y buscar soluciones». Nexus es el resultado de ese enfoque, nacido de la filosofía del empiricismo.
En el informe de VersionOne, los entrevistados reconocen que, a pesar del boom de soluciones de escalado, el método preferido de escalado (69%) sigue siendo el «Scrum of Scrums». La realidad se impone a la ilusión de pensar que lo nuevo es mejor que lo antiguo.
Y cual es la propuesta de Nexus
El motto de Nexus es que Nexus sigue siendo Scrum. A escala, pero Scrum. Y como tal, utiliza los elementos de Scrum para escalar a partir de tres equipos. Si un Scrum Team esta formado por equipos de 3 a 9 personas, un Nexus esta formado por 3 a 9 equipos Scrum.
- Roles: Nexus introduce un nuevo rol: El Equipo de Integración Nexus. Uno de los aspectos a los que se le presta especial atención en el Nexus es a la Integración. Si en Scrum el objetivo era entregar un Incremento al final de cada Sprint, en Nexus es entregar un Incremento Integrado. Para ello se hace un enfoque en el equipo de integracion Nexus, que es el responsable de que esto ocurra, introduciendo herramientas y ayudando a los equipos a conseguirlo.
- Artefactos: Todos los equipos usan el mismo Product Backlog y tienen Sprint Backlogs individuales. Un nuevo artefacto, el Nexus Sprint Backlog, se usa para mantener la transparencia del proceso. Así, se puede visualizar todo el trabajo que están realizando los equipos de manera integrada.
- Eventos: Se utilizan los eventos de Scrum. Ahora hay un Nexus Daily Scrum que ocurre antes que el de los equipos donde se identifican posibles dependencias y problemas de integración y se utiliza como una herramienta para dar información a los equipos sobre que ocurre.
Los beneficios de Nexus
- Organiza equipos para maximizar la productividad.
- Organiza a la gente en equipos adecuados para optimizar el esfuerzo.
- Ensena a los Managers como organizar y gestionar un numero muy grande de personas para construir software rápidamente.
- Ayuda a los Managers a detectar anomalías en la productividad.
- Proporciona practicas para resolver las anomalías.
- Presenta un patrón que permite auto-organizacion para un gran numero de desarrolladores.
Mas información sobre Nexus
La guía oficial de Nexus estará disponible gratuitamente en Otoño. Durante estos días he tenido acceso a la guía para dar mi feedback a Ken y al equipo de Scrum.org y lo que puedo decir es que es una pieza fundamental como ya lo es la guía de Scrum. En los próximos meses asistiremos a nuevos libros, artículos y blogs dedicados exclusivamente a Nexus y como utilizarlo.
Mientras tanto, el glosario de Nexus se puede consultar en Scrum.org, así como las próximas ediciones del curso y certificación Scaled Professional Scrum.
El rol del Nexus Integration Team
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.
Más sobre el Nexus Integration Team
- El whitepaper de Scrum.org sobre el Nexus Integration Team (En Inglés)
- 9 claves para entender el Nexus Integration Team (En Inglés)
- La guía de Nexus en español
- Video de mi charla sobre Nexus en la CAS2015
- Próximas ediciones del curso Scaled Professional Scrum
[/su_column]