¿Los timeboxes de 15 minutos de Daily-Scrum son el resultado de alguna investigación pública?

Durante años he estado aplicando los timeboxes de Scrum sugeridos con buenos resultados. Ahora es mi momento de aconsejar a otros que intentan aplicarlo. Mi consejo es seguir los timeboxes porque, de lo contrario, no tendremos tiempo suficiente para completar el trabajo de buena manera. No solo porque estás tomando tiempo prestado, sino también porque probablemente estés hablando de demasiado trabajo por día.

Mis compañeros parecen receptivos a este consejo, pero al día siguiente suelen extenderlo de nuevo... lo mismo para cada reunión que tenemos.

Me gustaría mostrarles una mejor evidencia.

En mi experiencia, si un Daily toma 45 minutos, no puedes esperar que termines el trabajo de ese día y tendrás que hablar sobre los mismos temas al día siguiente, empeorando aún más a medida que avanza la fecha. Pero esto es solo mi observación.

Alguien debería haber estado estudiando este tema antes para señalar que 15 minutos (o menos) serán adecuados para un día. Quiero decir, no fue solo un capricho de los "fundadores" de Agile... ¿o sí?

"si un diario toma 45 minutos, no puede esperar que termine el trabajo de ese día" - entonces probablemente no debería comprometerse a hacer tanto trabajo ese día, si no puede lograr tanto.
No nos estamos comprometiendo. Esto hace que vuelva a ocurrir la misma reunión de 45 minutos. Por eso quiero dar una razón bien fundada que simplemente "no terminaremos"

Respuestas (2)

Sutherland decidió que la reunión durara como máximo 15 minutos. En sus propias palabras :

[...] la reunión no podía durar más de quince minutos. Queríamos que fuera nítido, directo y al grano. Si algo requería más discusión, lo apuntábamos y nos reuníamos más después de la reunión diaria. La idea era obtener la información más procesable y valiosa en el menor tiempo posible.

La idea es que el diario (el standup también reduce la duración) debe ser un punto corto de sincronización entre el equipo solo para detectar cosas que alguien del equipo podría haber pasado por alto, un equipo que necesita comunicarse y sincronizarse constantemente de todos modos, no esperar a una reunión diaria para hacerlo.

La planificación debe hacerse en la planificación del sprint. Si el diario tiene una duración de 45 minutos, lo más probable es que haya mucha planificación allí, o discusión sobre cosas que deberían haberse aclarado también durante la planificación, y previamente durante las reuniones de refinamiento.

No importa si el diario tiene un máximo de 15 minutos o lo que sea, es más importante ver la imagen completa y tratar de averiguar qué está pasando. El problema está en otro lado y lleva a que una reunión diseñada para ser corta ocupe más tiempo.

Súper respuesta. +1.
Estoy totalmente de acuerdo con el punto de vista de Sutherland. Sin embargo, parece una declaración autorizada más que el producto de alguna evidencia empírica o la conclusión de algún análisis. ¡Interesante!

El razonamiento detrás del límite de 15 minutos en las reuniones diarias de scrum es, como señala Bogdan , que nunca debería necesitar más que eso para lograr el propósito de la reunión, que es solo una "sincronización" diaria para mantener a todos actualizados sobre quién. está trabajando en qué y verifique si alguien necesita coordinarse con alguien más en alguno de los detalles de lo que están haciendo. (En mi experiencia, exceder los diez minutos debería ser una gran señal de advertencia; mis reuniones diarias de sincronización casi nunca toman más de cinco minutos).

Si bien exceder el límite de tiempo es una excelente heurística para decirle que las cosas van mal en una reunión, no he encontrado que tratar de enfocarse en el límite de tiempo funcione bien cuando se trata de solucionar el problema. En lugar de eso, sugiero que se concentre en el propósito de la reunión, especialmente en convencer a las personas para que reduzcan ese propósito, y trate de ayudar al grupo a programar las cosas que se deben hacer fuera de la reunión. Para reuniones más largas, una agenda funciona bien para esto, pero para las más cortas, como las reuniones sincronizadas, obtuve los mejores resultados al considerar, para cada punto que inicia una discusión, si todos los presentes deben discutirlo o si las personas que necesitan tener esa discusión puede continuar y hacerlo por su cuenta después de la reunión.

