¡Nuevo episodio de Scrum Manager Podcast! En este tercer episodio explicamos cuáles son los eventos de Scrum y por qué son tan importantes. También disponible en Spotify e iVoox.
Recordad que las transcripciones de todos los episodios estarán disponibles en el blog, e iremos subiendo a ritmo de sprint: cada par de semanas. ¡No dudéis en sugerirnos temas sobre los que os gustaría profundizar en los comentarios!
Transcripción
¡Hola y bienvenidos! En el episodio de hoy queremos contestar a una pregunta interesante: ¿son las reuniones tan esenciales para el desarrollo del proyecto o basta con sprintar?
Scrum se compone de una serie de eventos, roles y artefactos. En este episodio vamos a hablar de los eventos, que es el término en el que agrupamos todo lo que tiene una cierta duración en el tiempo. En resumen, los eventos de scrum son el famoso sprint y las reuniones que giran en torno al sprint. Cuando se completan todos los eventos de principio a fin se dice que se ha realizado un ciclo, o una iteración.
¿Qué son los eventos de scrum?
Las reuniones típicas de scrum son cuatro, cada una con una función marcada: la reunión de planificación del sprint, el scrum diario, la revisión del sprint y la retrospectiva. El scrum diario se hace cada mañana, mientras que las demás reuniones se hacen una vez por ciclo.
La palabra sprint, como scrum, viene del mundo del deporte. Y es una metáfora muy apta. No son carreras de fondo, sino que persiguen una meta durante un periodo breve e intenso.
El tiempo que debería durar el sprint dependerá de las circunstancias. Hay quien opina que los sprints deberían ser muy cortos, pero también se hacen de un mes. En realidad, pueden variar en duración, incluso dentro del mismo proyecto. Depende de cuál sea el objetivo de la iteración. Si tenemos que presentar una nueva funcionalidad en un evento dentro de dos semanas, aunque el equipo suela trabajar en sprints de 3, habrá que adaptarse. Lo que hay que entender es que sirven para compartimentar el desarrollo en pequeños hitos. Es una técnica para gestionar avance continuo. Tienen que ser lo bastante breves como para darnos cuenta, con regularidad, de si estamos avanzando en la dirección correcta y de si necesitamos hacer cambios.
Vamos a ver el resto de eventos de scrum en orden cronológico:
- La primera reunión antes de cada sprint es la de planificación. Es la reunión en la que se decide cuál va a ser el objetivo del sprint. Se analizan las epics más prioritarias del backlog y se descomponen y estiman las más urgentes en historias, para pasarlas a la pila del sprint. Es importante en este paso evitar la sobrecarga de trabajo y elegir historias que aporten valor.
- Durante el desarrollo, cada mañana, se hace un scrum diario. También se le suele llamar stand-up meeting. Y con esos dos nombres ya nos hacemos una idea de qué es y cómo funciona. Se recomienda hacerla de pie para no perder tiempo, porque lo ideal es que dure muy poco.
- Las últimas reuniones a veces se confunden, pero conviene que las tengamos muy claras y las diferenciemos: son la reunión de revisión del sprint y la retrospectiva. Tienen en común que ambas se hacen al terminar el sprint y que sirven como un momento de aprendizaje con el que mejorar en el siguiente ciclo. Pero lo hacen desde dos ángulos distintos:
- La revisión del sprint se centra en analizar lo que hemos construido. El qué. A este «qué» se le suele llamar incremento. Es una parte terminada, testeada y usable del producto que se completa durante un sprint.
- La retrospectiva, en cambio, se centra en cómo lo hemos construido, en la manera de trabajar del equipo.
Antes de pasar a la práctica, vamos a repasar. Todos estos elementos dependen unos de otros y forman parte del ciclo de vida de scrum. El ciclo completo, desde el inicio del proyecto, consiste en:
Primero, elaborar el product backlog con historias de usuario priorizadas y ordenadas. Y después empezar a desarrollar en iteraciones cortas y frecuentes. Se planifica un sprint, se realizan scrum diarios para gestionar el avance, y cuando se termina se revisa el incremento y, por último, hacer una retrospectiva. Y repetimos. Con lo aprendido, volvemos a empezar con una nueva reunión de planificación de sprint.
De la teoría a la práctica
A simple vista pueden parecer demasiadas reuniones. ¿Por qué hay tantas? ¿No sería más eficiente mandar la información por correo, por ejemplo? ¿O un documento de requisitos? ¿Por qué usamos eventos en agilidad?
Esto viene ya del Manifiesto Ágil, que dice «preferimos la colaboración con el cliente a la negociación contractual.» Y que «la conversación cara a cara es el método más eficiente y efectivo de comunicar información al equipo y entre sus miembros.»
¿Por qué las conversaciones cara a cara son más eficientes y efectivas? En primer lugar, porque en la documentación escrita se pierde riqueza de comunicación: gestos, expresiones, retroinformación para saber si te están entendiendo, o incluso si alguien está teniendo un mal día y no está receptivo.
A esta falta de riqueza de comunicación se suma otro problema: no todo el mundo tiene la misma capacidad de expresión escrita ni de comprensión lectora. Las reuniones sirven para asegurarnos de que todos estamos entendiendo lo mismo, para plantear dudas y dar aclaraciones si son necesarias. Y en este choque de perspectivas las ideas además evolucionan, se concretan más y mejoran gracias a la inteligencia colectiva.
También hay evidencia científica que respalda la efectividad de las conversaciones cara a cara. Sobre todo después de la pandemia, se han hecho estudios comparando las respuestas fisiológicas y emocionales ante reuniones virtuales y físicas: cómo conectamos, cómo responde nuestro cerebro, nuestras hormonas… Parece ser que la presencia física es importante sobre todo para que las reuniones tengan el beneficio añadido de aumentar la confianza y fortalecer los vínculos personales entre los miembros del equipo. Aunque las virtuales también son útiles y preferibles a la documentación escrita.
Además, dividir el tiempo en sprints y reuniones con objetivos claros compartimenta el trabajo y nos ayuda a mantener el foco. Compartimentar cuando nos enfrentamos a objetivos complejos es natural y ayuda a nuestro cerebro. Evita que caigamos en hacer multitasking, ayuda a la memoria y a procesar información.
Cuando el trabajo es individual, las pausas que hacemos para recapacitar pueden ser más breves, pero al trabajar en equipo se necesita coordinación. Y para eso, el equipo debe reunirse y comunicarse.
Ahora bien, las reuniones mal llevadas pueden desmotivar. Para asegurarnos de que sean productivas, tenemos que entender y recordar cuál es su propósito.
Empecemos por el principio: ¿cómo sé si estoy haciendo bien una reunión de planificación de sprint?
Todas las reuniones son importantes, pero si no contamos con una estrategia inicial, el resto no tiene sentido. Si la reunión de planificación no está bien hecha, es probable que luego nos arrepintamos.
El propósito de esta reunión es crear la pila del sprint. Para ello, descomponemos las historias centrándonos primero en las que aporten valor tanto al usuario final del cliente como a su negocio. Después, elegiremos entre éstas las que consideremos más urgentes o con mayor impacto. Al descomponerlas y estimarlas veremos cuántas es viable incluir en el sprint.
Esto no nos protege por completo de equivocarnos. Puede que el incremento no se use tanto como nos gustaría al final, o que hayamos estimado mal. Pero reflexionando y haciéndonos estas preguntas antes de empezar, al menos tendremos una pila de sprint que creemos valiosa, algo que vale la pena intentar. Porque durante el proceso confirmamos que todos entendemos la finalidad del sprint, y que está alineada con el proyecto.
La mejor forma de desarrollar esta reunión es con la colaboración de todo el equipo. Además, esta reunión sirve para reubicarnos. Porque si no es el primer sprint, eso quiere decir que ya hemos aprendido cosas del anterior. Y ese feedback, el de la revisión y la retrospectiva que hemos hecho hace nada, nos va a ayudar a intuir cuál debería ser nuestro siguiente paso.
Pero una vez en el desarrollo, ¿qué pasa si no hemos estimado bien? ¿Qué hacemos si no se llega a completar el incremento en el sprint?
Es una muy buena pregunta. Seamos sinceros, los imprevistos son inevitables. Pero una comunicación fluida ayuda a resolverlos con antelación y facilidad. Y a controlar que no hagan efecto mariposa, se acumulen y nos generen problemas mucho mayores después.
Para eso está el Scrum diario. Esos 10-15 minutos al empezar cada mañana nos ayudan a visualizar qué tal va el incremento. Es más difícil que algo pase desapercibido y que nos demos cuenta, al final, de que no vamos a llegar a tiempo. Puede pasar, pero al menos lo sabremos con antelación. Se puede avisar antes al cliente, manejar expectativas y buscar soluciones bajo una presión mucho menor.
Ahora que hemos terminado un sprint, se supone que debemos hacer una revisión de sprint y una retrospectiva.
Pero parecen muy similares, ¿con hacer sólo una de las dos, la revisión o la retrospectiva, no sería suficiente?
Ambas se hacen al terminar el sprint y sirven para tener un tiempo de reflexión. Son un momento de aprendizaje con los que mejorar en el siguiente ciclo. Pero lo hacen desde puntos de vista distintos.
La revisión del sprint se centra en el incremento, en el qué. En esta reunión presentamos al cliente nuestro trabajo. Nos ayuda a conocer su opinión y, con ese feedback necesario, podemos continuar en el siguiente sprint. Porque, sin la participación del cliente, estaríamos iterando a ciegas.
Por otro lado, la retrospectiva tiene que ver con el cómo. En ellas el equipo discute sobre qué ha funcionado y qué no durante el sprint; para plantear mejoras. A nivel técnico y social. En estas reuniones se analizan las dinámicas de grupo y los conflictos dentro del equipo que hayan podido afectar al desarrollo. Es el momento en el que reconocer tanto lo que ha salido bien como las oportunidades de mejora.
Y ya está, ¿no?
Espera, espera…. ¿y el backlog?
En el episodio anterior insistimos en revisarlo, actualizarlo y mantenerlo, pero ahora no lo hemos nombrado en ningún momento. Inadmisible.
Efectivamente, toca hablar de lo que se llama refinamiento del backlog. Nos lo hemos dejado porque no se suele incluir en el ciclo «técnico» de scrum, pero es otra reunión que muchos consideran importante y que se puede institucionalizar. La realizan el product owner y el equipo para revisar, actualizar y mantener la pila del producto. Sirve para introducir historias de usuario nuevas y estimarlas con el feedback del equipo y del product owner.
No tiene por qué ser una única reunión, de hecho, se recomienda atender al backlog de forma frecuente. Por tanto, pueden ser reuniones periódicas (por ejemplo, una por iteración). Su duración depende del número de historias nuevas, pero normalmente no debería durar más de una hora.
Pero, ¿en qué consisten? y ¿cuándo se hacen?
Este proceso de refinamiento no tiene por qué ser una única reunión. Se recomienda atender al backlog de forma frecuente. Pero pueden ser reuniones periódicas, como las otras. Por ejemplo, se puede hacer una por iteración. Su duración depende del número de historias nuevas, pero normalmente no debería durar más de una hora.
El product owner explica cada historia en orden de importancia según su visión. El equipo debe entender para qué quiere el product owner cada historia de usuario. Después se estima cada una atendiendo a su complejidad, esfuerzo requerido e incertidumbres. En este momento se distingue también entre defectos (o bugs) y funcionalidades nuevas.
Respecto a cuándo encajarlas dentro del ciclo de scrum, como no forman parte del marco típico lo cierto es que no hay un consenso. Si las queremos institucionalizar en nuestro proyecto o empresa, podemos probar hasta dar con lo que mejor encaje. Hay quien las hace al principio del sprint, antes de la reunión de planificación. Con el feedback del incremento anterior y para preparar el terreno antes de la estrategia del sprint. Pero tampoco es que haya un momento óptimo, y en realidad el refinamiento del backlog es un proceso continuo. El product owner puede trabajar en él en cualquier momento, dentro o fuera de una reunión, y el equipo también es bienvenido y puede opinar cuando lo considere oportuno.
Resueltas todas las dudas, solo nos queda recordar que todos los eventos de scrum dependen unos de otros y todos giran en torno al sprint. Ayudan a compartimentar el trabajo y la visión del proyecto. Nos permiten procesar información, comunicarnos, colaborar y mantener un ritmo sostenible de trabajo.
Volveremos con el próximo episodio en lo que se tarda en hacer un sprint: un par de semanas. Hasta entonces podéis encontrarnos en Twitter, LinkedIn, y en scrummanager.com.
¡Mucha suerte con vuestros proyectos y hasta la próxima!