¿Cuál es el propósito de la reunión diaria de Scrum?

Tengo una reunión diaria de pie con unas 20 personas. Solo trabajo con 2 de estas 20 personas. Cuando me toca levantarme, digo lo que he hecho y lo que haré; me toma alrededor de un minuto. Durante el resto de la reunión, que dura entre 15 minutos y 1 hora, me siento allí fingiendo escuchar lo que otros dicen sobre temas en los que no estoy trabajando y que no son relevantes para mí.

Esto no quiere decir que no estoy involucrado con esas dos personas con las que trabajo. Por lo general, hablamos antes de la reunión para "sincronizarnos" y nos informamos si tenemos un problema. Si alguien me está esperando, le digo lo que estoy haciendo, y así sucesivamente. Hacemos esto cada vez que es necesario. Si surge algo, no esperamos a que llegue el día siguiente para "hablar" cuando tenemos un problema. Hablamos en ese momento y, por lo general, solucionamos el problema o planificamos cómo solucionarlo mucho antes de la próxima reunión diaria.

Esto me hizo pensar en por qué estamos haciendo el standup diario. Según las guías de Scrum, se supone que la reunión diaria debe centrarse "en el progreso hacia el Sprint Goal y un plan de acción para el próximo día de trabajo" y para "promover la toma de decisiones rápida".

Aún así, la guía continúa diciendo que los desarrolladores "a menudo se reúnen durante el día para discusiones más detalladas sobre la adaptación o replanificación del resto del trabajo del Sprint". Así que esto es lo que me encuentro haciendo.

Si se supone que el día a día es para tomar decisiones rápidas, bueno, esto es lo que mis colegas y yo hacemos a lo largo del día. Cada vez que surge algo y necesitamos tomar una decisión, inmediatamente nos "sincronizamos", involucramos a cualquier otra persona que deba participar y decidimos en ese momento qué hacer. ¿Cuál es, entonces, el sentido del diario?

La razón por la que necesita escuchar en qué están trabajando otros y/o tienen problemas es que si puede ayudarlos , puede hablar y ahorrar tiempo para el proyecto. Si eso no tiene ningún sentido, entonces la reunión tiene demasiados asistentes y debe dividirse en reuniones separadas.
Bueno, según esta lógica, deberíamos tener una reunión con los 10.000 desarrolladores empleados en la empresa en caso de que alguien tenga un problema con el que alguien más pueda ayudar.
No seas tonto. ¿Nunca ha trabajado en algo que un colega podría haberle ayudado a terminar más rápido si se lo hubiera pedido?
Una cosa es pedir ayuda y otra cosa es preguntarle a la gente si necesitan ayuda. Cuando alguien pide ayuda, el acto de ayudar es una reacción a esa súplica inicial de ayuda, mientras que esperar activamente a que alguien pida ayuda sabiendo que nadie podría ser... bueno, una pérdida de tiempo, especialmente cuando los que podrían preguntarle algo están trabajando con tecnologías completamente diferentes en diferentes proyectos. Claro, es posible que pueda dar algunos consejos generales, pero no podrá resolver el problema.
Decir “Ahora tengo un problema con x” implica automáticamente preguntar si alguien sabe algo que pueda ayudar sin siquiera tener que decirlo.
Creo que no entendí bien tu comentario inicial. Pensé que estabas diciendo que debería escuchar lo que dicen todos mis colegas, incluidos aquellos con los que no trabajo, que son la mayoría de ellos, en caso de que pueda ayudarlos de alguna manera.

Respuestas (6)

Hay una diferencia entre un Daily Scrum y una reunión de pie.

El Daily Scrum es uno de los eventos Scrum y está definido en la Guía Scrum . Es un evento de 15 minutos para que los desarrolladores del equipo Scrum analicen su progreso hacia el Sprint Goal y determinen qué harán durante el día siguiente para acercarse a lograr ese Sprint Goal. Es un evento de planificación realizado por y para los Desarrolladores, administrado por los Desarrolladores y tal vez facilitado por el Scrum Master a pedido de los Desarrolladores.

En el desarrollo ágil de software, la reunión diaria de pie se origina en la programación extrema . Incluye a todo el equipo: los desarrolladores, el cliente en el sitio, el entrenador y cualquier otra persona involucrada en el trabajo diario. Originalmente, todos se pusieron de pie para que la reunión fuera breve, pero muchos equipos han dejado de lado esa regla. Incluye tanto actualización de estado como componentes de planificación.

