Qué hace que una daily funcione

5
(1)

“¿Cómo podemos trabajar juntos para lograr que esto suceda?”

María Morales

 

Si trabajáis con metodologías ágiles, sabréis que la daily Scrum es una reunión oficial de Srcum, digo reunión, pero reunión suena a una de estas interminables y no, las dailies no duran más de 15 minutos.

El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros

¿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 les importan a dos personas, y todos los demás mirando deseando que acaben y las piernas temblando.

He visto equipos que estaban invirtiendo hasta 45 minutos en su “daily” e incluso una hora… Era un mal rato para todos.

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 focalizándose 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?
003_Daily blue
Daily Scrum

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). Ya escribiré un post sobre el Burn Down Chart dentro de poco, ya que hay quien piensa que si es una buena práctica y otros que no aportan valor, y veremos diferentes situaciones de unas y otras.

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…No obstante, también he trabajado, y trabajo con equipos distribuidos y usamos el tablero digital, como Jira, Redmine, etc., y es igual de válido y aporta el igual valor.

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.

Beneficios

  • Aumenta la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto:
    • Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o porque hay dependencias (especialmente si existe un retraso).
    • Los impedimentos con que se encuentra. La reunión de sincronización permite identificar más problemas a tiempo. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realización de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargará de solucionar los impedimentos que el equipo no puede solucionar por sí solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.
    • Cuáles son sus necesidades. Cada miembro entiende las necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el máximo valor y no realizar tareas que no proporcionan ningún beneficio al resto del equipo.
    • Cuál es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo está realizando tareas por debajo del rendimiento esperado. Se evita que una persona señale con el dedo a otra, dado que la reunión de sincronización pone a todos los miembros del equipo en la misma situación de tener que explicar en qué tareas están trabajando.
    • Cuáles son los criterios que está utilizando para realizar sus tareas, de manera que estén alineados con los objetivoscomunes del equipo.
  • Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo trabajan los otros según sus especialidades y experiencias.
  • Conocer el estado del Sprint, ver si es posible completar los requisitos a que se comprometió el equipo, en vista de las desviaciones y de las tareas pendientes

Terminando…

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 cómo 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 técnicas innovadoras y locas sin preguntaros: “¿esta técnica ayuda a cumplir el objetivo de este evento?”.

¡Feliz miércoles!

 

¿Cómo de útil ha sido esta publicación?

¡Haz clic en una estrella para calificarla!

Puntuación media 5 / 5. Recuento de votos: 1

No hay votos hasta ahora! Sé el primero en calificar esta publicación.

Cómo encontraste de útil esta publicación...

¡Sígueme en las redes sociales!

¡Lamento que esta publicación no te haya sido útil!

¡Permíteme mejorar esta publicación!

¿Cuéntame cómo puedo mejorar esta publicación?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.