Escalar Scrum con Nexus

27/03/2021
Escalar Scrum con Nexus surge de la necesidad de escalar Scrum o productos a nivel organizacional o trabajar con muchos equipos dentro de un producto utilizando Scrum, suele ser todo un reto. Para ello, hoy me gustaría hablarte de marcos de escalado, sobre todo Nexus que es Scrum escalado.
como pasa el examen de Nexus - Scaled Professional Scrum o llamado tambien SPS

Como sabrás existen varios marcos de escalado, como puede ser: LeSS, SAFe, DAD, Spotify, etc. En este caso compartiré contigo una introducción a Nexus.

¿Por qué surge Nexus?

En las grandes empresas que empiezan a asomar la cabeza en el mundo de la agilidad, se dan cuenta de que existen algunas dificultades al implementar Scrum, sobre todo cuando son varios los equipos que están colaborando para el desarrollo de producto. Nexus es simplemente Scrum, pero con ciertos cambios que permiten a varios equipos trabajar juntos gestionando sus dependencias. Este marco de escalado al igual que Scrum y se basa en la teoría del empirismo.

Escalar Scrum con Nexus

¿Qué roles hay en Nexus?

Nexus Integration Team

El equipo de integración Nexus está compuesto por:

  • El product Owner
  • El Scrum Master Nexus(que puede ser el Scrum Master de un equipo Scrum)
  • Uno o más miembros del equipo de integración Nexus (suelen ser miembros de equipos Scrum)

Este equipo es responsable de asegurar que en cada Sprint se genere un incremento integrado. Esto no quiere decir que lo tiene que hacer el equipo, sino los equipos Scrum individuales. Ellos son los responsables de entregar incrementos funcionales y potencialmente entregables en producción. Los miembros del NIT suelen tener habilidades en el uso de herramientas, diferentes prácticas y generalmente un buen conocimiento en la ingeniería de sistemas.
Nota: Nexus se compone de 3 a 9 equipos Scrum. Los equipos Scrum siguen las mismas reglas que comenta la guía Scrum.

Product Owner

Al igual que en Scrum, solo hay un producto y por tanto un Product Backlog y un Product Owner, será la persona que tendrá la última palabra sobre lo que hay que hacer ¡Cuidado con hacer un backlog por equipo!. El PO (Product Owner) es el responsable de la gestión del backlog y de la manera de conseguir maximizar el valor del producto que en este caso es integrado al tenerse que unir el trabajo de todos los equipos.

Scrum Master en el NIT

Dentro del equipo de integración Nexus (NIT), existe la figura del Scrum Master. Este es el responsable de que Nexus se entienda y se aplique correctamente. Cabe la posibilidad de que este sea Scrum Master de un equipo.

Development Teams (desarrolladores)

En Nexus hay equipos de desarrollo que hacen el producto, pero  aquí hablamos de varios equipos, más o menos entre 3 a 9 equipos. Para más información sobre los equipos de desarrollo te animo a que leas la guía oficial de Scrum.

Eventos en Nexus

Refinement

Este evento tiene un propósito esencial: dar transparencia, detectar y minimizar las dependencias entre equipos de Nexus. El refinamiento del Product Backlog a nivel de Nexus ayuda a los equipos a tener una previsión de qué es lo que pueden entregar de un modo individual y a gestionar las dependencias.
Este evento no elimina el refinamiento que los equipos Scrum individuales puedan refinar el Backlog para la selección de los elementos en la Planning de Nexus.

Nexus Sprint Planning

El objetivo de este evento es coordinar las actividades de los equipos Scrum en Nexus para el próximo Sprint. Para ello se debe refinar el Product Backlog e identificar las dependencias previamente. Durante este evento el Product Owner negocia el Nexus Sprint Goal. Así que una vez se entienda el trabajo a realizar, la planificación continua con la ejecución por parte de cada equipo de su propia planificación individual. Y solo se da por terminada la planificación de Nexus cuando todos los equipos hayan terminado su propia planificación.
Nota: Nexus Sprint Goal, es el total de todos los objetivos individuales de los equipos Scrum y el trabajo del Sprint.

Nexus Daily Scrum

Durante este evento se reúnen representantes (personas adecuadas) de cada equipo para inspeccionar el estado del incremento integrado, identificar problemas de integración, detectar dependencias que pueden surgir (o existentes), o identificar impactos entre equipos.
A lo largo de este evento los participante debaten sobre el impacto de cada equipo, usando la siguientes preguntas:

  • ¿El trabajo del día anterior fue integrado exitosamente? Si no ha sido así, ¿Por qué no?  
  • ¿Qué nuevas dependencias han sido identificadas?
  • ¿Qué información necesita compartirse entre los equipos del Nexus?

Los resultados obtenidos en este evento se trasladan a los equipos Scrum para que realicen su propia planificación de 24h durante su Daily Scrum.

Nexus Sprint Review

En Nexus se celebra el evento de la Review al final de cada Sprint con el propósito de inspeccionar el incremento integrado, adaptar el backlog y obtener feedback. Es importante señalar que solo hay este evento, o sea los equipos Scrum no realizan Sprint  Review individual.

Nexus Sprint Retrospective

Al igual que en Scrum, en Nexus existe el evento de la retrospectiva Nexus. Se trata de una oportunidad formal para que nos inspeccionemos y adaptemos nosotros mismos creando así un plan de mejoras para el próximo Sprint. El objetivo es promover la mejora continua. No obstante hay algo nuevo aquí. Este evento consta de 3 partes:

  • La primera es para los representantes de los equipos, en la cual identifican los problemas que hayan impactado a más de un equipo.
  • La segunda parte consiste en que cada equipo realiza su propia retrospectiva. Donde analizan los problemas comunes y los propios del equipo.
  • En la última parte  se vuelven a juntar los representantes para  llegar a un acuerdo de que acciones van a tomar para esos problemas que detectaron.

Artefactos

Product Backlog

Solo  existe un Product Backlog en Nexus. El Product Owner es el responsable del contenido, disponibilidad y de ordenar el Product Backlog.

Nexus Sprint Backlog

Es la unión de los elementos del Sprint Backlog de todos los equipos individuales.

Integrated Increment

Representa la suma de todo el trabajo integrado por Nexus. El Incremento debe ser usable, potencialmente entregable en producción.

Definition of Done

El NIT es el responsable de que exista una definición de hecho y que pueda ser aplicado al incremento integrado.
Esta es una introducción/resumen. Si quieres saber sobre Nexus, aquí tienes la guía oficial de este marco de escalado de Scrum.

Material de interés sobre Nexus

Como escalar Scrum, o Scrum a escala

¿Te ha gustado este contenido?

¡Valora este contenido!

Promedio de puntuación 5 / 5. Recuento de votos: 2

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Escrito por: Youssef Oufaska
Amo las actividades en familia, aficionado a la salsa cubana, bachata dominicana, desarrollo de productos digitales y la programación

Otras publicaciones

Apúntate a la newsletter

Apúntate a la newsletter

Manténte informado sobre todo lo relacionado con Agile Product Management, Scrum, Management 3.0 y Kanban

¡Mensaje enviado!

Training from the BACK of the Room!

 11 y 12 de noviembre en Madrid

Facilitado por Jose Casal

You have Successfully Subscribed!