El tercer elemento de Scrum son las reuniones. Como hemos dicho, Scrum se basa en la interacción entre personas, y para esto lo más eficaz sigue siendo hablar. Puede que tengas que hacerlo mediante artefactos tecnológicos, si tu equipo está distribuido, pero las reuniones son imprescindibles en esta metodología.

Algunos aspectos de las reuniones de Scrum pueden ser sorprendentes, pero tienen su lógica. Uno de ellos, fundamental, es el time boxing, es decir, una asignación previa de tiempos absolutamente inflexible. Por ningún motivo una reunión puede durar más que el tiempo que tiene asignado.

Planificación del Sprint

Un Sprint es un ciclo de desarrollo, en el que quieres terminar algunos elementos de la Pila de Producto. En la reunión de planificación del Sprint se hace precisamente eso, planificar qué tiempo se va a dedicar al Sprint y qué elementos de la pila de producto se van a obtener como resultado. Con todo ello compondremos la “pila de sprint”.

En esta reunión participan el dueño del producto, el scrum master y el equipo. El equipo es quien debe estimar qué esfuerzo va a llevar cada una de las tareas necesarias para terminar un elemento de la pila de producto, y qué miembro del equipo se va a encargar de que esté hecha.

Es importante que no haya tareas huérfanas, ni tareas que se hacen “entre todos”. Una tarea, un responsable. Aunque tenga que contar puntualmente con ayuda de otras personas, es fundamental saber quién tiene la responsabilidad de que esa tarea esté terminada a tiempo.

La estimación del esfuerzo que supone cada tarea es responsabilidad de todo el equipo, aunque en mi experiencia conviene dar más peso a la opinión de quien va a encargarse de ella.

Otro de los elementos que deben acordarse en esta reunión es la duración del sprint. En principio, los sprints deben durar entre dos y cuatro semanas. Lo recomendable es que cuanto menos experiencia tenga el equipo (en scrum y en el entorno de trabajo en general), más cortos sean los sprints, porque antes podrán detectarse y corregirse desviaciones.

Para esta reunión, como máximo, hay que dedicar ocho horas. Y eso solo si la pila de producto está definida a un nivel muy genérico y va a costar mucho descomponer un elemento en tareas. Lo ideal son 4 horas. Ojo, este tiempo tiene que estar definido antes de empezar la reunión, no vale decir “quedamos a las 10 y ya veremos cuando terminamos”.

Si estás emprendiendo en modo one-man-band, lo que debes hacer es reservar un tiempo en el que nadie te va a interrumpir (si es necesario, sal de tu sitio habitual de trabajo y apaga el móvil) y concéntrate en analizar qué tareas vas a abordar con el tiempo del que dispones.

Sprint diario

En la reunión de sprint diario, cada miembro del equipo expone tres cosas: qué hizo ayer, qué va a hacer hoy y qué obstáculos o impedimentos tiene o ha tenido. Solo pueden hablar los miembros del equipo y el scrum master, el dueño del producto puede asistir pero no tiene ni voz ni voto.

La reunión de sprint diario debe hacerse todos los días a la misma hora y en el mismo sitio. Se hace de pie, si hay un tablón físico delante del tablón para que todos puedan ver como progresan las tareas, y si no en el espacio de trabajo. Lo normal es hacerlo a primera hora de la mañana, cuando estén disponibles todos los miembros del equipo. Pero si alguno se retrasa, la reunión empieza de todos modos. No se espera a nadie.

El tiempo máximo, y esto es muy importante, es de 15 minutos. En esta reunión no se trata de dilucidar aspectos técnicos, ni de cómo debe hacerse tal o cual cosa, ni de qué cosas deberían haberse hecho o no. Se trata de ir al grano, reportar cómo progresa el proyecto y que si hay algún obstáculo que impida el progreso, el scrum master tenga la información suficiente como para eliminarlo o paliarlo.

No hay más reuniones durante un sprint. Si es preciso que dos o más miembros del equipo discutan algún problema técnico, lo pueden hacer en cualquier momento. Pero no hay reuniones formales, el dueño del producto no puede interrumpir el desarrollo para plantear nuevas necesidades ni para reorientar los esfuerzos, el scrum master no puede reasignar tareas, etc.

Si estás solo, también es buena práctica “reunirte contigo mismo” al comenzar el día, analizar qué hiciste ayer, qué vas a hacer hoy, y qué obstáculos tienes para conseguirlo.

Demo del sprint

El sprint acaba en la fecha prevista con una reunión en la que el equipo muestra el resultado obtenido. A esta reunión de demostración del sprint sí acude el dueño del producto, que debe validar si el resultado obtenido es el que estaba especificado al inicio del sprint. Pueden incluso acudir personas ajenas al proyecto, aunque en este caso no tienen voz ni voto, simplemente “se enteran” de lo que se está haciendo. Hay quien plantea la demo como una reunión “festiva”, con café o refrescos, una manera de que el equipo pueda “presumir” del resultado de su esfuerzo en las últimas semanas.

El ciclo de un sprint no se puede alargar, haya pasado lo que haya pasado en el sprint. ¿Que alguien se ha puesto enfermo? ¿que un proveedor no ha entregado a tiempo algo? ¿que problemas externos han impedido a algún miembro del equipo dedicar las horas previstas? ¿que la estimación inicial de esfuerzo pecó de optimista? Se siente. Pero no se alarga el sprint. Se reconoce el fracaso (que es de todo el equipo, no de una persona) y ya está.

En esta reunión el scrum master debe tomar nota del resultado, de si las tareas están realmente terminadas y el elemento de la pila de producto puede darse por entregado. Si no fuera así, las tareas pendientes deberían abordarse en el siguiente sprint.

En principio, la reunión de demo debería tener una duración de entre 2 y 4 horas.

Retrospectiva

Ya dijimos que uno de los aspectos esenciales de scrum es embeber en el proceso la mejora continua. En la reunión de retrospectiva el equipo, junto con el scrum master, analiza lo que ha ido mal en el sprint, lo que se puede mejorar y qué se puede hacer para mejorarlo. Aquí no es conveniente que haya personas ajenas al equipo, para que los problemas puedan ser expuestos y tratados con sinceridad y transparencia.

Esta reunión es el motivo de que nunca se retrase el cierre de un sprint. En lugar de eso, se asume que hay problemas, se identifican y se hacen públicos lo antes posible, y se les busca solución. A veces es simplemente que se pecó de optimismo al estimar el esfuerzo que requerían las tareas. A veces han sido problemas que no es probable que se repitan (una huelga, una inundación). Pero otras veces hay problemas de fondo, que deben ser resueltos para que el equipo pueda ser más productivo (falta de formación, un proveedor o un miembro del equipo que no es capaz de hacer su parte).

Para esta reunión en principio debería bastar con dos horas, salvo que se hayan detectado numerosos problemas. Lo normal es hacer las dos reuniones, la demo y la retrospectiva, en el mismo día.