¿Qué hace que una daily Scrum funcione, o que sea una pérdida de tiempo?

Uno de los primeros síntomas que me encuentro en personas que ya vienen de practicar un “Zombie Scrum” o un “cool waterfall” (algo que conserva la nomenclatura de Scrum, pero no se parece en nada), es la cara que ponen cuando se les habla de “la daily”. Un rasgo entre el hastío, asco, desesperación… y no les culpo, la verdad. 

Scrum es un marco de trabajo que funciona cuando lo ejecutas al completo. Si un equipo se conforma con cambiar los nombres de los roles pero nada más, y en realizar los eventos sin buscar el objetivo que realmente tienen, todo carece de sentido y nos vemos abocados a la pérdida de tiempo.

¿Qué NO es una Daily Scrum?

Una Daily Scrum no es una reunión de reporte o de control. Por mucho que algunos se encabezonen. No es una reunión donde cuento todo lo que hice ayer, o todo lo que voy a hacer hoy. Evidentemente, si alguien cuenta como estuvo ayudando a otro equipo, o que estaba haciendo papeleo en el departamento de recursos humanos, o que tuvo que ir al banco, todos tenemos la sensación de estar perdiendo el tiempo.

Tampoco es una reunión para hablar sobre un tema que solo le importan a dos personas, y todos los demás mirando deseando que acaben y las piernas temblando. Porque claro… la Daily Scrum debe ser de pie… ¿no? (veremos que no hay por qué) He visto equipos que estaban invirtiendo hasta 45 minutos en su “daily”. Era un mal rato para todos.

Además, os voy a contar un secreto: todo el mundo sabe mentir y exagerar su trabajo para parecer que ha estado trabajando mucho. Si se convierte en una reunión de reporte a un jefe de equipo encubierta, al que ellos llaman erróneamente Scrum Master, todas las personas pondrán más interés en hablar lo máximo posible, para aparentar todo lo que trabajan y cuando más aburra a todos, mejor.

 

¿Qué SÍ es una Daily Scrum?

Para explicar qué es una Daily Scrum, debemos  englobarla dentro del marco de trabajo. Como ya hemos dicho, es un marco donde todo tiene un sentido si lo ejecutas al completo. Y no perdamos de vista nunca los pilares: “Inspección, adaptación y transparencia“.

Un equipo Scrum sano ha realizado un Sprint Planning, donde el resultado es un plan para conseguir un objetivo. Generalmente, este plan está plasmado como un conjunto de historias de usuario, tareas, subtareas, etc…

El equipo de desarrollo tiene un deber, auto-organizarse y auto-gestionarse para completar ese plan lo mejor posible  y alcanzar el objetivo. Como equipo de desarrollo… ¿Cómo podemos coordinarnos de cara a alcanzar ese objetivo? ¿Cómo podremos saber si vamos bien, mal? ¿Cómo inspeccionamos y adaptamos el plan? ¡Exacto! Con la Daily Scrum. Es una reunión donde inspeccionamos el avance del equipo hacía el objetivo, dónde debemos obtener un plan para las siguientes 24h y , si es necesario, adaptaremos el plan. Todo esto en un tiempo máximo de 15 minutos.

Para poder conseguir este proceso los equipos utilizan diferentes técnicas pero siempre focalizandose en la consecución del objetivo del Sprint. La forma más común es respondiendo a las preguntas, y ojo a la coletilla final de cada una:

  • ¿Qué hice ayer para alcanzar el objetivo del sprint?
  • ¿Qué voy a hacer hoy para alcanzar el objetivo del sprint?
  • ¿Qué impedimentos me he encontrado para alcanzar el objetivo del sprint?

[Estas preguntas eran obligatorias antes de la edición de la Guía Scrum de 2017. Gracias @BenjaGarrido por el comentario]

No nos importa si ayer estuviste en otro proyecto, no nos importa si estuviste en el banco. Si no hiciste ayer nada para alcanzar el objetivo de Sprint, tu respuesta a la primera pregunta debe ser : “nada”. Esto, además, nos ayuda con la transparencia. Si alguien del equipo no ha hecho nada para alcanzar el objetivo deberíamos hablar (no en la Daily Scrum, si no a continuación) por qué está pasando esto. Y deberíamos pensar si aún estamos en estado de alcanzar el objetivo con el plan que hicimos, o si hay cambiarlo, o hablar con el Product Owner sobre prioridades.

El output debe ser un plan para las siguientes 24 horas. Y yo añado, una noción de si el plan aún sigue siendo viable. Cuando estoy empezando con equipos nuevos, de vez en cuando, le pregunto ¿creéis que vas a conseguirlo? Y se quedan pensando… “pues no sé, la verdad…” Para tomar decisiones correctas, como el plan de las siguientes 24h, debemos  tener los máximos datos posibles.

 

Buenas prácticas

Estar de pie: Lo dejo como buena práctica, siempre que se entienda el por qué. Scrum no dice en ninguna parte que postura debes tener para realizar la Daily. Scrum solo nos dice cuál es el objetivo del evento, y que tiene un timebox. Está muy extendida esta práctica ya que ayuda a recordar que no debes alargarte en tu exposición y respetar el timebox. Pero un equipo maduro en Scrum, que entiende el objetivo de la reunión, puede estar tumbado o bailando la macarena, que realizarán una buena Daily Scrum.

Lugar y hora establecido: Scrum SI nos dice que debemos establecer un lugar y una hora. De esta manera reducimos complejidad. Nos olvidamos de “¿os viene bien ahora? Es que aún no está Antonio, es que ahora no puedo, es que , es que…”.

