¿Por qué y por qué razones a los desarrolladores no les gusta el "scrum diario"? [cerrado]

Hay ventajas en mantener el scrum diario, como:

1. El equipo se coordina entre sí
2. Todos saben qué cantidad de tarea se ha realizado
3. El cuadro de Burndown se vuelve más y más completo
4. El tablero de tareas se actualiza
5. No dura tanto, 15 minutos no matarán a nadie

Sin embargo, recientemente (después de 6 meses de implementación y uso de scrum), siento que a nuestros desarrolladores ya no les gusta tanto scrum diariamente. La gente simplemente actualiza el tablero de tareas, sin explicar lo suficiente y parece que están aburridos. Veo que cuando, por cualquier motivo, no lo sostenemos, se vuelven muy felices.

Simplemente no sé qué podría estar mal con esto. ¿Hay alguna razón mencionada en alguna parte por las desventajas que el "scrum diario" puede tener para un equipo? ¿Cuáles podrían ser las razones para que los desarrolladores se cansen del scrum diario?

Tenía experiencia participando en un equipo "SCRUM" con varios empleadores. Me parece que los gerentes toman la "reunión de scrum diaria" como el punto principal de SCRUM, y la establecen como la meta, en lugar de tenerla para lo que es: un medio para lograr un ciclo de desarrollo más efectivo .

