Los 7 errores más comunes de la Daily Scrum, ¿cómo evitarlos?

¿Daily Meeting? ¿Standup Meeting? ¿Daily Standup? Son nombres típicos que encontramos referidos a la Daily Scrum. ¿Y si te digo que ninguno de ellos es correcto?

Aunque la Daily Scrum es el evento de Scrum más sencillo, es en el que más errores cometemos. Y si nos equivocamos con el nombre de esta reunión, ¿quién nos dice que no nos equivocamos al hacerla? ¡Hagamos productiva la Daily Scrum! Pero… ¿cómo?

¿Cuál es el objetivo real de la Daily Scrum?

Debemos tener claro que la Daily Scrum es un evento de Scrum que se realiza diariamente durante la ejecución del Sprint. Su misión principal es servir de hilo conductor entre los miembros del Development Team para que alcancen su Sprint Goal.

Recordemos que el Sprint comienza con un Sprint Planning donde obtenemos un Sprint Goal que el Development Team tratará de acometer.

Vamos a ver algunos de los mitos que giran en torno a la Daily Scrum y cómo podemos corregir estas malas prácticas.

Mito 1: Debe hacerse a primera hora de la mañana.

El mejor momento del día para hacer la Daily Scrum lo determinará el Development Team. La hora fijada debe mantenerse constante, al igual que el sitio donde se vaya a realizar, así evitaremos perder tiempo cada día decidiendo dónde llevarla a cabo.

Otra premisa es que el evento se realizará a diario, algo que parece obvio al llamarse “Daily”, pero que en muchos equipos no se cumple.

Mito 2: Tiene que hacerse de pie.

Otro mito es que la Daily Scrum tenga que hacerse de pie. Esta es una técnica que se aplica para evitar que se alargue más de 15 minutos, el tiempo máximo recomendado.

Para ello, cada Development Team tiene que autoorganizarse y es el Scrum Master el que debe enseñarles y ayudarles a conseguirlo. Buen signo de ello es que el día en el que el Scrum Master se ausenta, el evento se desarrolla con éxito y funciona.

Mito 3: La duración depende del número de personas implicadas.

Recordemos que el tiempo máximo que dura la Daily Scrum es de 15 minutos y no dependerá ni del número de participantes ni del tamaño del Sprint.

Mito 4: Cada asistente tiene que hablar como máximo 2 minutos.

Otra teoría errónea muy extendida es que cada persona que acude a la Daily debe tener 2-3 minutos para intervenir. Esta técnica es válida pero, sin embargo, no es la mejor ya que es posible que algunas personas necesiten más tiempo y el equipo considere que no todos deben hablar el mismo tiempo.

Una de las mejores opciones es tener un cronómetro presente. Así, cada participante es consciente del tiempo que ha usado para hablar.

Mito 5: Deben asistir el Scrum Master y el Product Owner.

Las personas que deben asistir a la Daily Scrum son solo los miembros del Development Team. Ellos son los responsables de que se haga bien. El Scrum Master, el Product Owner o cualquier Stakeholder podrán asistir como oyentes, pero no son necesarios para que se realice y siempre que sea útil para el Development Team.

Aunque la asistencia del Product Owner no es obligatoria, no está de más que acuda como oyente porque puede facilitar la resolución de impedimentos. Eso sí, es importante que el Product Owner no acabe usando el evento como un control sobre el Development Team.

Mito 6: Objetivo: contar qué se hizo el día anterior, qué se hace hoy y si existe algún impedimento que no permita llevar a cabo las tareas.

La Daily Scrum se ha convertido en muchos casos en una reunión de reporte donde cada participante asiste con la idea de demostrar que está trabajando. Sin embargo, el objetivo de la Daily Scrum es conocer si entre todos alcanzaremos o no el Sprint Goal.

Si no lo vamos a alcanzar tendremos que hablar con nuestro Product Owner para renegociar los ítems y que el Goal sea viable. Por eso, la función de la Daily Scrum no es responder a las preguntas sobre qué hicimos y qué vamos a hacer, sino analizar el estado de nuestro Sprint Goal.

Mito 7: Se actualiza el Sprint Burndown con las horas que se han invertido en el día anterior.

La Daily Scrum es una oportunidad de Inspección y Adaptación de nuestro Sprint Backlog, durante la cual inspeccionamos el avance realizado durante las últimas 24 horas y actualizamos nuestro Sprint Backlog de cara a alcanzar el Sprint Goal. Todo trabajo imprevisto que haya emergido deberá estar contenido en el Sprint Backlog. ¡Sin transparencia no sabremos qué estamos inspeccionando!

Otras técnicas para mejorar nuestra Daily Scrum

Hay más técnicas que podemos enseñar a nuestros Development Team:

• Por ejemplo, si tienen problemas de escucha, se puede utilizar una pelota que se vaya lanzando para evitar que las personas desconecten al poder tocarle en cualquier momento.
• Si el problema es que los miembros del equipo se interrumpen mucho, se puede utilizar un objeto tótem que indique quién puede hablar.
• Para solucionar problemas de duración, se puede utilizar un cronómetro que colocaremos en un lugar visible para que el Development Team sea consciente del tiempo que tiene disponible.

Una técnica que inventó una compañera nuestra es el “examen sorpresa”. Dado que buscamos una comprensión compartida del estado de nuestro Sprint Goal, podemos pasar un post-it a cada miembro del equipo al finalizar el evento.

En este post-it cada participante apunta el % de Sprint Goal y si creen que será cumplible al final del Sprint. Luego se ponen en común y ahí se puede ver si las percepciones del equipo están o no alineadas.

Si queremos que Scrum funcione es esencial que leamos la Guía Scrum, recibamos formación de personas cualificadas y no paremos de formarnos y aprender. Si cada evento de Scrum se adultera empezaremos a creer que Scrum no funciona cuando el problema es que realmente no lo estamos aplicando correctamente.

¡Aprendamos para mejorar! Es el mejor consejo que podemos dar.