Burn Down Chart: Para poder hacer el plan de las siguientes 24 horas es importante entender la situación completa del sprint. El burn down chart nos permite saber cuánto trabajo nos queda por realizar y que tendencia llevamos (pulsa aquí si quieres que Jeff te lo explique). Escribiremos un post sobre el Burn Down Chart dentro de poco.

Tablón físico: En mi experiencia, para que un equipo tenga la foto del sprint claro y el plan de las siguientes 24 horas establecido, es mucho más fácil con un tablón físico dónde poder tocar las tareas, asignar, cambiar de estado, etc…

Token: Muchos equipos deciden tener un token para el que habla y así respetar el turno de palabra. Una pelota, un peluche, o cualquier objeto. Sólo el que lo tiene puede hablar. Además, se lo suelen pasar aleatoriamente para que nadie se empane durante la Daily Scrum. Si el equipo lo decide, funciona bien. Si se lo imponen, como siempre, carece de sentido y acaban odiándolo.

Product Owner de oyente: La transparencia, como pilar, siempre nos va a ayudar a que el proceso Scrum se realice con más eficacia. Si el Product Owner acude a la daily no nos va a ayudar para realizar un buen evento, pero sí para que entienda lo que acontece durante el sprint.

Prácticas peligrosas

Putear al equipo. Perdonad el lenguaje, pero no sé muy bien como expresarlo. Aquí dejo una foto de un equipo haciendo una daily scrum haciendo la plancha. Si el equipo ha decidido que así realizan mejor daily, lo respeto.

Pero a mi, personalmente, me cuesta trabajo creer que están poniendo atención a la situación del sprint, y pensando un plan de 24 horas para alcanzar el objetivo. Hay que tener cuidado con usar las tácticas del agilismo para parecer cool, diferente, innovador… y olvidarse de cumplir con el marco. Quizás este Scrum Master quiera ponerse la medalla de “mira que cortas hacemos ahora la Daily Scrum”. Pero se trata de generar un evento de valor, y de cumplir un objetivo de inspección clave dentro del marco de trabajo. También he visto empresas que salían a la nieve con manga corta… Creo que el mensaje que se le lanza al equipo de desarrollo es: “como no me fío de vosotros, os puteo para que lo hagáis rápido” . Cuando un buen Scrum Master debe explicar el valor de los eventos para que se entiendan y se lleguen a realizar correctamente, respetando las decisiones del equipo, pero sin necesitar de tratarlos como a niños chicos.

El product owner metijón. Igual que un Product Owner de oyente para entender qué ocurre durante un sprint es buena práctica, un Product Owner esperando un reporte o diciéndole a los miembros del equipo qué y cómo hacer todo, va a reventar el sprint, dinamitar la auto-gestión y la auto-organización, y seguramente mermar el ánimo del equipo de desarrollo.

 

Conclusión

No ha habido aún equipo que cuando empieza a realizar correctamente Scrum, y a entender el marco, no diga que el evento diario es fundamental, y que no saben como trabajaban antes. Es el propio equipo el que demandará más herramientas como el burn down chart para poder tener más transparencia y perspectiva de todo el sprint. No os abandonéis a tecnicas innovadoras y locas sin preguntaros : “¿esta técnica ayuda a cumplir el objetivo de este evento?”. Y por favor, no puteéis a vuestros equipos de desarrollo por gusto.

 

¿Quieres saber más sobre Agile?

Puedes suscribirte en el siguiente cuadro, o seguirme en twitter pulsando aquí  🙂


 

9 Responses
  1. Tengo una duda Nacho: Si alguien de forma reiterada se pasa de tiempo ¿Qué podemos hacer para corregir este problema sin que genere otro problema? Es decir ¿Cómo podríamos proceder?

    1. Nacho Navarro

      Si la Daily Scrum no está funcionando correctamente, por timebox, funcionalidad, etc… en la Retrospectiva debe salir el tema y buscar una solución.

      Esta solución varía dependiendo del equipo: Como ha dicho Juan Carlos, hay equipos que recurren al control temporal hasta que el equipo aprender a gestionar su tiempo. Hay equipos que le dan a un miembro el papel de moderador para que esté atento a cortar y recordar que las conversaciones específicas se tienen fuera de la daily. La ayuda visual de tener las preguntas apuntadas en el tablón físico, también ayuda.

      Lo importante, si no está funcionando, que salga en la Retrospectiva y se busque una solución 🙂

  2. Hola Luis, a nosotros nos funcionó muy bien al principio colocar un temporizador en el móvil con 1 minuto para cada uno. Antes de esto todos nos pasábamos de tiempo y divagábamos, tras hacer esto 1 semana ya cogimos el ritmo de ser bastante concisos, claros y directos, con lo que ya no volvimos a necesitar el cronómetro más.

    Un saludo

  3. Lo primero de todo, gracias! He encontrado por total casualidad vuestra web mientras buscaba información para una charla que estoy preparando 🙂

    Ahora un apunte para que la información del post esté actualizada 😉

    Con la última actualización (posterior a la escritura del post) de la Scrum Guide en Noviembre de este año (2017) vemos en el apartado correspondiente a la Daily Scrum un detalle importante, y es que las 3 preguntas han pasado a ser una orientación y no una “obligación” en la Daily.

    Seguimos en contacto 😛

  4. Naim Raja Díaz

    Me encanta el punto de vista tan realista! Gran artículo que invita a la reflexión, y escrito de una forma muy amena y sencilla.

    Espero que les sirva de inspiración a mis equipos, a mi desde luego me ha llegado 😉

Leave a Reply