Muy rápidamente, las reuniones de 15 minutos se convirtieron en reuniones de 45 minutos, las actualizaciones fueron ineficaces porque las personas estarían ocupadas bostezando y pensando "cuándo podemos ir ya" en lugar de escuchar a los demás, y también rompería las rutinas de las personas (yo, por ejemplo, estoy una persona lechuza, y llegar a trabajar a las 9 a.m. para esta estúpida reunión todos los días es una razón suficiente para que renuncie al trabajo

Cuando los gerentes toman una idea que puede ser buena si se aplica correctamente, y la llevan al extremo, obtienen exactamente lo contrario de los resultados que esperaban. Yo personalmente creo que los más reuniones que participan en - el menos trabajo que estoy haciendo. Tengo 2 reuniones regulares por semana en mi calendario y generalmente me salteo una de ellas. Las reuniones son para gerentes, deja que los desarrolladores hagan su trabajo.

Estoy seguro de que habrá muchos entusiastas de SCRUM que dirán "Pero es tan maravilloso", bueno, guárdelo, lo he escuchado todo.

Me parecería aburrido e inútil todos los días si sintiera que tiene poco o ningún valor. Hay algunas cosas que pueden reducir la utilidad de un standup diario.

• La información que se comparte nunca me pertenece o me afecta de ninguna manera.
• Ausencia de propiedad del equipo y de que todos trabajen siempre en sus propios proyectos.
• Ausencia de comunicación del equipo fuera del standup.
• Falta de progreso visible o comunicado.
• Ausencia de información para compartir.

Estos están justo en la parte superior de mi cabeza, pero siempre hay más razones posibles.

¿Quizás debería preguntarles a los desarrolladores por qué no parecen estar interesados? Si desea más / mejor comunicación, debe comenzar con usted.

Algunos de los problemas encontrados con las reuniones diarias de SCRUM:

• los que duran demasiado No querrás ningún tipo de gerente en esos diarios porque son la causa principal de este tipo de problemas. Vea cómo suelen ser los que usan una silla (sí, tener que defenderlos es atraer a la gente a ser rápido)
• tener que escuchar acerca de alguien (o 2 o 3 desarrolladores) que describa cualquier problema aislado que tenga largo en lugar de que él decida programar otra reunión real más tarde para discutirlo con los interesados
• estúpidas horas Esas reuniones no tienen que ser por la mañana: no estás hablando de lo que hiciste ayer y no estás decidiendo qué harás hoy; estás hablando de lo que has hecho entre el último día y este y estás decidiendo qué harás hasta el próximo.
• falta de propiedad de la aplicación para los desarrolladores. SCRUM funciona si los desarrolladores no son tratados como monos de código. La primera señal de que el proceso va mal es cuando los desarrolladores no son los que evalúan cuánto tiempo llevará algo hacer.
• estúpidas horas de nuevo. Si parte del equipo ha comenzado a trabajar en algunas cosas y está "en la zona" cuando ocurre el día a día, se vuelve una molestia. Un buen momento para consumirlos diariamente es cuando nadie debería estar trabajando (después del almuerzo, por ejemplo, o justo antes de comenzar algunas discusiones durante el almuerzo).

El tiempo es el asesino para muchos. A los programadores les gusta codificar tarde, dormir hasta tarde y entrar después del apuro de la mañana. Tener que estar en el cargo a una hora fija, demasiado pronto para ellos. Y demasiado tarde para otros que pueden venir antes y comenzar a trabajar ya.

El flujo es otro problema. Un programador en funcionamiento con alguna función funcionará hasta altas horas de la noche, irá a casa y volverá recargado y listo para continuar. Tener que asistir a una reunión con problemas en su mayoría no relacionados puede distraerlo.

Mi observación es con demasiada frecuencia que estas reuniones son para que los gerentes se vean y sientan que realmente están haciendo algo en lugar de ser útiles para el equipo y el proyecto.

Por ejemplo, se asigna un equipo para hacer una serie de correcciones breves de errores en diferentes proyectos. Realmente no están trabajando en equipo sino como individuos. Sin embargo, debido a que la política de la empresa / departamento lo exige, el líder / gerente del equipo celebra una reunión scrum diaria de todos modos. Todo lo que se logra es tomar más de 15 minutos para una reunión inútil y agregar 15-30 minutos de distracción y falta de productividad antes y después de la reunión.

Ahora, he visto que Scrum funciona bien en un proyecto que tenía plazos ajustados y requería mucha coordinación entre las personas que trabajan en varias piezas. En ese contexto, fue un gran sistema. Pero, en el contexto de "Estamos teniendo una reunión porque somos una tienda scrum / ágil y eso es lo que se supone que debemos hacer" realmente puede ser una mierda.

Asegúrese de que nadie monopolice la reunión.

Si 4 de los desarrolladores obtienen su perorata fuera del camino en 5 minutos, y los siguientes 10 minutos se gastan escuchando el líder del equipo que detalla todos los increíbles , impresionantes nuevos desarrollos que ha hecho, la mayoría de los cuales no son ni tan sorprendente ni tan impresionante como él piensa que son, la gente se aburrirá muy rápidamente.

Retrocede un momento y piensa en tu equipo:

• ¿Están trabajando de manera efectiva?
• ¿Las tareas se completan a tiempo?
• ¿Es el código robusto y bien escrito?
• ¿Se asegura el equipo de que no se caiga nada?
• ¿El equipo se coordina para no duplicar el trabajo o pisar los dedos del otro?

Si su respuesta a todas estas cosas es "Sí", tal vez debería considerar por qué desea forzar el trabajo ocupado como las reuniones diarias, los cuadros de trabajo y los tableros de tareas en su equipo. ¿Qué valor agrega? ¿Desea generar datos burocráticos únicamente para su propio disfrute o está tratando de hacer que el equipo sea más productivo?

¿Ha habido una disminución en la productividad desde que se detuvieron los scrums diarios, o todo funciona igual que antes? Si nada ha cambiado, ¿por qué continuar las reuniones?

15 minutos. ¿Transmiten esos 15 minutos (más el tiempo para prepararse) suficiente información nueva y útil entre los miembros del equipo para mejorar la productividad del equipo para el día siguiente en más de 15 minutos? Si no hay esa cantidad de contenido útil de scrum todos los días, los miembros del equipo probablemente piensen que avanzarían mucho más hacia los objetivos si salieran de esta reunión lo antes posible y volvieran al trabajo.

Si solo desea actualizar el tablero y el gráfico con frecuencia, coloque borradores en una wiki.

Sugeriría si realiza la reunión retrospectiva para ver "Lo que salió bien" y "Lo que no salió bien" y ver si los desarrolladores enumeran la reunión Stand-up diaria como una pérdida de tiempo. Entonces necesitarías reorganizarlo un poco.

Mi experiencia personal:

• El objetivo es saber qué estamos haciendo hoy y dónde estuvimos ayer. En lugar de apegarse a la agenda, se convierte en una discusión técnica de bloqueadores entre 2 personas y las otras 15 se aburren. Identifique el problema pero discuta afuera
• Las personas no entran a la sala de reuniones a tiempo, y esto se convierte en un ciclo hecho por algunos a propósito. Por lo tanto, el Scrum Master necesita tener una discusión tranquila con ellos fuera de la reunión para asegurarse de que comiencen y terminen a tiempo.
• Ya actualizamos los gráficos de burndown fuera de la reunión de Scrum, por lo que ese no es el objetivo principal del stand-up diario.

La resistencia se produce cuando: 1) Se utilizan para obligar a las personas a apresurarse durante las 9 a.m. Es un estrés adicional cuando el tren llega tarde. 2) Pobre liderazgo de scrum. El líder debería decirle a la gente que desconecte las cosas en lugar de hacer que la gente escuche algo que no les afecta. 3) Contenido sin valor. Este es nuevamente un problema de liderazgo scrum. Se supone que es un foro para abordar cuellos de botella, problemas de trayectoria y posibles colaboraciones. Lo que sucede en realidad es que todos simplemente dicen lo que esperan trabajar ese día, lo que no sirve de nada ni interesa a nadie más. 4) De pie. No soportaré estar de pie. La lógica detrás de estar de pie es que alienta a las personas a ser breves. La gente en realidad solo habla sin parar.

