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

9

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?

agile scrum

— Cielo
fuente

Si tienes un scrum con 11 personas y 1 chico con 1 minuto de retraso, es una pérdida de 10 minutos de tiempo de la compañía. Si 1 chico llega 6 minutos tarde, ya es una hora. Algo que puede parecer pequeño puede resultar sorprendentemente grande.

— Pieter B

24

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.

— Karl Bielefeldt
fuente

Entiendo tu punto. Aunque siento que rompe el espíritu del Daily Scrum, al menos como se describe. Además, nunca ha sido un retraso de más de un minuto. Y lo es principalmente, porque el software no funciona bien. Los problemas habituales de teleconferencia.

— Cielo

2

Es mucho más fácil en persona, ya que generalmente las personas están sentadas cerca unas de otras, y pueden ser agarradas si llegan tarde. Soy propietario de un producto en un proyecto que suena similar en el sentido de que tenemos personas que trabajan en al menos cuatro ubicaciones separadas a nivel internacional. Es más difícil porque a veces las personas llegan "tarde" debido a limitaciones técnicas. Personalmente, creo que se puede hacer un balance si las personas no lo abusan.

— Gort the Robot

@StevenBurnap Eso es lo que siento, nadie en mi equipo está cerca. Y que una hora de inicio de la reunión sea a las 3 p.m., no significa que las personas comiencen a hablar a las 3, significa que se reúnen a las 3. Simplemente siento que ser tan estricto es realmente contraproducente en equipos distribuidos.

— Cielo

Voto este porque usted dijo primero que los equipos Scrum pueden decidirlo por sí mismos, y que mencionó que algunas personas pueden sentir "así es como se hace el scrum". El resto es relativo, ya que las condiciones para cada situación son muy difíciles de explicar aquí. Y con respecto a la puntualidad, depende de las personas, prefiero no castigar a las personas que honestamente tuvieron problemas, solo por la posibilidad futura de abuso, ya que los equipos distribuidos tienen complicaciones adicionales que no puedo describir aquí. ¡Gracias por tu respuesta!

— Cielo

1

excepto que en el mundo real el equipo no siempre asume la responsabilidad y es un gerente o medio gerente quien toma el control de las reuniones y las obliga y hace cumplir las reglas.

— Rudolf Olah

6

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.

— Bryan Oakley
fuente

El único problema con "a primera hora de la mañana cuando todos están disponibles" es que no se obtiene el ritmo de hacerlo todos los días a la misma hora. Tampoco permite que los que lleguen más tarde se comprometan con el trabajo y se pongan al día para que no olviden nada en su scrum diario. ¡Creo que su punto sobre comenzar sin demora es bueno! Enseña a todos a llegar a tiempo. Ese es un punto excelente y sugeriré que adoptemos.

— jmort253

Supongo que no estaba lo suficientemente claro. No quise decir una hora diferente cada día. Quise decir que el equipo tiene que elegir la primera hora en que estén disponibles, y luego deben usar esa misma hora todos los días.

— Bryan Oakley

Oh. OK, eso tiene mucho sentido entonces. Me alegro de haberlo preguntado. :)

— jmort253

2

¿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.

— Robert Harvey
fuente

1

¿No es el objetivo principal de tener una reunión no estructurada todos los días para que el equipo pueda saber lo que todos están haciendo y ofrecer ayuda a los demás? ¿Y por lo tanto, es más importante que se sientan cómodos y compartan, que si llegaran 30 segundos tarde?

— Cielo

3

if you know they are calling in, why not wait?- Porque una espera de 3 minutos se convierte en una espera de 5 minutos, luego una espera de 10 minutos ... Como Tom Hanks dijo elocuentemente en la película Cast Away (cuando habla sobre el registro a tiempo de Federal Express) "Antes de que te des cuenta, somos el Servicio Postal de los Estados Unidos ".

— Robert Harvey

2

Si no mantienes la puntualidad, la gente se molesta contigo y entre ellos. Si mantiene la puntualidad, las personas se molestan consigo mismas por no asegurarse de que estén listas. ¿Cual preferirías?

— keshlam

2

Creo que 15-20 minutos es demasiado tiempo. Si vas a pasar más de 5 minutos, lo estás haciendo mal.

— Bryan Oakley

2

@RobertHarvey el propósito del scrum diario es tomar rápidamente el pulso del equipo, identificar impedimentos y programar seguimientos solo entre los miembros necesarios del equipo según sea necesario sin perder el tiempo de todos en una reunión más larga y tradicional. Consulte en.wikipedia.org/wiki/Stand-up_meeting#Software_development para obtener una buena descripción general. Existe una gran cantidad de literatura disponible sobre scrum y es posible que leer algunos de ellos lo ayude a comprender mejor las preguntas de scrum y lo coloque en una posición para proporcionar consejos más significativos específicos del contexto.

— robar

2

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.

— Rudolf Olah
fuente

0

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.

— Michael Shaw
fuente

Al final resultó que, y como era mi sensación, el problema no era con el proceso, era con la gente. Estaban usando el proceso como una excusa, a medida que los miembros del equipo se familiarizaban más entre sí, la tolerancia crecía y, de repente, no tuvieron problemas para esperar 30 segundos o un minuto para que alguien se uniera, porque ahora sabían El uno al otro. No recomendaría mantener SCRUM separados a menos que ambos equipos trabajen en partes muy diferentes del proyecto y nunca necesiten interactuar. Estoy de acuerdo, los SCRUM deben ser ágiles, pero aún más equipos deben ser coherentes y tolerantes cuando hay problemas.

— Sky