Fuera del desarrollo de software ágil, otros tipos de equipos han utilizado prácticas similares para actualizar y alinear el equipo.

Lo que usted describe como una "reunión diaria de pie", una reunión que podría durar más de 1 hora con 20 personas que incluye temas que no están relacionados con su trabajo diario, no se alinea con la definición de Scrum de Daily Scrum o la reunión diaria de pie de Programación Extrema. Para mí, las dos mayores preocupaciones son la cantidad de personas (20 es demasiado para un equipo de desarrollo de software ágil) y los temas (los temas deben ser directamente relevantes para todas las personas que asisten).

En teoría, el propósito de Scrum's Daily Scrum no es tomar decisiones detalladas. La orientación sobre las reuniones a lo largo del día a menudo incluye la resolución de los problemas más específicos que enfrenta el equipo y, a menudo, incluye un subconjunto del equipo. Cuando comienza a incluir a todos, o incluso a la mayoría, de los desarrolladores del equipo en los puntos de decisión o quizás en todo el trabajo, se está moviendo hacia el mobbing y el Daily Scrum se vuelve menos útil. Daily Scrum es más útil cuando las personas trabajan individualmente o en parejas y necesitan tener la oportunidad de sincronizarse, asegurarse de que su Sprint Backlog refleje la realidad para las partes interesadas externas y, si hay algún riesgo o impedimento, involucre al propietario del producto. y Scrum Master inmediatamente.

Es posible que vea algún valor en que usted y sus colegas directos se reúnan hasta 15 minutos una vez al día para llevar a cabo un verdadero Daily Scrum. En algunos casos, esto puede reemplazar algunas de las "sincronizaciones" más ad-hoc que está haciendo y dar a las personas más tiempo para concentrarse en el trabajo con menos interrupciones y cambios de contexto. Sin embargo, realmente no hay problema con las sincronizaciones ad-hoc si el equipo está satisfecho con su desempeño. Puede que no sea Scrum, pero ser un equipo efectivo y eficiente es más importante que seguir las reglas de Scrum.