Me las he arreglado y he sido parte de los equipos scrum muchas veces. La razón principal por la que a los desarrolladores no les gusta scrum es:

• Debido a que funcionan con un scrum master muy pobre, si se convierte en 45 minutos, su scrum master necesita mejorar para controlar el scrum.
• La razón más grande y, con mucho, la más honesta por la que no les gusta, es porque es muy difícil esconderse en una mala ética de trabajo, es decir, más descaradamente, muestra gente perezosa. Algunos desarrolladores con los que he trabajado son impactantes, llevan días haciendo tareas que deberían ser un trabajo de 30 minutos. Un buen PM debería eliminar las barreras para los desarrolladores, lo que significa que deberían poder completar sus tareas en un sprint. A los desarrolladores no les gusta porque tienen que ponerse de pie cada día y demostrar el progreso que han logrado. Causa ansiedad cuando no pueden demostrar progreso por cualquier razón. Si se debe a un problema válido, un buen scrum master debería resolver ese problema lo antes posible.

El problema surge cuando los maestros scrum no tienen la autoridad, las habilidades o la capacidad para resolver problemas de bloqueo. De hecho, he visto algunos problemas de enterramiento con la esperanza de que desaparezcan. Esto es desastroso.

Francamente, en el 99% de las reuniones diarias de scrum a las que he asistido, casi todas las discusiones / preguntas / respuestas podrían haberse solucionado con unos pocos correos electrónicos.

Sinceramente, creo que debemos mostrar razones más válidas para NO tener reuniones. Cree entornos donde, cuando sea el momento de acorralar a todos en una habitación en persona, sea mejor que sea una buena razón y esté organizado para maximizar la eficiencia del tiempo.

Odio las reuniones en general, y preferiría usar videoconferencias, teléfonos, correos electrónicos, cualquier cosa que me permita entrar o permanecer en mi trabajo sin tener que levantarme e interrumpir mi flujo de productividad.

Personalmente, creo que si tiene más de cuatro reuniones en un período de 8 horas, los proyectos no se gestionan bien.

Hay muchos factores que contribuyen a la tensión sobre las reuniones. Considere estas como algunas de las razones importantes por las cuales las reuniones pueden costarle más de lo que valen:

• Enfoque: software versus reuniones
• Gestión: los gerentes necesitan medición
• Personalidad - Introvertidos vs. Extrovertidos
• Hora - interrupciones, hora de Maker y Manager
• Objetivos, prioridades

Cada uno de esos factores se explica a continuación,

Enfoque : disfruto desarrollando software, y eso incluye pensar en los desafíos (problemas), crear soluciones, construir el software y las reuniones distraen la atención de las tareas que lo compilan. Hay un estado llamado " Flujo " en el que un desarrollador está inmerso en el desafío (problema), ha creado un modelo mental de la solución y tiene un enfoque completo en la construcción de la solución. Un desarrollador puede trabajar hasta la medianoche, salir solo para comer y dormir, luego volver a un estado cercano a donde se fue.

Los desarrolladores deben evitar las distracciones, y muchos encuentran que hay ventajas para codificar hasta altas horas de la noche (evitan el ruido, las llamadas telefónicas, la oficina ocupada y los colegas no desarrolladores que interrumpen su trabajo). Y cuando ha trabajado hasta las 10, 11 o 12 p.m., no es irrazonable venir a trabajar más tarde (10, 11, mediodía?). ¿Es razonable esperar que los desarrolladores trabajen desde las 9 de la mañana hasta la medianoche?

Las reuniones de Scrum (y cualquier) distraen al desarrollador de su objetivo principal, que es la creación de software.

Administración : los gerentes deben medir para tener éxito, de ahí la necesidad de cronogramas, entregas, plazos, prioridades y reuniones para medir e informar el progreso y exponer dependencias, demoras y áreas de riesgo. El desafío con un Scrum es que un gerente necesita estas cosas, pero el desarrollador necesita concentrarse. Las reuniones sirven al gerente y proporcionan una forma para que el administrador obtenga, mida y rastree el estado y los progresos, pero las reuniones rara vez brindan utilidad a los desarrolladores. Considere que los gerentes brindan más valor cuando manejan distracciones, eliminan barreras y permiten a los desarrolladores concentrarse en la creación de software.

