Algo más sobre las Daily Meetings

Para ponerte en antecedentes consulta el artículo previo: Las Daily Meetings.

Si repasamos la teoría, veremos que en las Dailies cada miembro del equipo debe comentar principalmente 3 aspectos: "Qué hice ayer", "Qué haré hoy" y "Qué me está bloqueando". Estos comentarios acostumbran a dar pie a otros tantos también muy útiles, como por ejemplo:

• Ep, sospecho que esto que estoy haciendo podría afectar a lo que estás haciendo tú, mejor te lo explico luego y nos ponemos de acuerdo.
• Ep, deberíamos crear estas tareas con las que no contábamos, lo hacemos luego, ok?
• Ep, creo que esta tarea con la que estoy necesita una explicación por mi parte u os va a costar entenderlo.
• Ep, mi Pull Request lleva un día muerta de risa... por el amor de Dios Bendito! que alguien le eche un vistazo!
• Ep, necesito ayuda con este tema, no consigo sacarlo. Invoco al todopoderoso Pair Programming, o en su defecto a alguien con quién comentar el problema por si puede darle otro enfoque.
• Ep, me he encontrado con este detalle que no está bien definido. Toca hablar con el Product Owner y aclararlo.

Además, hay una serie de situaciones que, si se diesen, conviene corregir:

• Varios miembros se enzarzan en cuestiones técnicas que requieren tiempo de estudio, sin darse cuenta de que será muy difícil encontrar una solución en el tiempo disponible.

• Un miembro del equipo es poco conciso y se extiende demasiado:

  Esta tarea empezó cuando Anaximandro le hizo una Pull Request a Diplodocus, este puso huevos, y entonces...

• Secuestro inconsciente de la reunión para comentar temas que no están directamente relacionados con las tareas del sprint.

• Un miembro del equipo muestra dificultades para comunicarse:

  Uhm.. a ver, no recuerdo lo que hice ayer. Hoy creo que haré esa de ahí.. ehhh... Siguiente!

• Falta de acuerdo respecto a como se plantean problemas o soluciones complejas:

  Según la escuela Aristotélica del Software, el principio que aplicas en tu patrón genera problemas en la tercera capa y esto impide refactorizar ...

Es aquí donde en nuestro caso el Scrum Master actúa como moderador, por ejemplo recordando que se está excediendo el tiempo, o redirigiendo el cauce de los comentarios, incluso emplazando a tratar ese tipo de cuestiones más tarde en una reunión monográfica. Considero normal que cuando un equipo añade las Dailies a su día a día por primera vez se den algunas de estas situaciones. Educarse en las Dailies no es cosa de un día ni de dos, y es principalmente reto del Scrum Master recordar a los participantes las reglas de este tipo de reuniones. En cualquier caso no hay que perder de vista tampoco que el Scrum Master no es un ser omnipotente, plantear correctamente una Daily es un compromiso de todo el equipo, por lo que cada uno de los miembros es responsable de asimilar sus reglas y sacar lo mejor de sí mismo durante su turno de palabra.

Antes de acabar, un par de detalles que suelen generar preguntas:

1. En las Dailies nosotros NO actualizamos las estimaciones de las Historias de Usuario.

2. La reunión tiene lugar aunque alguno de los miembros no pueda venir. Sólo nos las saltamos de manera puntual y en situaciones concretas.

En resumen, en nuestro caso las Dailies funcionan, y os las recomiendo sobretodo cuando tratéis con equipos medianos o grandes. Obviamente no todos los días son igual de productivas ni duran exactamente 15 minutos, siempre hay aspectos que mejorar, pero aun así el cómputo global es claramente positivo.