El Marco Nexus para Escalar Scrum en el Desarrollo de Software

Scrum, siendo la forma ágil más común de trabajo de los equipos de desarrollo de software, lleva a la pregunta de: “¿Cómo escalamos Scrum más allá de un solo equipo?”Si tiene problemas con las dependencias entre equipos, los riesgos que afectan a varios equipos, la programación de entregas, es posible que necesite un marco de escalado.

Puede organizar varios equipos de Scrum de muchas maneras diferentes. En este artículo, profundizaremos en el marco Nexus para escalar Agile y Scrum, basado en la experiencia de DevCom. Hay otros marcos para escalar la metodología Ágil, como LeSS, SAFe, DAD (Entrega Ágil disciplinada) y, pero no se tratan en este artículo.

¿Qué es Nexus Framework?

Nexus framework fue fundado por el co-creador de Scrum Ken Schwaber y el Scrum.org equipo en 2015 como guía para escalar Scrum en proyectos ágiles de gran alcance.
Como Scrum se ha convertido en una parte integral de muchas organizaciones, sus proyectos deben ir más allá de las típicas sesiones de reuniones Diarias, de Planificación, Revisión y Retro utilizadas en el Scrum para ser eficaces. Scrum por sí solo no es suficiente cuando varios equipos trabajan en un producto. La productividad se erosiona debido a las dependencias entre los equipos.
Nexus framework utiliza Scrum como componente básico y lo amplía para una mejor gestión de varios equipos de Scrum que trabajan en un solo producto. Nexus se aplica a 3-9 grupos de scrum y los guía sobre cómo deben cooperar y compartir el trabajo para entregar software en cada Sprint con dependencias mínimas.

¿Cómo escala Nexus Framework Scrum?

Scrum es un framework a partir del cual evoluciona el proceso. Se centra en cómo un solo equipo de Scrum trabaja en un solo producto y entrega software en pequeños incrementos. La principal diferencia entre el marco Nexus y Scrum es la adición de un equipo de integración que se centra en facilitar las dependencias entre los equipos.

Marco Scrum

(Fuente)

Nexus para escalar ágiles

(Fuente)

Flujo de proceso Nexus:

  1. Refine el Backlog de Productos.
  2. Planificación de Sprints Nexus.
  3. Trabajo de desarrollo.
  4. Nexus Daily Scrum.
  5. Revisión de Nexus Sprint.
  6. Retrospectiva de Nexus Sprint.

En el momento de implementar el Nexus, no hay cambios significativos en los fundamentos de Scrum en sí. Nexus es lo mismo que agregar nuevas prácticas a Scrum, roles adicionales, eventos y artefactos solo cuando sea necesario para permitir iniciativas de desarrollo de software exitosas. Nexus aumenta el Scrum para permitir que el Scrum se escale de manera efectiva. Esto se logra aumentando la sencillez y la transparencia al trabajar a partir de un único Backlog de productos. Lo que importa es que se preste más atención a las dependencias entre los equipos de Scrum, que son responsables de entregar Incrementos “Hechos” en cada Sprint.

Una definición de “Hecho” es un criterio riguroso que se puede aplicar al Incremento Integrado desarrollado en cada Sprint, y que es seguido por todos los Equipos de Scrum de un Nexo.

 DevCom Cómo Nexus extiende Scrum

Implementación de Nexus Framework

El Nexus framework presume la experiencia Scrum. Las organizaciones que ya trabajan con Scrum podrán implementar Nexus fácilmente. Para iniciar un Nexus, las organizaciones deben identificar primero los equipos en su Nexus, un Equipo de Integración inicial de Nexus, un único Producto acumulado, una definición de “Hecho”, una cadencia de Sprint.

Estrategia de Implementación de Nexus

