¿Las reuniones de Daily Scrum deben realizarse por la mañana o por la tarde?

Estaba acostumbrado a las reuniones diarias de scrum por la mañana (después de 30/60 minutos de trabajo), pero actualmente estamos realizando reuniones después de 6 horas de trabajo. Creo que este enfoque tiene la ventaja de centrarse en los problemas que han encontrado los miembros del equipo cuando responden a la pregunta "¿Hay algún impedimento en su camino?" pregunta. Creo que esta es la más importante de las tres preguntas que responden los miembros del equipo.

¿Cuál es la mejor parte del día para tener las reuniones Daily Scrum, por la mañana o por la tarde?

Respuestas (7)

TL;DR

¿Cuál es la mejor parte del día para tener las reuniones Daily Scrum, por la mañana o por la tarde?

No puede haber una respuesta única y canónica a esta pregunta que sea cierta para todos los equipos y todos los proyectos. Sin embargo, ciertamente existen algunas prácticas comunes, pero tenga en cuenta que "común" no significa necesariamente "mejor".

Para aclarar las compensaciones involucradas en la selección de un momento óptimo para su stand-up diario, proporcionaré algunos ejemplos concretos de cómo se debe usar la reunión Daily Scrum. Una vez que todo su equipo comparte una comprensión fundamental de para qué sirve el scrum y cómo aprovechar al máximo su formato, es mucho más fácil hacer los ajustes necesarios para descubrir qué funciona mejor para su equipo.

Naturalmente, también tengo algunos consejos pragmáticos al respecto. En el caso general, comenzar su stand-up diario 30 minutos después del inicio de las "horas principales" de su equipo será de gran utilidad para muchos equipos. Si bien no es universalmente cierto, es un principio de proxy razonable para usar como punto de partida hasta que pueda definir empíricamente el tiempo óptimo de reunión para su equipo, en su organización y en su campo de actividad.

Entendiendo el Propósito del Stand-Up Diario

Cada una de las tres preguntas formuladas durante el Daily Scrum es igualmente importante para la coordinación interna del equipo requerida para un Equipo Scrum exitoso. Es un error hacer que una de las preguntas sea más importante que las demás. Como @jessehouwing señala correctamente :

El objetivo más importante del scrum diario no es identificar problemas, sino crear un plan para las próximas 24 horas (hasta el próximo scrum diario).

Dicho de otro modo, el objetivo del stand-up diario es permitir que el equipo coordine sus actividades. Las "tres preguntas" proporcionan un marco para que los miembros del equipo hagan lo siguiente:

  1. Identifique el trabajo completado que está listo para pasar a la siguiente columna del flujo de trabajo basado en extracción del equipo.

    ¿Qué hiciste ayer? debe obtener un elemento de trabajo de la persona que actualmente maneja la historia de aumento de widgets. Esta persona está comunicando qué partes del trabajo se han realizado y está listo para ser incluido en la columna de control de calidad por la persona del equipo que esté mejor capacitada para manejar las pruebas de Selenium o Capybara que forman parte de la definición de hecho de la historia.

  2. Identifique la capacidad de la cola y coordine el traspaso.

    ¿Qué harás hoy? debe provocar la expectativa de un miembro del equipo de qué trabajo está listo para realizar para que dos personas no intenten agarrar la misma historia. Esta pregunta también debe provocar dependencias de tareas o historias, y puede hacer explícitas las expectativas implícitas . Por ejemplo, cuando el miembro del equipo Bravo dice "Hoy planeo agrandar la Cascada Foo", esa persona está comunicando que:

    • Lo que estaba en el plato de Bravo ayer está hecho y tiene capacidad disponible.
    • Bravo se compromete a trabajar para agrandar la cascada hoy, a menos que el equipo autoorganizado identifique algo más que tenga prioridad.
    • El trabajo que el miembro del equipo Alpha dijo que estaba en el plato de Alpha ayer ahora lo necesita el miembro del equipo Bravo, y Alpha debería hablar si Foo Cascade aún no está listo para que Bravo lo aumente.
    • Si Alpha y Bravo necesitan coordinar el traspaso con más detalle, identifican la necesidad y planean desconectar la coordinación adicional. Por ejemplo, Alpha podría decir: "La cascada está lista para ti, Bravo, pero reunámonos después del scrum para que pueda explicarte cómo insertar la pestaña A en la ranura B antes de que comience el agrandamiento".
    • Bravo le informa al equipo que, si todo sale bien hoy, la persona que recogerá Foo Cascade mañana para probarlo (supondremos que es el miembro del equipo Charlie) puede planificar su trabajo en consecuencia, ya que ahora hay una expectativa explícita de cuándo la historia de usuario estará lista para el siguiente paso en su viaje.
  3. Identifique cualquier nueva tarea o historia que pueda requerir cambios en el Sprint Backlog del equipo o que requiera coordinación adicional o apoyo de otros miembros del equipo.

    ¿Tienes algún obstáculo? debe obtener una breve lista de cosas que se interponen en el camino de una transferencia limpia entre los miembros del equipo. Por ejemplo, es posible que el miembro del equipo Charlie no pueda probar Foo Cascade porque el condensador Quux tiene una fuga. Charlie menciona esto como un obstáculo para que el equipo pueda discutirlo brevemente para determinar qué recursos tienen para abordar el problema (si los hay), quién anotará la tarea en el Sprint Backlog si aún no se ha hecho, y quién debe asumir la propiedad provisional de la tarea de desbloqueo.

    Continuando con este ejemplo, acabamos de enterarnos de que el miembro del equipo Bravo ha limpiado su placa, y no tiene sentido que Bravo trabaje para aumentar la cascada de Foo hasta que se haya solucionado la fuga del condensador Quux, ya que Charlie no puede realizar el trabajo completo mientras este obstáculo está en sitio.

    Este tipo de resolución cooperativa de problemas a veces se denomina enjambre o detener la línea , y es la forma Scrum de permitir que el equipo mantenga el flujo y la cadencia a lo largo del Sprint. También aprovecha la holgura de los procesos y la propiedad colectiva para asignar dinámicamente los recursos a las historias de los usuarios de una manera que la gestión de comando y control generalmente no puede reproducir o coordinar de manera tan eficiente.

