¿Cómo hacer que la gente se presente a la reunión diaria? [duplicar]

Aunque tenemos nuestra reunión de pie a la misma hora todas las mañanas, la gente todavía no llega a la reunión por su cuenta. Necesito llamarlos para la reunión todas las mañanas. ¿Ayudaría decir que deben estar allí 2 minutos antes del tiempo asignado? No están en otras reuniones de antemano.

Soy scrum master y dev manager. Tenemos un equipo de 12 desarrolladores y estas reuniones suelen durar hasta 25 minutos.

Cronometré la reunión de esta mañana y tomó 16 minutos y 10 personas informaron, así que está bien.

Editar el 02/05/18

Comenzó a hacer reuniones de pie más pequeñas con menos personas. Ahora solo informan sobre bloqueadores, elementos que les impiden completar su trabajo.

¿Eres el scrummaster de este equipo?
Sí, y el administrador de desarrollo. Feliz de nombrar a alguien más para dirigir el stand up.
Suministro de donas.
Si tarda 25 minutos, entonces estás haciendo algo mal. Esa es probablemente la razón por la que la gente no quiere asistir. Deben ser de 10 minutos como máximo.
Deben ser 10 minutos como máximo : @DarrenYoung tenga en cuenta que son 12 personas, lo que significa que 20 a 25 minutos no es tan irrazonable.
@RaduMurzea Lo que no es razonable es el tamaño del equipo Scrum que conduce a largas reuniones como esta.
@RaduMurzea Estoy en un equipo de 8 y podemos hacerlo en 10 minutos muy bien la mayoría de los días. Realmente no debería haber tanta información saliendo.
Un mejor momento para una reunión corta regular no es a primera hora de la mañana, sino justo antes o después del almuerzo. Muchas personas están en el pico de su productividad por la mañana y tener una reunión interrumpe ese momento dorado.
@teego1967, en cualquier lugar donde haya trabajado, ese sería el peor momento para una reunión porque nadie va a almorzar a la misma hora y muchos trabajan durante el almuerzo.
Hablando como alguien que actualmente tiene AGILE impuesto sobre ellos, y resentido por eso, si un stand-up tomara 25 minutos todos los días, movería el Cielo y la Tierra para evitar asistir.
@teego1967 Tenerlo a la hora del almuerzo anula el propósito de una reunión de pie, que es identificar cualquier problema y riesgo para el día.
"Tenemos un equipo de 12 desarrolladores y estas reuniones suelen durar hasta 25 minutos". Eso es excesivo.

Respuestas (5)

Es posible que tenga un problema XY aquí. Averigüe por qué las personas no se presentan a la reunión y arréglelo.

Por ejemplo, si las reuniones duran demasiado y eso los distrae de su trabajo, comprenda por qué las reuniones son tan largas y cómo puede solucionarlo. Si no se discute nada útil en la reunión, y se trata más de "Hice esto, haré aquello", tal vez la reunión se pueda omitir por completo. Etcétera.

Es una reunión diaria de scrum que aborda las preguntas. ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Hay algún impedimento en tu camino? De momento es un grupo de 12 y ya no son 25min.
@fran 12 son demasiadas personas y 25 son demasiados minutos para una reunión de scrum.
Lo cronometraré, pero por lo general son menos de 25. El equipo de desarrollo está formado por 12, no dispuestos a dividir el grupo, ya que es útil para las personas escuchar en qué están trabajando otras personas. Y conduce a algunos buenos consejos solo de su propia experiencia al tratar con el mismo problema.
Un equipo de desarrollo de 12 es demasiado grande. Es probable que las personas no se presenten porque no están de acuerdo en que es útil escuchar en qué están trabajando otras personas.
No tienes que explicarme . :) Acabo de darte un par de quejas comunes que mi equipo ha tenido con la llamada reunión de scrum. Es posible que su equipo también tenga otros problemas, que puede averiguar hablando con ellos. Pero de todos modos, según su comentario, parece que la duración de la reunión puede ser parte del problema aquí.
@Erik Despediría a un desarrollador que está tan metido en lo suyo que no cree que lo que alguien más esté trabajando sea relevante para él. Eso es una incompetencia grave.
@HLGEM Depende de lo que realmente se diga durante la reunión. Solía ​​asistir a las llamadas reuniones de scrum, donde la gente informaba así: "Empecé a trabajar en el número 123, pero vi que tiene dependencia con el número 456, y otra cosa, para lo cual abriré un nuevo número de hoy".
Las respuestas tanto aquí como en el duplicado son buenas, pero a veces tienes un grupo que simplemente no puede llegar a una reunión requerida de inmediato por su propia voluntad. Trabajé en un proyecto durante un tiempo que usaba un timbre de bicicleta para recordarle a la gente que era hora de venir a los controles diarios y demás. El equipo lo odiaba , ¡pero fue efectivo!
@HLGEM: en cualquier empresa siempre hay unas pocas personas cuyas aportaciones son importantes y muchas otras cuyas aportaciones no. La idea general del scrum diario es escuchar solo a aquellos cuyas opiniones son relevantes para ti; es por eso que está limitado a "tu equipo" y por qué "tu equipo" está limitado en la cantidad de personas que puede ser.

La gente no estará ansiosa por ir porque no lo consideran útil.