Define los equipos Scrum (mantén el foco en las características, en lugar de en los componentes). 1.1. Celebre una reunión y defina cómo formar equipos;
1.2. Asignar miembros del equipo (idealmente equipos hechos a sí mismos);
1.3. Definir los jugadores/representantes clave de cada equipo.
Definir los Entornos y repositorios para el desarrollo (en función del número de clientes (inquilinos) y el nivel de acceso). 2.1. Haga una lista de los repositorios actuales;
2.2. Reorganice los repositorios y los entornos de revisión para acortar el tiempo de entrega de las tareas;
2.3. Crear una base de código común (si es posible);
Definir el Equipo de Integración de Nexus (Miembros de los equipos Scrum. Puede variar dependiendo de la información que se difunda y se resuelva como resultado de Nexus Daily Scrum). 3.1. Definir personas responsables de integraciones principalmente y resolución de dependencias;
3.2. Asigna el rol de un maestro de Scrum dentro de cada equipo.
Enseñe y explique Scrum & Nexus framework. 4.1. Celebre una reunión para todos los equipos de Scrum y revise los conceptos básicos;
4.2. Facilitar las reuniones cuando sea necesario.
Definir herramientas con las que trabajar y dentro de ellas. 5.1. Definir herramientas de productividad y gestión de proyectos con las que trabajar y dentro de ellas e integrarlas (configurarlas).
Definir la “Definición de hecho”. 6.1. De acuerdo con el NIT sobre el término;
6.2. Cree un documento formal.
Defina el backlog de productos / refine el backlog de productos con el Propietario del producto (PO) o/y los representantes. 7.1. Registre los requisitos funcionales utilizando una de las herramientas anteriores;
7.2. Cree una plantilla con los campos obligatorios que debe rellenar (por ejemplo, nombre, descripción, criterios de aceptación, restricciones).
Obtenga la aprobación del propietario del producto & deje que priorice el backlog. 8.1. Involucre a PO para preparar y refinar el atraso;
8.2. Colaboración continua con PO para trabajar en el backlog de productos (escribir historias, tareas utilizando una plantilla 7.2).
Organice NIT para estimar el atraso utilizando puntos relativos. 9.1. Realice la primera parte de la reunión para adquirir una técnica de estimación.
9.2. Realice una segunda parte de la reunión para hacer estimaciones aproximadas de los artículos pendientes de productos (PBIs).
Implementar la Planificación de Sprint Nexus. 10.1. Definir cadencia de Sprint;
10.2. Defina dependencias, problemas de integración que puedan aparecer;
10.3. Alcance por definir: aproximadamente al menos 2 Sprints por delante y en curso;
10,4. Organice una reunión para ayudar a los miembros de NIT con la planificación de Sprints en equipos.
Implemente la Planificación de Sprint dentro de cada equipo de Scrum. 11.1. Utilice estimaciones absolutas para tareas y subtareas durante la planificación de Sprints;
11.2. Facilitar la planificación de Sprints para cada equipo;
11.3. Cree una plantilla de documento.
Implementa Nexus Daily Scrum y Daily Scrum para cada equipo. 12.1. Defina la hora, facilite las reuniones diarias de Scrum de Nexus (trate de mantenerlas con horario fijo);
12.2. Defina el tiempo, facilite las reuniones diarias de Scrum (manténgalas con horario fijo).
Implementar Revisión de Sprint Nexus (máx. 4h). 13.1. Realice una revisión de Nexus Sprint (incluida la grabación de demostración si es necesario) con miembros del equipo Scrum, PO y otras partes interesadas.
Implemente Reuniones retrospectivas y retrospectivas de Nexus Sprint para cada equipo de Scrum (cree un documento de plantillas) (máx.1h y 3h). 14.1. Realizar una reunión retrospectiva para NIT;
14.2. Cree un documento de plantilla;
14.3. Facilitar reuniones retrospectivas en equipos de Scrum.
14.4. Cree un documento de plantilla.
Implemente el evento de refinamiento Nexus de forma regular en función de la acumulación de productos. 15.1. Defina la frecuencia (tan a menudo como sea necesario; por ejemplo, 2 t / semana).
Implementar la estimación de los puntos de la historia (dependiendo de la iniciativa PO y la disposición a pronosticar). 16.1. Comience a rastrear la velocidad de los equipos de Scrum (después de 3 Sprints);
16.2. Haz un seguimiento del progreso usando el gráfico de quemado de Sprint.
Implementar dependencias visuales y su previsión entre tareas. 17.1. Visualice dependencias entre historias de usuario, tareas (por ejemplo, bandera y enlace);
17.2. Defina dependencias para el Sprint actual y dos Sprints por delante.
Iniciar actividades de gestión de proyectos para apoyar el proyecto. 18.1. Cree documentos que puedan ser útiles (por ejemplo, Carta del proyecto, Matriz de gestión de riesgos, Gestión de partes interesadas, Gestión de equipos (incl. Información de los miembros del equipo, prueba de disco, prueba de motivación, chequeo de salud del equipo));
18.2. Defina los KPI del proyecto y cree una plantilla para rastrearlos. Por lo general, incluyen velocidad, Quema de Sprint, CSAT. Los demás podrán incluir los cálculos presupuestarios;
18,3. Definir informes para las comprobaciones de estado del proyecto con las organizaciones de productores y las partes interesadas clave;
18.4. Revise la estrategia de pruebas dentro de las tareas y el flujo (manual, pruebas unitarias, automatización) si no forman parte del flujo predeterminado.
Estrategia para ofrecer más valor y maximizar los resultados después de implementar los pasos anteriores (POR determinar). 19.1. Celebrar una reunión con las principales partes interesadas (PO, CEO, otros);
19.2. Recopile y analice los requisitos que se alinean con la estrategia empresarial.

