Las dailys son una pérdida de tiempo

Ayer puse un twit que decía que las dailys son una pérdida de tiempo en el 99% de los casos y el 99% de las veces.

Y como grandes afirmaciones requieren de grandes justificaciones, aquí van las mías.

Se hacen mal

Y esto es uno de los principales problemas. Se hacen rematadamente mal en casi todos los sitios.

El objetivo de la daily es ver cómo está el equipo en relación con los objetivos marcados en el sprint: si se está desviando del camino, si hay bloqueos y quién puede ayudar a desbloquearlo, cambios de requisitos, algún bug que ha venido a reventar la planificación, etc. No es el lugar para decir lo que hiciste ayer, que es el foco en el que se basan una gran parte de las dailys. A los compañeros eso les da igual y al manager debería también darle igual, porque, de nuevo, lo importante no es lo que hiciste ayer sino cómo vamos en relación a los objetivos marcados en el sprint.

Tampoco es el lugar indicado para resolver nada. Ningún asunto. Ni el más pequeño. Está todo el equipo reunido, es tiempo de mucha gente y resolver un problema suele ser cuestión de un subconjunto de ellos y hace que la reunión se alargue de forma innecesaria. Si dos o tres personas tienen que resolver algo es mejor hacerlo en otro momento (que puede ser tras la daily).

La información que se irradia es redundante

Si los procesos están bien diseñados, lo normal es que un desarrollador no tenga nada que decir en una daily. Es muchísimo más claro y eficiente mostrar el progreso, los asuntos particulares y los pormenores de forma escrita en un comentario del gestor de tareas. Y si los procesos no están bien diseñados, pues mejora los procesos.

Si no tienes bloqueos y estás en tiempo y forma con tu desarrollo, no hay nada que decir. La daily fuerza una comunicación que no hace falta.

No estoy en contra de reunirse para discutir un problema o hablar de un ticket, ¡Al revés! Eso es bueno siempre y en todas las circunstancias, pero no es necesario juntar a todo el equipo para eso. Ni hace falta planificar la reunión o hacerla de forma periódica. Reuniones bajo demanda.

Ser claro y conciso es difícil

Y claro, como se fuerza la interacción (ver punto anterior), aunque un desarrollador no tenga nada que decir le toca el turno en la daily y se siente obligado a decir algo. Y se explaya. Y da rodeos y vueltas, y cuenta cosas que a nadie le interesan porque son demasiado técnicas o no son técnicas, pero no son de tu campo o son de tickets que no conoces y no tienes contexto o todo lo anterior a la vez.

Y es que ser claro y conciso es difícil. Las habilidades comunicativas hay que desarrollarlas y trabajarlas y no son el punto fuerte de todo el mundo. Y es que solo necesitas a una persona para que te reviente la daily y se pase de los 15 minutos a los 30, los 45 o incluso una hora. Y encima crea un problema añadido porque crea frustración en el resto que, además, se evade.

No se les presta atención

Y esto no es causa sino consecuencia. No se les presta atención por todo lo anterior. Porque se comunica mal (en exceso), porque se comunica lo que no es (qué hice ayer), porque se comunica información que ya se conoce… y al final la atención se dispersa. Y el problema de esta atención dispersa es que si casualmente se dice algo que tiene relevancia real, se pierde esa información en el limbo porque no se tenía la atención puesta en la reunión. Y entramos en el bucle de no prestar atención porque no tiene interés y no tiene interés porque no se pone atención. Es fácil caer ahí, lo he visto decenas de veces.

Es una reunión hecha por y para el manager

La daily existe para paliar las lagunas de información que tiene el manager. Y lo sé, porque he sido manager, y necesitaba la daily para paliar las lagunas porque no tenía tiempo suficiente para hacer mi trabajo de manager (que, entre otras cosas, era intentar conseguir que los desarrollos estuviesen en tiempo y forma). Entre otra cosa porque tenía demasiadas reuniones (la pescadilla que se muerde la cola, otra vez).

Y también me servía para sofocar el lack de comunicación que tenía con el equipo de desarrollo, que, muchas veces, comunicaba mal y de forma insuficiente. Y la daily es una solución, desde luego, por eso no he dicho que la daily sea inútil. Es útil. Para el manager. A veces. Pero a costa de invertir perder una cantidad ingente de tiempo.

Fuerzan un sincronismo innecesario

Las dailys se suelen hacer a primera hora de la mañana. Esto tiene sentido porque en teoría si tienes bloqueos mejor resaltarlos pronto para no estar todo el día parado. Pero es que esa primera hora no tiene que ser la misma para todo el mundo. Habrá personas que preferirán empezar la jornada a las 7 y otros a las 10. A veces tener una daily a las 9 o 9:30 (horas habituales) fuerzan al que prefiere entrar más tarde a adelantar su inicio, impiden a muchos progenitores a llevar a sus niños al colegio, rompen el flujo de trabajo de los que empezaron a las 7 y que ya llevan 2 horazas de producción, etc.

Y además es innecesario porque… ¿Por qué esperar a la daily? Si tienes un bloqueo, ¿Por qué no comunicarlo inmediatamente de manera asíncrona en un canal de slack/chat común diseñado para tal efecto? O directamente escribiendo a la persona que tiene la capacidad de solucionarlo si sabes quién es. Tras ello, se busca un hueco común para los implicados (que podrá ser las 9 de la maña, las 5 de la tarde o las 3 de la noche) y se resuelve si es necesario en una llamada de 2-3 personas. Esperar a la daily hace que se pierdan MUCHAS horas porque “bueno ya me espero a la daily”.

Paradógicamente, la sincronía hace que se pierda tiempo, porque se espera el hueco síncrono de todo el equipo en lugar de exclusivamente de los implicados.

Es una pérdida de tiempo tanto para equipos pequeños y para equipos grandes

Si el equipo es pequeño la comunicación debería de fluir tan rápido y de forma tan ordenada que no se necesita un protocolo diario para irradiar información. 3-4 personas, un canal de slack y llamadas bajo demanda es más que suficiente para que todo fluya. Lo sé, de nuevo, porque he trabajado en equipos siguiendo esta dinámica.

Y si el equipo es grande una daily se convierte en una reunión larga con demasiada gente hablando de cosas que no le interesan a casi ninguno de los otros presentes. Volvemos a lo mismo, a la pérdida de tiempo.

Es una pérdida de tiempo

Así que por todo lo anterior defiendo que la daily es una pérdida de tiempo. Es una mala y costosa solución a problemas que se pueden afrontar de forma más eficiente. Sin implicar a todo el equipo en una reunión de 30 a 60 minutos. Más los tiempos muertos que provoca, por supuesto.

En un equipo de ocho personas, si la daily dura 30 min de media, más otros 15 min antes y después de la misma (porque sí, una reunión planificada cuesta más tiempo del que dura la reunión), hablamos de 1h al día por persona. 8h al día por equipo. 40h semanales en total. Una verdadera pérdida de tiempo.

– Si os interesa el tema intentaré crear otro artículo con estrategias para eliminar la daily de vuestras vidas de una vez por todas.

Written on May 14, 2026