Algunos consejos prácticos

Si bien no puede haber una respuesta canónica a la pregunta de cuándo deben realizarse las reuniones, ciertamente existen algunas consideraciones pragmáticas.

  1. En un equipo autoorganizado, una práctica común es tener "horas principales" en las que todos los miembros del equipo están disponibles entre sí. Por ejemplo, un equipo puede tener un horario central entre las 10:00 a. m. y las 2:00 p. m., pero las personas pueden llegar antes, trabajar más tarde o tener un horario totalmente basado en el desempeño fuera de ese horario central. Programar el stand-up diario cerca del comienzo de las horas centrales suele ser la mejor manera de garantizar que haya suficiente tiempo para la coordinación dentro del equipo después del stand-up.

  2. Realizar el scrum demasiado pronto puede resultar en una menor productividad de aquellos que no son madrugadores y no les da suficiente tiempo para revisar el trabajo del día o preparar datos coherentes para el scrum. Asegúrese de que las personas tengan al menos tiempo suficiente para tomar una taza de café y la oportunidad de revisar su correo electrónico, el estado de creación de CI u otras métricas antes de esperar que un scrum produzca resultados significativos.

  3. Celebrar el scrum demasiado tarde en el día no deja suficiente tiempo libre en el proceso para manejar eventos imprevistos y no proporciona al equipo las reuniones ad hoc posteriores al scrum que pueden necesitar para coordinarse entre ellos.

En mi propia experiencia como Scrum Master, realizar el stand-up diario de 15 minutos 30 minutos después del inicio de las horas centrales (por ejemplo, realizar el scrum de 10:30 a. m. a 10:45 a. m. cuando las horas centrales son de 10:00 a. m. a 2:00 p. m. ) es empíricamente la mejor estrategia que he encontrado. Sin embargo, otras estrategias también son válidas, por lo que su kilometraje ciertamente puede variar.

En general, todas las interrupciones del "flujo" mental de los trabajadores del conocimiento altamente concentrados son contraproducentes y, por lo tanto, el momento, la duración y la estructura del día a día requieren una cuidadosa consideración.

Habiendo probado algunas variantes, prefiero mantener los 30 minutos diarios después de que todos estén en la oficina. Las razones son:

  1. Hay suficiente tiempo para que la mayoría del equipo se "caliente" con un café, algunas pequeñas tareas administrativas como correos electrónicos y para volver a concentrarse en el trabajo de ayer. Sin embargo, es antes de que se hayan metido en las zonas mentales necesarias para lograr un trabajo de calidad.

  2. Permite a las personas formar un plan para el día y articularlo frente al resto del equipo. La verbalización genera confianza y, como en cualquier deporte de equipo, una "reunión" cronometrada al comienzo del juego genera motivación e impulso.

  3. Permite suficiente tiempo antes del cierre de operaciones para que el scrum master planifique y ejecute cualquier actividad de eliminación de impedimentos que pueda ser necesaria y también permite que el equipo tenga suficiente tiempo para programar sesiones de programación en pareja y otras reuniones de coordinación/intercambio de conocimientos.

Sin querer profundizar demasiado en esto, en general creo que los seres humanos están programados de manera innata para seguir ritmos diarios de comportamiento, comenzando de nuevo por la mañana y cerrando por la noche. También funcionan mejor si sienten que tienen una dirección o un plan desde el principio, por lo que mi recomendación sería hacerlo todos los días temprano.