Nexus Teams

Un Nexus consta de aproximadamente de 3 a 9 Equipos de Scrum, y un Equipo de Integración de Nexus formado por 1-2 miembros de cada equipo de scrum que son responsables de planificar la visión del producto general y coordinar los Equipos.

Se recomienda formar equipos en función de la viabilidad. Los equipos de funciones tienen más sentido, ya que pueden trabajar en cualquier elemento de acumulación de productos.

Sin embargo, el flujo de trabajo actual se inclina hacia los equipos componentes, lo que puede generar dependencias más grandes entre ellos. Para reducir el riesgo, es un punto válido delegar a los equipos aquellas tareas que pertenecen a otros componentes. El proceso de intercambio de conocimientos será esencial en este caso y reducirá la falta de información al integrarse.

El equipo de Integración de Nexus (NIT) está formado por miembros de:

  • ⇒ Propietario del producto: responsable de maximizar el valor del Producto y de garantizar que el trabajo combinado completado por un Nexus se produzca al menos una vez cada Sprint.
  • ⇒ Scrum Master-responsable de que los equipos de Scrum hagan Scrum y Nexus correctamente y maximicen el valor entregado por el equipo de desarrollo. Responsable de entregar Incrementos “Hechos” de productos potencialmente liberables.
  • ⇒ Equipo de desarrollo responsable de crear Incrementos Integrados que se ‘Hacen’. NIT asegúrese de que los equipos de Scrum dentro del Nexo entiendan e implementen las prácticas necesarias para detectar dependencias, e integren con frecuencia todos los artefactos a la definición de “Hecho”.”

Rol del equipo de Integración de Nexus:

  • ⇒ El Equipo de Integración de Nexus es responsable de garantizar la definición de “Hecho”.
  • ⇒ El incremento integrado (el trabajo combinado completado por un Nexo) se produce al menos una vez cada Sprint.
  • ⇒ Los equipos de Scrum son responsables de entregar “Hecho”.
  • ⇒ El NIT proporciona un punto focal de integración para el Nexo. La integración incluye resolver cualquier restricción técnica y no técnica entre equipos que pueda impedir la capacidad de un Nexo para ofrecer un Incremento constantemente Integrado.
  • ⇒ La membresía puede variar con el tiempo dependiendo de los impedimentos que experimente el Nexo.

Los miembros del equipo tienen que producir el resultado máximo para cada Sprint. Se recomienda un chequeo de salud regular para los equipos, así como para el software. Una vez al mes, se puede realizar un cuestionario rápido para monitorear la productividad de los equipos dentro de cada equipo de Scrum.

Preguntas para los miembros del equipo:

  • ⇒ ¿Están aportando valor?
  • ⇒ ¿ El producto es fácil de lanzar?
  • ⇒ ¿Los miembros del equipo se divierten?
  • ⇒ Es el Producto saludable?
  • ⇒ ¿ Es sostenible y soportable?
  • ⇒ ¿Los miembros del equipo están aprendiendo?
  • ⇒ ¿Entienden los objetivos del producto?
  • ⇒ ¿Se sienten como peones o jugadores?
  • ⇒ ¿Sienten pertenencia?
  • ⇒ ¿ Su velocidad es adecuada?
  • ⇒ ¿Sienten que tienen un proceso adecuado?
  • ⇒ ¿Se sienten apoyados?
  • ⇒ ¿Están trabajando bien en equipo?
  • ⇒ ¿Contribuye la empresa al desarrollo de los empleados?

Comprobación de estado del equipo Nexus de DevCom

Eventos Nexus

1.Refinamiento

