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í?
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.
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.
nico haase
zameb