Hay soluciones a la necesidad de reuniones. Un gerente puede visitar a sus desarrolladores, solicitar informes de estado, adoptar un protocolo para cuando las interrupciones son menos intrusivas, o adoptar una política que el desarrollador les notifique sobre el progreso cuando el desarrollador sea interrumpible. Vea la discusión del tiempo sobre por qué esto es importante.

Personalidad : considere que algunas personas son introvertidas y otras son extrovertidas. Los extrovertidos disfrutan de las interacciones sociales y son recargados por ellos. Los gerentes suelen ser extrovertidos (porque los extrovertidos suelen ser mejores con las interacciones sociales), aunque los introvertidos pueden tener éxito como gerentes. Los introvertidos pueden disfrutar e incluso sobresalir en las interacciones sociales, pero se recargan por la soledad. Los desarrolladores a menudo son introvertidos y tienen éxito trabajando solos (o en pequeños equipos) porque no "necesitan" interacciones sociales; pueden ser felices trabajando solos en problemas (aunque los extrovertidos también pueden ser desarrolladores). Las reuniones diarias de scrum pueden convertirse en reuniones sociales, buenas para los extrovertidos, pero no tan buenas para los introvertidos.

Tiempo : los desarrolladores no pueden escribir código mientras están en reuniones. Tampoco pueden pensar en problemas difíciles (a menos que sean una lluvia de ideas), mientras están distraídos por las reuniones. Los desarrolladores necesitan grandes bloques de tiempo ininterrumpido para centrarse en la creación de software. Las reuniones son interrupciones que distraen de sus esfuerzos. Cuando ha estado inmerso en la resolución de un problema durante horas, ya casi termina, y alguien dice "tiempo para el scrum", lo interrumpen y tal vez pierda horas de trabajo mientras "cambia de marcha". O ha permanecido en el trabajo hasta las 11:00 p. M., Dejó el trabajo, viajó a su casa, durmió sobre el problema, se despertó, regresó al trabajo listo para resolver el problema y luego fue interrumpido después de una hora de trabajar en un problema, porque es "tiempo para el scrum".

Paul Graham tiene un excelente artículo sobre Maker Time vs. Manager Time, que explica este problema mucho mejor que yo. Baste decir que una interrupción de la reunión, ya sea planificada o no planificada, puede interrumpir el flujo y obligar a un desarrollador del tiempo de Maker al tiempo de Manager. Créeme, quieres desarrolladores en tiempo de Maker.

Objetivos, prioridades : los desarrolladores y gerentes tienen diferentes objetivos y prioridades. Los gerentes tienen la responsabilidad de realizar un seguimiento de los horarios, minimizar los costos, garantizar que sus informes sean responsables y que se desempeñen. Los desarrolladores tienen el objetivo de construir el software que aborde los desafíos / problemas. Estos objetivos no están en conflicto, pero es el mecanismo de comunicación el que crea la tensión. Las reuniones satisfacen las necesidades del administrador y optimizan el tiempo de los administradores, pero entran en conflicto con las necesidades del desarrollador. Las reuniones de Scrum descartan la primera regla de las reuniones, "tienen una agenda" y tienden a vagar más. Y las reuniones se utilizan para optimizar la comunicación (para el gerente), pero le cuestan tiempo al desarrollador (interrupciones, pérdida de flujo, etc.).

Cual es el objetivo? Crear software que aborde las necesidades, de forma rápida y con calidad, mientras que las restricciones son (calidad, tiempo, costo, proceso). Scrum y otras metodologías ágiles reconocen la restricción del proceso e intentan minimizar ese factor, y han tenido éxito porque minimizan esa restricción. Pero agregar reuniones cuesta tiempo, y la interrupción le cuesta al desarrollador mucho más que la duración de la reunión.

Modifique la reunión para asegurarse de que brinde beneficios:

1. Programe a una hora que ofrezca cierta comodidad. ¿Por qué no pueden ser 30 minutos después del inicio del trabajo para que todos puedan revisar el correo electrónico y organizar sus pensamientos para la reunión? La brevedad requiere planificación. Los que no están preparados pueden divagar para siempre.
2. Identifique los problemas que podrían haberse evitado si se hubiera comunicado un problema durante la reunión. Todos necesitan entender cuál es el punto.
3. Haga lo que sea necesario para mantener los aportes de todos al mínimo. No es el lugar para el debate. Anime a las personas a programar reuniones privadas fuera de la reunión diaria centrada en un tema que necesita discusión. Regla: solo una persona habla a la vez.

Todos los reclamantes deben asegurarse de que no están contribuyendo al problema. Si puede lograr sus objetivos para el scrum diario sin tener uno de una manera menos dolorosa, nos gustaría escucharlo.