¿Es verdad que en Scrum hay demasiadas reuniones?: Los eventos en Scrum

Suelo escuchar, en algunos equipos Scrum, que el marco de trabajo tiene demasiadas reuniones.

En Scrum se habla de eventos, en lugar de reuniones, para diferenciar estos encuentros del equipo, con lo que tradicionalmente conocemos como reuniones.

La guía oficial de Scrum establece que el propósito de sus eventos es el de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de tiempo (time-boxes) con una duración máxima, y a excepción del Sprint que tiene una duración fija, los demás eventos pueden terminar siempre que se alcance su objetivo, asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio en el proceso.

Los eventos en Scrum son:

  • El Sprint, es el corazón de Scrum, un bloque de tiempo (time-box) entre 1 y 4 semanas, durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable. El sprint contiene el resto de los eventos.
  • El Sprint Planning o de planificación del sprint, donde el equipo Scrum alinea prioridades y acuerda los objetivos y metas del sprint. Se conforma el Sprint Backlog con las funcionalidades que se incorporarán al producto y al menos 1 acción de mejora acordada en la retrospectiva. Se puede realizar en 2 partes: Qué se va a hacer en el Sprint, liderada por el PO, y Cómo el equipo técnico abordará el desarrollo.
  • La Daily o reunión diaria, donde el equipo técnico sincroniza el trabajo y establece el plan para las 24 horas siguientes. Cada desarrollador comunica qué hizo, qué hará y qué le impide cumplir los objetivos del sprint. No es una reunión de estatus. Aquí se promueve el trabajo en equipo y el SD se lleva los impedimentos para gestionar su solución.
  • El Sprint Review o reunión de revisión de lo realizado en el sprint, para inspeccionar el Incremento del producto desarrollado durante el Sprint y adaptar el Product Backlog si fuese necesario. El Equipo Scrum y los interesados colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor, revisando y adaptando las prioridades del próximo Sprint.
  • La Retrospectiva o Retro, donde el equipo se inspecciona a sí mismo, reflexionando sobre cómo ha realizado su trabado en el último Sprint y creando un plan de mejoras para ser abordadas en el siguiente Sprint.
  • El Sprint Refinement o Refinamiento de los elementos del Backlog, para incrementar el nivel de concreción de las historias que por su prioridad se van acercando hacia el próximo sprint. Incluye la incorporación de nuevas historias, división de las más grandes, replanteamiento, detalle y estimación de historias ya definidas. Permite al Dev Team una mejor comprensión del producto.

La siguiente figura muestra cuándo se realiza cada evento dentro del ciclo de Scrum y la duración aproximada de estos eventos, según mi experiencia, con sprint de 2 semanas y equipos con cierta madurez que tienen entre 3 y 7 desarrolladores.

No hay texto alternativo para esta imagen

Los eventos Scrum están diseñados para habilitar los pilares vitales de transparencia, inspección y adaptación, así como, fomentar la comunicación y colaboración entre los miembros del equipo.

Asimismo, facilita la implementación de un modelo de desarrollo iterativo e incremental, donde el equipo Scrum, incorpora al PO y a stakeholders clave del negocio y de sistemas, con el objetivo de focalizar a los equipos en entregas de valor, potenciando el desarrollo de equipos autónomos, autogestionados y multidisciplinarios, elementos que promueven la motivación y eficiencia de los equipos.

Es normal, que al tener al equipo junto en los eventos de Scrum, se tenga la tentación de “aprovechar” y querer resolver otros temas. Adicionalmente, somos seres sociales, hay personas de naturaleza más conversadora que otras, y por lo general, no nos gusta decir No, interrumpir o poner límites.

Esto, junto a otras dificultades, ocasiona que las sesiones se alarguen, y a veces, se vuelvan incluso improductivas, generando en algunos miembros del equipo la duda sobre la utilidad de estos eventos para el equipo.

Por esta razón, se te plantean las siguientes preguntas sobre la realización de cada evento:

1.   Sprint Planning: Y si no planificamos, ¿puede el equipo articular el desarrollo de incrementos de productos, y mantener entregas de valor frecuentes y periódicas, con eficiencia y calidad técnica, sin pasar por un proceso de planificación y estimación conjunta?

2.   Daily: Eliminar estos 15 minutos diarios, ¿podrá evitar otras reuniones de sincronización, alineación, colaboración y comunicación entre los miembros del equipo?

3.   Sprint Review: ¿Cómo tener el feedback del negocio y de cómo debe ir evolucionando el producto, sin este evento? ¿Se te ocurre hacerlo de otra manera?

4.   Retrospectivas: ¿Quitamos esta reunión donde el equipo tiene la oportunidad de encontrarse, resolver sus diferencias y mejorar sus procesos e interacciones?

5.   Refinamientos: Y si no refinamos en un evento aparte, igual se necesita refinar utilizando el tiempo de otros eventos. ¿Es mejor ampliar el tiempo de otros eventos y reducir el número de eventos? ¿Qué tal el foco y propósito de cada evento?

Me gustaría mucho recibir tus reflexiones sobre estas preguntas, y con ello, ampliar y complementar perspectivas sobre este asunto.

En todo caso, lo que, sí debe ser un reto y meta de todo equipo Scrum, es lograr eventos Scrum productivos, que logren su propósito y donde se eliminen los desperdicios que suelen presentarse.

María Esther Remedios

@soy.agile.coach

Artículos recientes

Imagen principal de la noticia de tipos de Ingeniería Social

Tipos de Ingeniería Social

Phishing: Se caracteriza por buscar información personal, nombres, direcciones y números de seguridad. Utiliza links que redirigen a sitios sospechosos, con URLs que parecen legitimas y…

Ingeniería Social

La ingeniería social es un conjunto de técnicas que usan los cibercriminales para engañar a los usuarios incautos para que les envíen datos confidenciales, infecten…