La conclusión con respecto a la reunión de scrum es que solo las personas relevantes deben participar y sincronizarse, pero en cuanto a la necesidad real, ¿por qué dice que las conversaciones ad-hoc son interrupciones? Si yo, como desarrollador frontend, noto que ocurre un error cuando hago una solicitud al backend en el que está trabajando mi colega, ¿debo esperar al día siguiente para avisarle? O si noto una falla en la lógica comercial que estamos implementando, ¿no debería contactar a mis colegas para discutirlo? Cuando terminamos con todas las charlas, ya sabemos lo que cada uno de nosotros está haciendo y lo que planeamos hacer.
@ user1969903 Depende de la urgencia, que depende del contexto. Generalmente, sin embargo, una comunicación ad-hoc aleja a alguien de lo que está haciendo y lo lleva a otra cosa. Lleva tiempo cambiar los contextos a lo nuevo y luego volver a lo antiguo. Minimizar esas interrupciones es bueno. Tener un Daily Scrum para planificar en qué está trabajando la gente y dónde sería necesaria la asociación o la interacción permitiría a las personas planificar su día de manera efectiva. También puede ayudar a eliminar esos errores o fallas o defectos antes de que se inyecten en el sistema.
Esta oración parece importante: lo que [estás haciendo] no se alinea con la definición de Scrum de Scrum diario o reunión diaria de programación extrema .
@user1969903 si nota un error en algo que usa y en lo que está trabajando otro colega, plantea el problema, lo pone en la lista de espera si es posible, y si el problema no es crítico, comienza a trabajar en el siguiente elemento y deja que el otro colega /scrum master lo maneja en el siguiente scrum diario; si el problema es crítico, informe tanto al Scrum Master como al colega y deje que el Scrum Master lo maneje lo antes posible.
@ThomasOwens Cuando digo comunicación ad hoc, lo que quiero decir es que los empujo y digo "oye, mira, esto y aquello". Si están ocupados, lo hablaremos más tarde y todos continuamos. No es como organizar una reunión, reservar una sala de conferencias, enviar invitaciones y todo eso. ¿Todavía se considera esto una interrupción? No veo esto más como una interrupción que las bromas regulares de la oficina, que diría que son solo interacciones sociales regulares de la oficina en este momento.
@JoshPart Si es algo que forma parte del sprint / EE. UU. actual, lo arreglamos cuando sea conveniente; de ​​lo contrario, creamos otra historia de usuario durante nuestra planificación del sprint, lo que generalmente involucra también al cliente. Me gustaría su opinión sobre si esto encaja con Scrum, pero supongo que ese es un tema para otra pregunta.
@ user1969903 He agregado una respuesta a la pregunta; verifique si responde lo que está comentando aquí, de lo contrario, intentaré abordar esa pregunta específica en los comentarios
@ usuario1969903 Sí. Empujarlos y pedirles que miren algo es una interrupción. Incluso si no parecen ocupados, podrían estar trabajando: leyendo algo relevante para su trabajo actual, pensando en un problema. A menos que estén tomando un descanso completo del trabajo, pedirle a alguien que analice un problema es una interrupción y requiere que cambien su enfoque hacia lo que usted necesita y luego lo desvíen. Tener un buen Daily Scrum es una excelente manera de que todos sepan en qué está trabajando y si anticipa que necesitará el conocimiento, la experiencia, la opinión o simplemente los ojos en el trabajo de otra persona.
@ThomasOwens Entiendo de dónde viene, pero no puedo evitar verlo simplemente como un cambio en el momento en que ocurre la interrupción. De una forma u otra, el problema deberá analizarse eventualmente. Ahora entiendo que el diario puede ayudarnos a decidir cuándo debe ocurrir esta interrupción, pero aún requerirá que cambien su enfoque hacia el problema y luego, una vez hecho esto, regresen a la tarea en la que estaban trabajando.
@ThomasOwens En todo caso, he agregado dos interrupciones más a la mezcla porque ahora tenemos: 1. diario donde el problema se menciona brevemente (pero supongo que esto era obligatorio de todos modos), 2. reunión separada para discutirlo en detalle; 3. El tiempo real en que se analiza el problema. ¿Cómo es esto diferente? Por cierto, estoy hablando de problemas que son relevantes y deben solucionarse en el sprint actual. Cualquier otra cosa sería parte de un futuro sprint.
@ user1969903 Tener una interrupción planificada es mejor simplemente porque está planificado. Tomarse 15 minutos para decidir qué es importante y cuándo se pueden reunir las personas necesarias es mucho mejor. Tal vez ni siquiera sea hoy, tal vez la gente pueda resolver el problema mañana o pasado mañana. De todos modos, tiene cambios de contexto naturales entre tareas, por lo que está planificando y aprovechando esos cambios en lugar de tener cambios de contexto arbitrarios en medio del trabajo. Ayuda a mantener el enfoque y el flujo para poder reservar el tiempo para terminar una tarea o prepararse para el cambio de contexto.
@ThomasOwens Ok, ahora entiendo cuál es el propósito del diario, y parece que ya lo estamos haciendo por separado, pero todavía tengo algo que preguntar sobre los otros puntos que mencionas. Cuando "interrumpo" a alguien, no tiene que detenerse y cambiar de contexto. La mitad de las veces, por lo general, solo toman nota y manejan el problema cuando lo consideran oportuno. A veces hablamos de ello durante un descanso (supongo que cambia de contexto natural), a veces simplemente me informan que el problema se solucionó y, a veces, hablamos de lo que ahora veo que es nuestro propio día a día. ¿Es esto realmente una mala práctica?
@ user1969903 Si alguien deja de hacer lo que está haciendo para "tomar nota de ello", eso es una interrupción. Acabas de romper su flujo. Cada vez que eso sucede, toma minutos, hasta 15-20 minutos, para recuperarse. Tres interrupciones por día es una hora de trabajo perdido para cambiar de contexto. Si espera hasta que ambas personas estén en un descanso, por lo general no agrega cambios de contexto adicionales al día.
@ThomasOwens Supongo que todo se reduce a lo que constituye una interrupción y si son tan costosos como dices. Si ese es el caso, entonces cada notificación de correo electrónico que no es de trabajo, ventana emergente de holgura, recordatorio de calendario, etc. están desperdiciando hasta 15-20 minutos de trabajo. Recibo alrededor de 20 de esos al día (aproximadamente 8 correos electrónicos por día, el resto solo chats aleatorios de slack/equipos) por un total de hasta 5 horas perdidas por el cambio de contexto. Seguramente ese no es el caso. ¿Por qué? Porque puedo ignorarlos, especialmente cuando estoy concentrado en algo. Sé que están allí, puedo volver a ellos cuando me apetezca.
@ThomasOwens, creo que necesito consultar algo de literatura sobre este tema porque me has despertado mucha curiosidad.
@user1969903 Para las notificaciones de aplicaciones, estas son personalizables. Además, las personas tienen diferentes tolerancias para una ventana emergente en su monitor (y en qué monitor aparece) que otras. No es fácilmente comparable con una llamada o un toque en el hombro. Pero si está interesado en obtener más información, Gerald Weinberg tiene mucha información sobre el cambio de contexto en Quality Software Management: Systems Thinking (Volumen 1). También puede leer sobre las ideas de Mihaly Csikszentmihalyi detrás del flujo para los fundamentos científicos.

