Introducción
Dentro de las metodologías ágiles, y más precisamente dentro de SCRUM encontramos una de las reuniones que más importante se torna gobernar correctamente, o en otras palabras, lograr que se respeten los principios de Time-Boxed y Short/To the point. Se trata de la Stand up o Daily meeting
Como ya se comentó en publicaciones anteriores, SCRUM podría explicarse como un framework de reuniones, en la que cada una tiene una razón de ser (objetivos) y una dinámica particular (método orientado al objetivo de la reunión).
En esta publicación se explica más en detalle los fundamentos y dinámica de la Stand up meeting.
Objetivo
El objetivo de esta reunión es que el equipo entero comparta diariamente una actualización del estado del trabajo que está realizando cada uno de sus miembros.
Dinámica
Un aspecto importante de estas reuniones es que se mantengan breves, siguiendo la filosofía SCRUM, se aplicará el concepto de Time-Boxing. Por este motivo, los asistentes permanecen de pié durante la misma (recordando que hay que ser breve e ir directo al punto). Es importante para que el Time-Boxing sea eficaz, la puntualidad de los participantes.
El facilitador (Team Leader/SCRUM Master) “abre” la reunión, y define una dirección (ej: horario/antihorario). El primer miembro del equipo plantea uno a uno (a modo de ítems) los temas sobre los que ha trabajado desde la última reunión, y aquellos con los que estará trabajando hasta la siguiente. Antes de pasar al siguiente miembro, el integrante que está hablando, debe informar cualquier inconveniente que tenga en la resolución de un problema presentado. Al hacerlo, otro participante puede/debe interrumpir solo para decir “yo puedo ayudarte con ello” (no es esta reunión el momento para debatir respecto de la solución, sino enterarse los problemas de nuestros compañeros y avisar que podemos contribuir positivamente en la resolución). El SCRUM Master debe tomar nota de estas interacciones para poder realizar un correcto seguimiento, y preguntar sobre temas no tratados (que vienen de reuniones pasadas). Al finalizar, pasa al siguiente miembro del equipo, y se repite esta lógica hasta que nadie tiene más que decir y/o finaliza el tiempo asignado a la reunión.
El escenario “ideal” es que en este momento, los miembros del equipo vuelvan a sus lugares de trabajo, y “en el camino”, aquellos que hayan interactuado ofreciendo solución, caminen mientras charlan más en detalle lo enunciado durante la reunión. Si esto ocurre, es muy probable que al llegar al escritorio, emprendan una pequeña sesión de peer programming y solucionen el problema o lo encaminen de forma inmediata.
Problemas frecuentes
Equipos expertos en SCRUM conocen los beneficios de este tipo de reuniones. Los equipos que recién se inician, suelen no reconocerlos hasta que la dinámica esta afianzada (no olvidemos que las metodologías ágiles proponen el mejoramiento continuo de los equipos en calidad de trabajo entregado, precisión de estimaciones, eficacia de las reuniones, etc). Cuando esto ocurre, los equipos suelen abandonar la práctica. Si están en esta situación: EVITEN TOMAR ESE CAMINO. Denle al equipo el tiempo de madurar la práctica (esto aplica para todo Agile).
Dentro y fuera de SCRUM/Agile
¿Es necesario implementar agile para poder realizar Stand up meetings? Esta pregunta, extrañamente formulada a propósito, intenta en realidad sentar las bases para analizar si este tipo de reuniones aportan algún valor fuera de la estructura ágil. La pregunta real debería ser: ¿Tiene sentido realizar Stand up meetings fuera de metodologías ágiles?
La respuesta es subjetiva. En mi opinión, este tipo de reuniones aportan beneficios independientemente de la metodología utilizada. No está mal comenzar a valorar las interacciones humanas incluso fuera del mundo ágil. La gran diferencia, quizás, sea la “unidad de trabajo planteada”. Mientras que con Agile nos aseguramos un trabajo orientado a tareas de cierto nivel granular tomadas de un backlog, otras metodologías podrían no garantizar la existencia de las mismas. Al mencionar sobre qué estuvimos trabajando, podríamos NO tener un objeto autónomo, cuantificable y estimable, y eso podría complicar en gran medida la dinámica descripta (podríamos tardar mucho tiempo en explicar un problema, no mencionar tareas que signifiquen algo fuera de su correcto contexto, etc) complicando de esta manera seguir el principio de Time Boxing.
El punto positivo de este escenario, es que podría conducirnos a orientar nuestro trabajo a tareas comparables (técnica utilizada pero no exclusiva de Agile), y eventualmente a implementar gradualmente más partes de estas metodologías (a pesar de lo que puedan pensar los puristas y expertos en Agile yo sigo creyendo que la metodología es implementable por partes, e incluso, es posible utilizar solo aquellas partes que nos sean útiles).
Conclusión
Hay mucho material escrito al respecto de esta (y todas las reuniones SCRUM). Decido dejar madurar un poco estas ideas y retomarlas más adelante para profundizar en temas tales como las metas detalladas, principio del buen comienzo (good start), patrones de la stand up, etc.