¿Podría cambiar la reunión solo para repasar

  • lo que estoy haciendo hoy
  • Cualquier problema de ayer

Elimina lo que hicieron ayer a menos que haya un problema. Un scrum de 20-25 minutos no parece tan útil, por lo que es posible que deba acortar el scrum eliminando parte del contenido.

Trate de asegurarse también de que las discusiones sobre los problemas se lleven fuera de la reunión. Como desarrollador, realmente no puedo molestarme en escuchar acerca de un problema que no me interesa durante 10 minutos cuando tengo mis propias cosas que hacer. Describa brevemente el problema y luego deje que los desarrolladores en cuestión lo discutan después de la reunión.

Entiendo lo de dividir el equipo, pero ¿podría intentarlo? ¿Dividirlo en función de las áreas del software o algo así? ¿Quizás tener un scrum el lunes por la mañana con los 12 y luego scrums divididos por el resto de la semana?

No estoy seguro, pero "ser pagado y tener un trabajo" es útil. Dejemos a un lado todo el asunto milenario: cuyo pan tomo, cuyo hijo canto. La empresa espera que esté allí, no lo estoy -> violación del contrato de trabajo y mala ética.

Un equipo de scrum debe tener entre 5 y 9 personas. 12 es excesivo. Somos 7 personas y es fácil: cuando uno se levanta, todos los demás mirarán hacia arriba y pensarán "oh, es standup".

Asegúrese de que sea fácil llegar a tiempo:

  • No tenga una reunión en un momento en que la gente acaba de llegar. Es fácil perder un autobús o quedar atrapado en el tráfico. Fije la reunión para 30 minutos después de que lleguen las personas para que tengan un búfer y puedan revisar sus correos.

  • Establecer recordatorios. Haga que aparezca algo en las pantallas de las personas 5 minutos antes, para que tengan tiempo de cerrar su tarea actual y venir.

  • Reúnase en una sala de fácil acceso. Con un equipo Scrum, esa debería ser la sala del equipo. Todos se levantan de su escritorio y listo: ponerse de pie.

Y finalmente, si todos están de acuerdo en que es un problema, hablar de ello en la retrospectiva. Tenemos sprints de "conciencia de puntualidad", en los que el miembro del equipo que llega tarde con mayor frecuencia tiene que limpiar la cocina para el próximo sprint. Nadie llega tarde. Ni una sola vez. Pero esto tiene que ser una decisión de equipo, forzar algo así va en contra del espíritu Scrum.

El equipo de desarrollo debería tener entre 5 y 9, ¿verdad? Todo el equipo de scrum también incluye PO y SM e idealmente tendría entre 7 y 11.
@Erik: el PO no debería estar en una reunión de SCRUM. SI lo son, deberían ser solo espectadores (ya que su ladrido está cosido). Lo mismo ocurre con los gerentes. Si el PO está en problemas en las reuniones de SCRUM, está en el trabajo equivocado.
+1 para retrospectiva. Plantee un problema en la retrospectiva (los stand-ups no tienen mucha asistencia) y haga que los desarrolladores resuelvan cómo quieren ejecutar los stand-ups. Esto funciona mejor si los desarrolladores han tenido una formación adecuada sobre cómo funciona SCRUM, en lugar de aplicarlo al equipo de segunda o tercera mano. Una de las cosas buenas de SCRUM, desde la perspectiva de un desarrollador, es cómo detalles como este son mutables y están bajo el control del equipo. El experto en scrum está ahí para ayudar a cumplir con las mejores prácticas, pero la mayoría de los detalles son negociables.

Establezca un tiempo. Diles que tienen que estar allí. No los consigas, si no vienen. Dígales después que no los vio en la reunión y que realmente tienen que asistir de ahora en adelante. Si todavía no asiste regularmente, toma nota y siéntate con ellos.

Si no sienten que es algo que tienen que hacer, ¿por qué dedicarían 25 minutos a una reunión que podría no brindarles mucha información? Además, esfuércense por optimizar la reunión juntos. Pregúnteles qué tiene de malo y qué tiene de bueno. Pero no los reciba todas las mañanas. son adultos Han aprendido que serán llamados.

En resumen, el punto principal (además de todos los puntos mencionados en las otras respuestas, como optimizar la reunión y reducir el tiempo) es que han aprendido que serán llamados a la reunión. Así que están esperando eso. Dígales que ya no irá a buscar a nadie, repita la hora y el lugar una vez más y deje de llamarlos por separado. Es su responsabilidad presentarse.

Habrá reuniones desordenadas por un tiempo, pero eventualmente las cosas deberían mejorar.

Dado que esta es una parte fundamental de Scrum, es posible que desee averiguar si todos realmente están aceptando este proceso. Debería haber problemas y consecuencias cuando no dejan que todos sepan lo que están haciendo y lo que van a hacer y viceversa.

El problema no es su falta de asistencia, sino los resultados de no asistir. ¿Otras personas tienen que tomarse un tiempo adicional para informarles sobre los problemas? ¿Las personas en la reunión sienten que no pueden hacer su trabajo debido a la falta de aportes de aquellos que no asistieron a la reunión?

Suponiendo que tiene un grupo de personas que desean hacer bien su trabajo, descubra cómo pueden perderse esta reunión crítica y seguir funcionando de manera efectiva.