La reunión Daily Scrum está ahí para alinear a las personas que realmente están involucradas en el trabajo hacia el Sprint Goal.

Se supone que debe ser breve y no entrar en detalles. Indica quién necesita ayuda, quién está trabajando en algo que podría interferir con su trabajo; La alineación diaria es clave.

No es un informe de progreso diario. No es reportar información que ese grupo de personas no necesita inmediatamente. Y no es una reunión secuestrada porque es muy conveniente tener a todos juntos.

Si su descripción es precisa, están desperdiciando entre 10 y 20 horas de trabajo al día. Mi sugerencia sería que todos escriban una breve nota indicando lo que aportan a la reunión y lo que obtienen de ella. Eso toma dos minutos y los resultados deberían ayudar a reestructurar la reunión.

Estoy de acuerdo en que la reunión que estamos haciendo no es precisamente constructiva, pero ese no es el enfoque principal de la pregunta. Lo que estoy preguntando es ¿por qué necesitamos una reunión diaria si ya tenemos reuniones cortas donde las personas relevantes se alinean cada vez que surge la necesidad, lo que, en realidad, sucede varias veces al día?
Por lo tanto, ya tiene una rutina de trabajo en la que habla y se alinea con frecuencia durante el día. En ese caso, un scrum diario para ustedes tres sería una reunión en la que retroceden por un momento, hacen una descripción general rápida y luego se ponen a trabajar. Compáralo con la cocina de un restaurante; durante el trabajo estarías atado a los detalles del plato que estás haciendo. El scrum es donde miras a tu alrededor: ¿todavía hay suficientes verduras? ¿Cuántos pedidos tenemos esta noche? ¿Hay algo de interés con lo que te encontrarás más tarde, como una gran fiesta a las 20:00? Es una planificación del día y puede terminar en minutos.
Adición: puede notar que hace esta alineación con sus colegas durante el día y no necesita una reunión por separado. Scrum no se obsesiona con la forma; eso solo significa que ha encontrado un formulario que funciona para usted. El Daily Scrum es un recordatorio de que se necesita la alineación, y el Standup es una forma que funciona para muchas personas.

Me parece que sus reuniones están mal etiquetadas: la reunión de más de 1 hora con 20 personas, la mayoría de las cuales no afecta ni se ve afectada por su trabajo, no es un Daily Scrum.

El Daily Scrum es este:

Esto no quiere decir que no estoy involucrado con esas 2 personas con las que realmente trabajo. Por lo general, hablamos antes de la reunión para "sincronizarnos", nos informamos si tenemos un problema, si alguien me está esperando, le digo lo que estoy haciendo, etc.

Esta simple charla con tus colaboradores directos, tan breve que ni siquiera requiere sentarse, es un Daily Scrum. Y como esta tradición la has inventado tú solo (¡un equipo autoorganizado!) ya sabes el valor que esta reunión aporta a tu día.

Apéndice: ¿Por qué su reunión larga no es un Daily Scrum?

Scrum se define en la Guía de Scrum, que escribe :

El Daily Scrum es un evento de 15 minutos

