Recientemente comencé a trabajar en un equipo de proyecto para una empresa que está en transición a metodologías ágiles, y eso significa reuniones diarias de scrum. Los scrum masters, sin embargo, tienden a mantener el formato de su reunión repasando los nombres de las tareas y solicitando el progreso para que puedan documentarlo ellos mismos. Esto lleva a muchas discusiones largas sobre esas tareas durante el scrum entre los empleados de administración que resuelven los detalles sobre esa tarea mientras los desarrolladores se sientan y escuchan. Estas reuniones superan la media hora asignada cada vez.
Que yo sepa, se supone que la reunión de scrum es una reunión enérgica de 15 minutos en la que cada desarrollador responde las siguientes preguntas:
Esto debería establecer un punto de referencia de progreso para y entre los desarrolladores .
Sin embargo, estas reuniones parecen estar orientadas a la contabilidad con fines de gestión y no brindan el espacio adecuado para que los desarrolladores establezcan puntos de referencia entre ellos, como lo fomenta el formato de reunión Scrum. En cambio, la reunión la lleva a cabo el maestro de scrum que enumera los números de problema para los nombres de las tareas con la siguiente pregunta:
Esto generalmente va seguido de una discusión que comienza como una aclaración entre el experto en scrum y el desarrollador, y luego termina como una discusión entre los empleados de la gerencia que intentan resolver los detalles sobre la historia relevante. Debido a esto, y a la naturaleza de varios desarrolladores asignados a la misma tarea mientras que solo uno informa sobre el progreso de la tarea, no todos los desarrolladores pueden participar en la reunión .
Notas a considerar antes de mi pregunta:
Mi pregunta es, ¿cómo/a quién debo abordar para plantear este problema al equipo del proyecto?
No quiero que el scrum master ni nadie en la gerencia sienta que esencialmente les estoy diciendo cómo hacer su trabajo, pero también siento que este cambio debe ocurrir, ya que estas reuniones son muy ineficientes e ineficaces para los desarrolladores y múltiples miembros. del equipo de desarrollo han expresado preocupaciones similares.
Editar: Debería haber notado que estas reuniones son por teléfono. Estamos en alrededor de 3-4 ubicaciones diferentes en total, una de las cuales no está en los EE. UU. Ninguno de los scrum masters o managers que he tenido en este proyecto estaban en mi ubicación.
Como dices en tu pregunta:
una empresa que está en transición a metodologías ágiles
He estado trabajando en una empresa en el mismo camino, los gerentes escuchan sobre los maravillosos pensamientos que proporciona Agile (principalmente la capacidad de enviar más rápido) e instruyen al equipo de desarrollo para que adopte la metodología. Pero al mismo tiempo, no les gusta que los desarrolladores pasen de 15 a 30 minutos todos los días en reuniones de scrum.
Entonces, tal vez el maestro de scrum quiera hacer las reuniones como dice el proceso, pero su gerente quiere o espera un resultado diferente que doble al maestro de scrum en ese formato de reunión.
O tal vez el maestro de scrum nunca reciba ningún tipo de capacitación (puede leer en línea sobre la implementación de scrum, pero no es fácil para todos hacerlo).
Puede usar su puesto como contratista (si tiene experiencia previa) para comenzar a hacer recomendaciones, no para decirles a todos que lo están haciendo mal porque no conoce el panorama completo.
Hablaré primero con el scrum master en privado, para saber por qué las reuniones son así, y luego ver cómo puedes ayudar (si es posible) sin decir que lo está haciendo mal, tal vez puedas decirle. sobre cómo experimentas los beneficios de seguir el formato normal de las reuniones en otras empresas/proyectos.
Es posible que te encuentres en una situación en la que solo necesites tener una conversación honesta. Esto se puede hacer con tacto, pero parece que hay algunas partes fundamentales de Scrum que no entienden.
No hay razón para abordarlo de manera grosera ("Ustedes apestan en esto"), pero compartir con tacto que hay mejores maneras ("¿Puedo compartir una forma de hacer esto que he visto que funciona realmente bien antes?") podría ser la camino a seguir. Sprint Retrospective es un lugar increíble para mencionarlo, ya que se supone que se centrará en las mejoras en el proceso de trabajo del equipo de todos modos.
También menciona el problema que tienen los Scrum Masters para informar sobre el progreso de la tarea. Esto es, por supuesto, problemático. El hecho de que la gente venga allí con necesidades directamente en conflicto con el propósito de la reunión crea un conflicto estructural que tiene que ser resuelto en el sistema (es decir, no es un problema de personas).
Finalmente, dijiste que están en proceso de transición. Hay dos cosas a considerar con ese hecho. En primer lugar, muchas empresas en transición buscan contratistas que tengan experiencia porque es una forma de inyectar nuevas ideas al grupo. Es posible que los encuentre más acogedores con su experiencia de lo que espera. En segundo lugar, estarán más abiertos a algunas ideas que a otras. Si ofreces una sugerencia y no la aceptan, consérvala para más tarde. No puedo contar la cantidad de equipos que he visto luchar contra una idea con uñas y dientes solo para amar la misma sugerencia unos meses después.
En mi opinión, las reuniones matutinas son actualmente la ruina de la industria tecnológica por la sencilla razón de que los gerentes (producto, proyecto o ingeniería) las convierten en reuniones de informes de estado. Todas las empresas en las que he estado han tenido ese problema. Incluso una reunión enérgica de 15 minutos puede convertirse en una rutina cuando algún desarrollador comienza a hablar: "luego agregué un punto final de API, luego agregué un nuevo correo electrónico, luego agregué un nuevo css...", mientras que el gerente está mirando atentamente ellos y asintiendo su comprensión. Es una pérdida de tiempo, dinero y cordura del desarrollador.
El problema subyacente es que los gerentes tienen incentivos para obtener informes de estado. No tienen ningún incentivo para llevar a cabo correctamente una reunión matutina de scrum.
Ya que no te aconsejaría que renuncies por esto, la única respuesta es sonreír y soportarlo. Puede tratar de hablar con los gerentes sobre esto, pero es probable que obtenga, en el mejor de los casos, vagas promesas de cambio, pero probablemente sin un cambio real.
rath
rath
paparazzi