Cuestiones de Daily SCRUM Meeting 1: El Horario

21 12 2007


- Buenos días Ana, Te llamo para avisarte que ya podemos ver el tema de los archivos que aun no llegaron. ¿Cuánto nos estaría demorando?
- Emmm… ¿Qué archivos?. No… no entiendo.
- Ayer en la daily meeting comentaste que no estaban llegando los archivos que necesitas para terminar la importación de datos.
- Ahh… si, si cierto. Bueno, ahora me fijo. Es que… creo que llego algo hoy temprano…

Luego de ya algunos años de implementar Daily SCRUM Meetings en los proyectos bajo mi responsabilidad, he detectado que la repetición constante de casos como el este no son nada más ni nada menos que producto de una cuestión independiente de la tecnología, el ritmo de trabajo, la experiencia de la gente y del tamaño del equipo: el horario elegido para esta reunión.

Resulta un criterio de Perogrullo que el horario debería ser el mismo todos los días, pero ¿A qué hora? ¿Cuándo resulta más conveniente?. Pues bien, eso depende de muchos factores, desde el ritmo y las tareas de trabajo hasta las preferencias de los miembros del equipo. Personalmente y partir de mi experiencia, yo prefiero hacer las meetings por la mañana, lo más temprano posible (pocas veces las he implementado por las tardes y descarto de plano el mediodía, ya que la cabeza de los miembros del equipo por lo general está en otro lado a esa hora: en el almuerzo).Obviamente cada elección tiene sus ventajas y desventajas. Las que siguen son las más notorias:

Daily meetings por la mañana.
Pro: Todos o la mayoría de los problemas expuestos en la reunión son tratados, investigados, resueltos en el mismo día. A no más de entre 4 y 5 horas de distancia de haber sido compartidos con el resto del equipo en dicha reunión.
Contra: Cuando uno asiste a estas reuniones a la mañana debe hacer el esfuerzo por recordar qué fue lo que hizo el día anterior y como fueron resueltos los problemas. Esto es seriamente agravado luego de un fin de semana o feriado, donde se debe recordar lo hecho y resuelto hace 2 días, o –peor- el viernes anterior.

Daily meetings por la tarde.
Pro: Es natural para los asistentes hablar acerca de los temas tratados, tareas realizadas y problemas resueltos durante ese mismo día. También así plantear los problemas y riesgos que cada ha detectado.
Contra: La mayoría de los problemas expuestos en la reunión son tratados, investigados, resueltos al siguiente día. Esto es causa, por lo general, de confusiones, olvidos, necesidad de seguimiento excesiva, etc. Y como es predecible, extremadamente difícil los días Lunes.

En mi opinión, el segundo escenario es el peor de los dos. Es por esto que yo siempre tiendo a elegir un horario bien temprano a la mañana en tanto y en cuanto no moleste al equipo. Una salvedad necesaria en este punto es que con “no molestar al equipo” no me refiero a permitirles llegar tarde; sino a darles el suficiente tiempo al principio de cada día y antes de la daily meeting para estar “on-track” con el escenario general del proyecto. Esto es más evidente en proyectos de alto rendimiento o con un equipo global, donde mientras uno duerme por la noche la rueda sigue en movimiento; y al llegar por la mañana debe hacer un “update” en su memoria. Leyendo, entendiendo y procesando los 50 nuevos e-mails que hay en el inbox.

Mi horario preferido es de 10:00AM a 10.15AM (no más de 10:30AM); pero lo más importante aquí es que sea un horario que todo el equipo haya acordado y aceptado.

Llegadas tarde
Otro tema asociado directamente con el horario de la daily meeting es la ocurrencia de llegadas tarde
Para ser sincero, pocas veces tuve que lidiar con el mal de “la llegada tarde crónica”. Por lo general, los casos que se me presentaron fueron esporádicos y anecdóticos.
Las pocas veces que se ha presentado ese problema con el equipo hemos implementado una suerte de “multa” simbólica. La idea es que quien llega tarde, aunque sea 2 minutos tarde, debe dejar una cantidad prefijada de dinero (muy poco de hecho) en una alcancía destinada para ese fín. Aunque uno avise de antemano que va a llegar tarde, igualmente debe pagar el precio; salvo algún evento que lo justifique, como un turno con el médico.
Ese dinero se utilizaba mensualmente para algún evento de equipo, como comprar helados un viernes por la tarde o un desayuno un martes por la mañana.

No nos olvidemos que esto debe ser “parte de un juego” y no un castigo. Pero insisto, esto es estrictamente necesario cuando hay un problema de “latecomers” explícito en el equipo.

Hasta aquí he expuesto uno de los tantos temas a considerar a la hora de implementar daily meetings o hacer correcciones frente a una que no está funcionando del todo.
Espero que la hayas encontrado útil y haber colaborado con tu implementación de prácticas tendientes a una gestión de proyectos Agile.


Acciones

Información

Deja un comentario

Puedes usar estas etiquetas : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>