El objetivo más importante del scrum diario no es identificar problemas, sino crear un plan para las próximas 24 horas (hasta el próximo scrum diario).

Sin embargo, no importa cuándo exactamente hagas el scrum diario. Lo prefiero temprano en la mañana si todos los miembros del equipo tienden a llegar a la misma hora. Si los miembros del equipo llegan en diferentes momentos, generalmente sugiero que los equipos elijan su tragamonedas favorito. Muchos equipos hacen un diario justo antes o después del almuerzo. Lo cual es una ruptura natural en tu 'ambiente' de todos modos.

Cuando un miembro del equipo encuentra un problema durante el día, es mejor que trabajen juntos para resolverlo.

El scrum diario puede identificar posibles problemas en el futuro, que pueden afectar la capacidad de su equipo para completar el objetivo del sprint, esos son en los que se centran las 3 preguntas.

En términos generales, una reunión matutina es mejor, porque

  • no divide la jornada laboral en dos mitades (la mayoría de las personas se quejan de las reuniones porque dividen su trabajo en partes y les resulta difícil comenzar de nuevo)
  • durante la reunión solemos hablar de lo que va a pasar después de la reunión y cuando es por la tarde pierde puntos. Además, el equipo ya no está necesariamente unido (la gente se va temprano, continúa desde casa, etc.)

Por supuesto, si los miembros del equipo no están en la oficina por la mañana o si tiene más de un sitio con diferencia horaria, no tiene otra opción que mantener la reunión en un horario adecuado para todos.

Y qué pasa si la reunión es en la última hora del día. ¿Es más una reunión de supervisión, destinada a satisfacer el interés de un gerente que a ayudar a los trabajadores a encontrar soluciones?

La convención es por la mañana, pero la respuesta es que depende de las necesidades de tu equipo.

Al elegir un momento para el scrum diario, considere lo siguiente:

  • zonas horarias
  • estilo de vida y necesidades profesionales
  • necesidades del cliente
  • ritmo de trabajo

¿En qué zonas horarias se encuentran los miembros del equipo? Si su equipo está distribuido geográficamente, elija un horario que respete las horas de trabajo de tantos miembros del equipo como sea posible. Si alguien tiene que asistir al scrum a las 3 a. m., considere alternar cada pocos sprints para compartir las molestias.

¿Qué se adapta a los estilos de vida de los miembros del equipo? A algunas personas les gusta comenzar el día más tarde que otras. A menudo me gusta trabajar hasta la medianoche, por lo que no soporto un scrum diario a las 7 am porque entonces estoy trabajando sin haber sido probado y sin ser productivo. Del mismo modo, algunas personas tienen hijos y necesitan salir de la oficina para recogerlos después de la escuela. Por lo tanto, las necesidades de su equipo variarán.

¿Dónde está el cliente del equipo y cuáles son las necesidades de comunicación de ese cliente? Esta pregunta se aplica más a la programación de demostraciones de productos, pero si el cliente o el gerente del equipo asistirán a un scrum, entonces es importante considerar qué horas del día funcionarán para esa parte interesada. Esto es más importante si el cliente utiliza los comentarios del scrum diario para comprender y comunicar cómo se está desempeñando un proveedor.

¿A qué ritmo está trabajando el equipo? Si el equipo rara vez completa una tarea entre scrums o es un esfuerzo de medio tiempo para la mayoría de los miembros del equipo, entonces puede ser frustrante para los miembros del equipo reunirse todos los días. Considere ajustar la frecuencia de los scrums para adaptarse a las realidades del equipo. Aumente las reuniones en persona con otras formas de comunicación.

En la mañana. Lo primero.

Lo más importante que debe hacer en el scrum diario es decir en qué tarea está trabajando ese día.

Esto da inmediatez y no permite equívocos, es decir. "Sé que dije ayer que hoy haría X. Pero se me olvidó/me dormí/cambié de opinión"

También se ocupa del problema de la gente que no se presenta. es decir.

  • Ayer , Alex dijo que haría la tarea X,
  • pero estaba enfermo y esperamos todo el día antes de tener esta reunión
  • donde asignamos X a Bob para hacer mañana.
  • Si Alex aparece mañana, no trabajará ese día excepto asistir al scrum diario.

Nuestro equipo suele hacer una reunión diaria a las 13:00. Este es el tiempo que el equipo acuerda y cada miembro del equipo puede asistir a la reunión sin problema. En reunión, planeamos para las próximas 24 horas lo que vamos a terminar.

Elegir la reunión diaria en la mañana o en la tarde, creo que depende del acuerdo y la disponibilidad de su equipo. Algunos equipos prefieren por la mañana, otros por la tarde.