... y ese es un cuadro de tiempo, es decir, si el equipo siente que la reunión se realiza antes, por supuesto, pueden irse antes.

para los Desarrolladores del Equipo Scrum

... así que solo los desarrolladores, no todo el equipo. E incluso todo el equipo debería estar

lo suficientemente pequeño para seguir siendo ágil y lo suficientemente grande para completar un trabajo significativo dentro de un Sprint, normalmente 10 o menos personas. Si los Equipos Scrum se vuelven demasiado grandes, deberían considerar reorganizarse en múltiples Equipos Scrum cohesivos, cada uno enfocado en el mismo producto.

Si solo necesita coordinar con otros dos, los 3 deben ser su propio equipo, ¡con su propia reunión!

Y debido a que los Equipos Scrum son

autogestionables, lo que significa que deciden internamente quién hace qué, cuándo y cómo.

el equipo decide cómo lleva a cabo sus reuniones (posiblemente dirigido por el Scrum Master , que sirve al equipo por

Asegurarse de que todos los eventos de Scrum se lleven a cabo y sean positivos, productivos y se mantengan dentro del marco de tiempo.

Entonces, si su Scrum Master fuera bueno, evitaría reuniones diarias de una hora llenas de información irrelevante...

Apéndice 2: ¿Por qué diariamente?

¿Por qué necesitamos una reunión diaria si ya tenemos reuniones cortas donde las personas relevantes se alinean cada vez que surge la necesidad?

¿Qué distingue a estas reuniones cortas de un Daily Scrum?

¿Que las personas involucradas son relevantes? Como cualquier reunión, el Daily Scrum debe centrarse en temas de interés para sus participantes. Los temas que afectan solo a un pequeño subconjunto de participantes deben discutirse en otro lugar (en este caso, Daily Scrum aún puede ser útil para determinar quién debe participar y cuándo reunirse). Además, dado que se supone que los equipos de Scrum son cohesivos, su trabajo generalmente debe ser relevante para el resto del equipo, por lo que generalmente debe haber algo de qué hablar. Y en los raros casos en que no la haya, puede finalizar la reunión antes de tiempo.

¿O es que la reunión es cada vez que surge la necesidad? Eso puede ser una bendición y una maldición. ¡Una bendición, porque la reunión ocurre solo cuando se necesita, pero una maldición, si ocurre una nueva reunión cada vez que se identifica una necesidad! Después de todo, cada reunión interrumpe a los participantes, lo que hace que la información relevante para lo que sea que estaban haciendo antes sea desalojada de la memoria a corto plazo, lo que llevará algún tiempo reconstruir antes de que el trabajo pueda continuar. Al reunir estas discusiones en una sola reunión, se pueden discutir varios temas a costa de una sola interrupción. Y al tener esta reunión a la misma hora y en el mismo lugar todos los días, la programación se simplifica enormemente.

Entonces, ¿por qué todos los días? Porque eso es fácil de recordar y resulta ser un buen equilibrio entre la inmediatez de la discusión y la frecuencia de la interrupción para muchos equipos.

En primer lugar, como han mencionado otros, lo que usted describe primero no es una reunión diaria de scrum standup. Lo que su empresa está haciendo actualmente es lo que las personas que están demasiado acostumbradas a las metodologías lineales o no ágiles suelen hacer cuando quieren decir que han adoptado una metodología ágil sin cambiar realmente nada; por lo tanto, el único propósito de esa reunión actual es que los gerentes sepan en qué están trabajando todos y qué porcentaje del trabajo se ha completado.

Ahora, lo que describe que hace con su equipo se parece más a lo que debería ser un scrum diario o una reunión diaria: una reunión rápida para sincronizar el trabajo de todos los miembros, averiguar si hay algo que deba discutirse o escalarse, y decidir cómo fluirá el trabajo hasta la próxima reunión.

¡Pero! como mencionas, algo de esto puede (y debe) ser resuelto o discutido durante el día; esta es precisamente la razón por la que la reunión diaria se ha refinado/redefinido/reutilizado a lo largo del tiempo. Si todavía hay una reunión diaria en las pautas de scrum, es porque se supone que una metodología ágil debe ser, bueno, ágil, y no vale la pena detener repentinamente el trabajo de otros miembros del equipo para discutir cualquier tema, obstáculo o problema. A veces, cuando surge algo, solo necesita registrarlo en cualquier herramienta que se use como trabajo pendiente, retomar la siguiente tarea y luego dejar que el equipo lo maneje durante la próxima reunión diaria.

Puede parecer que la guía de scrum se contradice en estos temas, pero no olvidemos que scrum es un marco y no un conjunto de reglas grabadas en piedra. Para algunos equipos/organizaciones, la reunión diaria es suficiente, para otros, reunirse durante el día es más eficiente, para otros, puede ser una combinación de ambos; después de todo, uno de los objetivos de scrum es tener equipos autoorganizados que puedan encontrar lo que funciona mejor para ellos.

Entonces, si reunirse durante el día Y antes de esa otra reunión más grande funciona para su equipo y cumple con las pautas de su empresa/departamento, siga haciéndolo. Si su posición le permite plantear su preocupación de que la reunión más grande distrae o puede mejorarse, hágalo también. Recuerde que también debe haber una reunión retrospectiva donde se puedan tratar este tipo de temas.

"Si su posición le permite plantear su inquietud..." Creo que eso resume muy bien por qué la cultura cooperativa y ágil/scrum es, digamos, ¡una combinación difícil en el mejor de los casos!
Gracias por tu opinión sobre el tema. Tenemos una retrospectiva, pero la tenemos principalmente porque es parte de nuestro contrato. Realmente no se hace nada. Al menos, así es como me siento al respecto. Nunca escuché a nadie hacer un seguimiento de un problema anterior y decir que el problema de nuestro último retro se solucionó. En todo caso, escuché que el mismo problema todavía existe.

Donde trabajo, no hacemos todo exactamente según las reglas. Pero el Daily Scrum es un lugar para:

  • Mencione el horario para las próximas 24 horas, cuando eso afecte a otros.
    "Casi termino con esa historia. Necesitaré otro desarrollador para la solicitud de fusión. ¿Quién está libre?"
  • Mencione posibles impedimentos y averigüe quién necesita hablar sobre ellos.
    "No creo que la UX funcione como esperábamos. Deberíamos analizarlo con el propietario del producto y el diseño. ¿Mañana por la tarde?"
  • Dale al propietario del producto o a los desarrolladores la oportunidad de cambiar el sprint.
    "Ese error acaba de aparecer. Es/no es más importante que el objetivo del sprint". O simplemente "Uno de ustedes lo mira y da una estimación aproximada. ¿Quién?"
  • Asesorar al propietario del producto y al Scrum Master sobre el estado del objetivo del sprint.
    "Subestimamos esa historia. Tendremos que dejar algo más si quieres hacerlo en este sprint".
  • Socialice un poco, especialmente porque todavía estamos trabajando desde casa bajo las reglas de la pandemia.

Una docena de personas, 15 minutos. En un buen día, 10 minutos equivalen a menos de un minuto de tiempo de conversación para la mayoría. Es un lugar para delegar o escalar problemas y programar reuniones no rutinarias.

La reunión de Scrum es una parte esencial de la gestión de todo proyecto, especialmente uno que sigue la metodología Agile. Se considera una fuente valiosa para obtener actualizaciones, información y comentarios en tiempo real del equipo de desarrollo. También sirve para ayudar a mantener al equipo de campo alineado con los objetivos y plazos de la empresa.

Para aprovechar al máximo los beneficios de las reuniones diarias de Scrum, las empresas deben creer en el empirismo y crear un marco integral para la implementación. Si tú, tu equipo o tu Project Manager aún no están convencidos, ¡déjame ayudarte! A continuación se enumeran muchos beneficios de implementar reuniones Scrum diarias para equipos, organizaciones, individuos, productos y servicios exitosos.

  1. Mayor colaboración y propiedad
  2. Métricas más relevantes
  3. Mejora de la visibilidad y exposición del progreso
No te ofendas, pero suenas como uno de esos evangelistas que llaman a la puerta de la gente preguntándoles si han oído hablar de los muchos beneficios de "nuestro señor y salvador, [insertar deidad políticamente correcta, despertada, neutral en cuanto al género]".
Esto no parece abordar la pregunta que realmente se hizo.
¿Cuál es el propósito de la reunión diaria de Scrum?
RespuestasAquíPolítica de privacidad1y, 1v