Reunión diaria de Scrum: ¿puntualidad sobre presencia de equipo completo?

Tengo entendido que una reunión de Daily Scrum debe ser muy rápida, organizada de manera amigable y que requiere la presencia de todos los miembros del equipo. Porque es objetivo es tener a todos al día con lo que todos los demás están haciendo.

Me gustan las reuniones diarias de Scrum que se llevan a cabo así.

En mi último proyecto, nuestros Scrums diarios son más como una reunión de actualización de estado. Aunque la posición es que estamos sosteniendo Scrums y practicando Agile adecuadamente.

Somos un equipo distribuido, en 2 países diferentes, y las personas que están en el mismo país no están en la misma oficina. Como consecuencia tenemos Scrums virtuales.

El problema es que nuestras reuniones siempre comienzan a tiempo, muchas personas llaman antes de la hora de inicio real, por lo que en realidad comienzan en el primer segundo de la reunión. Sin ninguna tolerancia a pequeños retrasos.

Por ejemplo, la última vez que estuvimos hablando por teléfono y la persona que coordinaba la reunión verificó si todos estaban encendidos, y dijimos que uno de los miembros de nuestro equipo aún no estaba conectado pero que estaba llamando. Y me dijeron que comenzara a compartir sin esperar al miembro de mi equipo.

Además, todos tienen muchas reuniones y, a veces, se encuentran consecutivos con la reunión de Scrum, por lo que es comprensible que lleguen durante el primer o segundo minuto de la reunión.

¿Es eso lo normal para los equipos que practican Daily Scrums? Es la primera vez que me pasa.

No puedo encontrar ninguna bibliografía directamente al respecto. Aunque se destaca la presencia de todos los miembros del equipo, también se destaca que las reuniones siempre deben comenzar al mismo tiempo. Pero me imagino que puede haber una pequeña tolerancia al retraso.

Incluso leí en un blog a alguien que sugiere que el Scrum Master puede imponer sanciones si alguien llega "5 segundos" tarde. Pensé que se suponía que los Scrums eran amigables, y tener una penalización como esa parece contraproducente.

¿Cuál es el enfoque recomendado en una situación como esta?

Al igual que con cualquier práctica ágil, los equipos scrum pueden decidir esto por sí mismos. Si te molesta, debes mencionarlo en tu retrospectiva y tratar de llegar a una solución con la que todos estén contentos. Quizás otros miembros del equipo sientan lo mismo, pero piensan que es "así como se hace el scrum".

Dicho esto, en mis reuniones de scrum comienzo en el segundo a menos que falten tres o más personas. Para una reunión a la que todos deben asistir todos los días, siento que es irrespetuoso con el tiempo de todos para hacer lo contrario. Cuando soy yo quien llega tarde, mi equipo comienza sin mí. Si tenemos tiempo al final, volvemos a las tareas de las personas que llegaron tarde.

He sido menos estricto con respecto a la puntualidad en el pasado, y lo que sucedió es que las personas que se presentaron a tiempo se cansaron de perder su tiempo, por lo que comenzaron a tratar de adivinar cuándo comenzaría realmente la reunión y, en cambio, aparecieron en ese momento, lo que había Un efecto de bola de nieve.

Para una reunión diaria, no es el fin del mundo si alguien ocasionalmente pierde parte de él. Esperemos que no sea la única comunicación que hagas a lo largo del día.

Si espera a la gente, les enseña que está bien llegar tarde. Si comienza en el minuto, se les enseñará a las personas que deben llegar a tiempo si quieren participar. La programación es una actividad profesional que requiere al menos un mínimo de disciplina.

Dicho esto, el objetivo del enfrentamiento diario es discutir lo que hizo el equipo ayer, lo que están haciendo hoy y hacer que todos estén al tanto de los obstáculos. La hora programada debe ser "a primera hora de la mañana cuando todos estén disponibles", no necesariamente una hora específica en el reloj. El objetivo final es trabajar juntos como un equipo, no seguir reglas estrictas. Si su equipo es muy nuevo en ágil, atenerse al reloj es una buena manera de desarrollar sus habilidades de equipo. Si eres un equipo maduro, haz lo que funcione para tu equipo.

¿Es así como funciona Scrum?

Le sugiero que las reuniones diarias sean demasiado frecuentes para cualquier actividad comercial, a menos que su equipo sea especialmente productivo (lo que significa que pueden producir grandes extensiones de funcionalidad en períodos de tiempo muy cortos).

Si decide tener etiquetas diarias, no deben durar más de 15 a 20 minutos, y sí, todos deben llegar a tiempo o no participar. Las etiquetas son para el beneficio de los miembros del equipo, no del scrum master; Las sanciones por faltar a las reuniones diarias deben manejarse de la misma manera que cualquier otra tardanza.

En resumen, no veo nada especial aquí. Creo que las reuniones diarias de cualquier tipo limitan con la microgestión, pero si decides hacerlo, debes hacerlo correctamente.

Personas sobre proceso . Ese es uno de los principales inquilinos de Agile, si un proceso no funciona para su equipo, deséchelo o modifíquelo. Deje que el equipo lo modifique para adaptarlo a sus necesidades.

Piénselo de esta manera, ¿cuál es el punto de la lucha diaria?

Es su oportunidad de aumentar los impedimentos con el resto del equipo, señalar que puede necesitar asistencia y resaltar los cambios que afectarán a otros. Es importante que usted como desarrollador esté allí.

Con un equipo de desarrolladores de 4 a 8, deben ser rápidos y rápidos: 30 segundos cada uno la mayor parte del tiempo. Si desempeñara el papel de scrum master, me preocuparía el inicio tardío de las reuniones, ya que aumentaría el costo de la reunión. Del mismo modo, los horarios de reunión variables crean una distracción para todos: estamos a punto de ... También sería muy consciente de equilibrar esto con las necesidades para garantizar que el equipo pueda apoyarse mutuamente, por lo que puede retrasar la reunión si es necesario porque alguien quien probablemente se vio impedido estaba en el teléfono / baño.

Cuando los equipos se distribuyen geográficamente como usted describe, estaría señalando esto como un impedimento de equipo en CADA retrospectiva. Es evidente que un impedimento para el desempeño y la comunicación de los scrums es que no todos están sentados juntos y son capaces de comunicarse libremente y fácilmente.

Argumentaría que esto debería organizarse como dos equipos de scrum separados, y el trabajo debería organizarse para que el scrum de scrums maneje la comunicación internacional.