El refinamiento da como resultado un Backlog de productos lo suficientemente granular para que los equipos de Scrum puedan extraer el trabajo sin crear dependencias inmanejables. Durante el refinamiento, los equipos de Scrum deben centrarse en estas preguntas:

  • ⇒ ¿Qué trabajo hará cada equipo?
  • ⇒ ¿En qué orden se debe hacer ese trabajo para ofrecer el mayor valor de negocio lo antes posible, al tiempo que se minimiza el riesgo y la complejidad?

Planificación de Sprints Nexus

La planificación de Sprints Nexus consiste en:

  • ⇒ Validación de la Cartera de Productos. Los equipos de Scrum revisan los PBIs y hacen los ajustes necesarios para el trabajo del evento de Refinamiento. Todos los equipos de Scrum deben participar y contribuir a minimizar los problemas de comunicación; sin embargo, solo los representantes apropiados (aquellos que sienten que pueden hacer una contribución para refinar los PBIs) de cada uno de los equipos de Scrum deben asistir.
  • ⇒ Formulando el Objetivo Nexus. El Objetivo Nexus es un objetivo de Sprint que se cumple a través de la implementación de PBIs por varios equipos.
  • ⇒ Planificación de Sprint en equipo Scrum. Una vez que se comprenda el Objetivo de Nexus para el Sprint, cada equipo de Scrum llevará a cabo sus eventos de Planificación de Sprint individuales en los que los miembros crearán sus propios Retrasos de Sprint. A medida que identifican dependencias con otros equipos, trabajan con esos equipos para minimizar o eliminar las dependencias. La mayoría de la planificación de Sprints debe tomar 8 horas.

En algunos casos, esto significará que la secuencia de trabajo entre equipos puede tener que ajustarse para permitir que un equipo termine su trabajo antes de que comience otro.

Nexus Daily Scrum

La reunión Nexus Daily Scrum abarca las preguntas principales:

  • ⇒ ¿Se integró con éxito el trabajo del día anterior, y si no, por qué?
  • ⇒ ¿Se han identificado nuevas dependencias?
  • ⇒ ¿Qué información se debe compartir entre los equipos del Nexo?

Normalmente se celebra al mismo tiempo y en el mismo lugar.

Revisión Sprint Nexus

La revisión Sprint incluye los siguientes elementos:

  • ⇒ Entre los asistentes se incluyen los equipos de Scrum y las partes interesadas clave invitadas por el Propietario del Producto;
  • ⇒ El Propietario del Producto explica qué elementos del Backlog de productos se han ” Hecho “y qué no se han”hecho”;
  • ⇒ Los Equipos de Desarrollo discuten qué fue bien durante el Sprint, con qué problemas se encontró y cómo se resolvieron esos problemas;
  • ⇒ Los Equipos de Desarrollo demuestran el trabajo que ha “Hecho” y responden preguntas sobre el Incremento;
  • ⇒ El Propietario del Producto discute el Retraso del Producto tal como está. Proyecta fechas de entrega y objetivos probables basadas en el progreso hasta la fecha (si es necesario);
  • ⇒ Todo el grupo colabora en lo que debe hacer a continuación para que la Revisión de Sprint proporcione información valiosa para la Planificación de Sprint posterior;
  • ⇒ Revisión de cómo el mercado o el uso potencial del producto podrían haber cambiado lo que es lo más valioso para hacer a continuación;
  • ⇒ Revisión de la línea de tiempo, el presupuesto, las capacidades potenciales y el mercado para las próximas versiones anticipadas de funcionalidad o capacidad del producto.

El resultado de la Revisión de Sprint es un Backlog de Productos revisado que define los elementos probables de Backlog de productos para el siguiente Sprint. El Backlog de productos también se puede ajustar en general para satisfacer nuevas oportunidades.

Esta actividad no debe tardar más de 3 horas en completarse.

Reunión Retrospectiva de Nexus

5.1. Retrospectiva de NIT

Debido a que hay disfunciones de escala comunes, cada retrospectiva debe abordar las siguientes preguntas.

  • ⇒ ¿Han alcanzado el Objetivo del Nexo? Si no, ¿por qué no?
  • ⇒ ¿ Quedó algún trabajo sin hacer? ¿El Nexo generó deuda técnica?
  • ⇒ ¿ Todos los artefactos, en particular el código, se integraron con frecuencia (idealmente, de forma continua) y con éxito?
  • ⇒ ¿ Se construyó, probó e implementó el software con éxito con la frecuencia suficiente para evitar la acumulación abrumadora de dependencias sin resolver?