Para las reuniones de sincronización en particular, generalmente recorremos el grupo con cada persona dando una oración o dos diciendo en qué están trabajando y dónde anticipan cambios importantes en el código que podrían afectar a otros, respondiendo preguntas breves y luego co - Coordinar con otros para decir "aquí está con quién hablaré más tarde para tener una discusión más detallada", si es necesario.

Estoy de acuerdo con todo el razonamiento, sin embargo, 20 minutos podrían ser buenos como 10 por las mismas razones. Probablemente podamos sospechar que 4 horas es mucho para sincronizar, pero... una vez que nos damos cuenta de que necesitamos un tiempo para sincronizar todos los días, todavía tenemos que encontrar cuál es la cantidad de tiempo correcta
@zameb Diez minutos no es un tiempo de "esto está bien": diez minutos es el tiempo de "es casi seguro que tiene un problema si golpea esto regularmente". Tenga en cuenta que esta es una reunión diaria : veinte minutos por, digamos, doce personas son cuatro personas-hora por día. Use las reuniones sincronizadas solo para organizar reuniones posteriores, en lugar de ocupar todo el tiempo en discusiones que solo puede tener una parte del equipo.
Estoy absolutamente de acuerdo. Pero, ¿por qué exactamente ese número?
@zameb ¿Por qué diez minutos exactamente? Es solo un número redondo que es mucho más largo de lo que normalmente debería ser la reunión, pero aún así no es una gran cantidad de tiempo (alrededor de dos horas-persona para una reunión con una docena de personas). Ocho o doce minutos probablemente servirían igual de bien. Nuevamente, tenga en cuenta que esto es un huerístico solo para indicar un problema, una especie de luz de advertencia, por así decirlo. Como se describe en mi respuesta, no me concentro en el tiempo cuando trato de arreglar reuniones demasiado largas, me concentro en minimizar lo que se hace en la reunión. (Las reuniones que se acortan son solo un buen efecto secundario de eso).
@zameb Para usar una analogía: en su automóvil, la luz de combustible se encenderá antes de que su tanque esté realmente vacío, para darle tiempo de llegar a la estación de servicio y llenarlo. Tal vez en los autos Ford se encienda con 10 millas de gasolina restante, en los autos Nissan con 12 millas y en los autos Toyota con 15 millas. La pregunta que se debe hacer no es "pero cuál es el estándar correcto para que se encienda la luz de combustible", es "¿por qué somos tan malos para repostar regularmente que necesitamos depender continuamente de la luz de combustible para decirnos que vayamos a la gasolina? estación".
Si necesita 45 minutos de discusión al comienzo de cada día, parece que su equipo necesita una mejor sincronización en general durante todo el sprint: una mejor comprensión de la meta de primavera, la planificación, el desglose de tareas, no tomar trabajo hasta que se cumpla alguna 'definición de listo', etc.
Gracias por las ideas. Estoy de acuerdo en que hay múltiples problemas con la planificación, el objetivo y el desglose de tareas. Al reducir el tiempo diario, intento evidenciar dónde está el problema. Al menos aumentaremos el tiempo para poner las manos en el trabajo, en lugar de una charla infinita. Probablemente no entreguemos tanto como esperan pero será más de lo que hoy es: básicamente nada
Así como se mencionó 10 minutos, fue solo un ejemplo, afaik, la guía oficial de Scrum menciona 15 como máximo. Bueno, pueden ser 10, 8 o 2 minutos por participante. Al final, se está volviendo más evidente que fue solo una preferencia de Sutherland y no algo proveniente de la investigación.
@anotherdave Podría haber problemas en la forma general en que realizan los sprints, pero mi experiencia con las reuniones de sincronización que duran demasiado es que el problema suele ser que la gente no las usa como un punto de sincronización, sino como un foro para discusiones en profundidad. sobre temas particulares con otros desarrolladores en la reunión. Por ejemplo, en lugar de "Hablemos después de la reunión sobre esas pruebas que siguen fallando debido a problemas con los datos", la discusión sobre eso comienza en la reunión misma. (Y, por supuesto, todo el equipo tiene que sentarse y escucharlo).
¿Los timeboxes de 15 minutos de Daily-Scrum son el resultado de alguna investigación pública?
RespuestasAquíPolítica de privacidad1y, 0v