Cuando se descubren problemas, los representantes deben preguntar:

  • ⇒ ¿Por qué pasó esto?
  • ⇒ ¿Cómo se puede solucionar el problema?
  • ⇒ ¿Cómo se puede prevenir la recurrencia?

Después de la reunión retrospectiva de Nexus, es importante definir los elementos de acción en los que trabajar dentro de todos los equipos de Scrum. El NIT tiene que llevar un registro de dichos elementos y puede usar una tabla a continuación.

 Elementos de acción Nexus de DevCom

5.2. Retrospectiva de equipos de Scrum

Cada equipo de Scrum puede usar un tablero para visualizar los elementos en los que hay que trabajar. Además de eso, se recomienda llevar un registro formal de dichos registros de una manera estructurada. A lo sumo, se necesitan 4 horas para discutir con el equipo cómo fue un Sprint.

 Retrospectiva de Scrum teams

Propietario del producto

El Propietario del producto es responsable de maximizar el valor del producto.

El Propietario del Producto es la única persona responsable de administrar el Backlog del Producto. La gestión del Backlog de productos incluye:

  • ⇒ Expresar claramente los artículos del Backlog de productos;
  • ⇒ Ordenar los artículos del Backlog de Productos para lograr mejor los objetivos y las misiones;
  • ⇒ Optimizar el valor del trabajo que realiza el Equipo Nexus;
  • ⇒ Asegurarse de que el Backlog de productos sea visible, transparente y claro para todos, y mostrar en qué trabajarán los equipos de Scrum a continuación;
  • ⇒ Asegurarse de que los equipos de Scrum entiendan los elementos del Backlog de productos al nivel necesario;
  • ⇒ Definir el objetivo Nexus para cada Sprint (similar a milestone).

El Propietario del producto puede hacer el trabajo anterior o hacer que el equipo de Nexus lo haga. Sin embargo, el Propietario del Producto sigue siendo responsable.

Conclusiones clave

  1. Scaled Agile funciona, y el uso de un marco de escalado le ayuda a obtener un inicio rápido.
  2. Scaling Scrum es solo Scrum. No cambias la forma en que trabajas como un equipo de Scrum ni cambias el trabajo que se entrega.
  3. Al agregar el marco Nexus en la parte superior de Scrum, proporciona a los equipos una forma de lidiar con las dependencias entre equipos y garantizar que todos trabajen juntos hacia un objetivo común y un incremento del producto.
  4. Si conoce Scrum muy bien, el marco Nexus es el marco” obvio ” para escalar equipos de desarrollo de software, y es posible que nunca necesite nada más.
  5. Nexus es un marco de discusión útil para aquellos que ya tienen varios equipos de Scrum en su lugar que funcionan juntos.
  6. Alternativamente, si desea describir su proceso, el marco Nexus es un buen punto de partida para que no se pierda ninguna perspectiva.
  7. Como siempre, cuando se trata de escalar de forma ágil, recuerde estas tres cosas importantes:
  • ⇒ Adapte el método a su organización.
  • ⇒ Reflexione constantemente sobre la situación.
  • ⇒ Mejore la forma en que trabajan juntos.

¿Tiene más sugerencias para las técnicas “más allá del equipo”? ¿Quieres ayuda para implementar estas ideas?

Desde el año 2000, DevCom ha adaptado metodologías ágiles estándar de la industria diseñadas para crear soluciones oportunas, efectivas y eficientes para lograr los objetivos de nuestros clientes. Estas metodologías representan un modelo de desarrollo iterativo en el que el esfuerzo general se divide en múltiples versiones para lograr los objetivos trazados para una fase en particular. Ponemos mucho énfasis en tres elementos del ciclo de vida de desarrollo: Evaluación y Planificación Inicial del Proyecto, Gestión de Proyectos de Calidad y Garantía de Calidad.

Nuestro enfoque de desarrollo reduce los riesgos del proyecto y trabaja para controlar el tiempo de comercialización y el presupuesto. Compartimos esa experiencia y conocimiento con nuestros nuevos clientes para que todos puedan tener éxito a la hora de escalar.

Obtenga mejores resultados a través del trabajo en equipo: ¡Contáctenos en DevCom hoy mismo!

Deja una respuesta

Tu dirección de correo electrónico no será publicada.