¿La metodología Agile conduce a muchas reuniones inútiles y causa frustración entre los desarrolladores?

Gracias por el A2A.

Ya hay algunas respuestas geniales con las que estoy de acuerdo.

Especialmente la respuesta de Chuck Cobb lo clavó justo en la cabeza.

Entonces, ¿qué puede hacer para que sea más interesante para esos desarrolladores:

• Concéntrese en la funcionalidad, sin entrar en detalles demasiado
  A menos que sea necesario señalar exactamente algunos detalles importantes
• Prepare las reuniones para que la información conocida no se repita innecesariamente
• Asegúrese de que las cosas que deben ser discutidas / decididas por representantes de la empresa hayan sido discutidas / decididas antes de la reunión con los desarrolladores. Puede ser una pérdida de tiempo absoluta si los desarrolladores están viendo una discusión como si estuvieran viendo un partido de tenis.
• Informe a los desarrolladores con anticipación (con suficiente antelación) de lo que se discutirá en la reunión, para que puedan preparar detalles técnicos si es necesario.
• Piense detenidamente a nivel empresarial antes de discutir las características / funcionalidades deseadas con los desarrolladores , para evitar “soñar despierto sobre todo tipo de funcionalidades posibles que serían buenas” durante la reunión
• Asegúrese de tener una visión concreta del producto que pueda usarse como referencia para las características que se desarrollarán, para evitar un efecto jojo (una semana vamos a la derecha, la otra semana a la izquierda y así sucesivamente)

Cuando el tiempo de reunión se gasta sabiamente, estoy convencido de que la mayoría de los desarrolladores disfrutarán de las cosas que se discuten, porque a todos nos gusta participar en compartir información e ideas sobre nuestro trabajo y poder influir en lo que realmente tiene que ser hecho por nosotros mismos y nuestro equipo.

Creo que depende de tu perspectiva.

El Manifiesto para el desarrollo ágil de software favorece cosas como “individuos e interacciones”, “colaboración con el cliente”, ingenieros de software y partes interesadas de negocios trabajando juntos, y comunicación cara a cara para compartir información.

Si se hace bien y de manera consistente con los diversos principios de desarrollo ágil y esbelto, entonces no creo que las reuniones sean inútiles o frustrantes. Sin embargo, puedo ver a alguien que no siente la necesidad de colaborar con otras personas que se desconectan de las diversas reuniones y ceremonias que forman parte del desarrollo típico de Agile.

Agilidad significa flexibilidad. Sin embargo, no debería terminar en anarquía y caos. Por lo tanto, es bueno tener cierta estructura y, por lo tanto, algunas reuniones son útiles.
Si estas reuniones están causando frustraciones, será una buena idea que el equipo se una y haga un análisis rápido de cuáles son las causas reales de las frustraciones. A veces, no es la cantidad de reuniones, sino la forma en que se llevan a cabo, lo que causa frustraciones. Entonces, en lugar de llegar a conclusiones de que simplemente estamos teniendo demasiadas reuniones, sería bueno dar un paso atrás y tratar de encontrar por qué habíamos decidido tener esa reunión en primer lugar y por qué no queremos hacerlo ahora. . Probablemente, la causa raíz se encuentra en otro lugar. Después de eso, si se da cuenta de que alguna de las reuniones ya no agrega ningún valor y es un desperdicio, simplemente deshágase de ella.

Bien,

Cualquier método puede caer en un frenesí “no hecho bien”, así que,

Si su reunión satisface uno de estos problemas, entonces, algo anda mal.

• Sin informe de progreso (su equipo necesita actualizar Scrum 101)
• No hay problema / problema no encontrado (lo que puede significar que necesitamos más probador)
• Siéntate demasiado tiempo sin hacer nada (err, Scrum con 12 guiones y solo una persona que tiene final para decir cosas)
• Reunirse más de 15 minutos por guión (eso puede significar que la tarea de la unidad era demasiado grande de todos modos)

• 20% scrum cumple 80% charla (su equipo puede necesitar vacaciones)

Si y no.

Lamentablemente, muchas organizaciones que afirman ser “ágiles” hacen exactamente esto. Sé que suena falso, pero te lo prometo, no es así como queremos que se comporte una organización ágil.

Algunas organizaciones intentan cínicamente parecer algo ágiles. Algunos de ellos programan erróneamente un número ridículo de reuniones porque leyeron esto en un libro y no pensaron en lo que realmente significa. Recomiendo evitar esas organizaciones.

Cuando entreno a organizaciones que intentan “ser ágiles”, casi siempre tengo que enseñarles a tener reuniones más rápidas y efectivas. ¡Incluso les enseño a no tener reuniones, sino a trabajar juntas, a veces sin necesidad de una sala de reuniones! Tengo el objetivo de aumentar la comunicación entre los miembros del grupo. De todas las cosas que enseño a tales organizaciones, organizar reuniones rápidas y efectivas ocupa un lugar muy alto. Afortunadamente, no es tan difícil. Lea el libro de Patrick Lencioni “Death By Meeting” para algunas buenas sugerencias.

Si su organización “ágil” lo está enterrando en reuniones, entonces tienen algunas cosas que aprender. Yo puedo enseñarles También pueden otros, pero, por supuesto, me gusto. 🙂

No intrínsecamente. Nunca he programado reuniones recurrentes en grupos ágiles, siempre he limitado los asistentes a reuniones requeridos a personas con intereses en los resultados, y pongo todo lo que no está en la agenda publicada para más adelante cuando solo se necesitan personas afectadas / interesadas.

OTOH, una reunión diaria superflua es estándar en Scrum, que es la etiqueta más popular utilizada cuando las organizaciones intentan ser ágiles. Las personas no necesitan actualizaciones inmediatas sobre cosas que no les afectan. Por el contrario, las personas no deberían esperar hasta la reunión de mañana para actualizar a los compañeros de equipo sobre los problemas de bloqueo o la finalización de la dependencia. Una actualización electrónica semanal es suficiente para alentar un poco de competencia saludable en la velocidad, y significa que no hay cambios forzados de contexto o personas que retrasan el inicio de su próximo paso para evitar eso.

Otras reuniones son necesarias. La planificación de las reuniones es importante para garantizar que construya lo que es más importante para el negocio y satisfaga las necesidades de sus usuarios. Los leads técnicos y otros desarrolladores necesitan coordinar las interfaces entre los componentes para simplificar la complejidad general. Los ojos adicionales que miran cada diseño se simplifican para acortar los ciclos de desarrollo, evitar el esfuerzo desperdiciado e identificar problemas cuando todavía son económicos de solucionar. Las retrospectivas son importantes para cerrar los circuitos de retroalimentación para que los grupos puedan mejorar la próxima vez. Esos pueden alinearse con el inicio / entrega de características de cara al cliente o puntos de contacto internos significativos, en oposición a los límites fijos de sprint de 2 a 3 semanas.

Gracias por la A2A

Exactamente lo contrario, tendrá reuniones más cortas, conversaciones más cortas y más certeza, lo que lleva a lo contrario de la frustración del desarrollador. Si lo haces bien: todo el equipo tiene que estar comprometido y tener paciencia.

Cualquier cosa que no se use adecuadamente puede ser dañina. Lo mismo es aplicable a Agile.

La metodología ágil es una forma colaborativa de hacer cosas que enfatiza más en los individuos y las interacciones que en los procesos y las herramientas. Por lo tanto, el número de interacciones es mayor, también lo son las reuniones.

Hay diferentes tipos de reuniones que se realizan para diferentes propósitos. Cada reunión tiene un plazo aproximado dado.

El stand-up diario es una breve sesión para verificar si algún miembro del equipo se ha atascado en algún lugar necesita ayuda. Como equipo, si es necesario cambiar algo para lograr los objetivos de la iteración actual (sprint).

Si no se lleva a cabo correctamente, la reunión de pie puede seguir y seguir, lo que conducirá a una pérdida de tiempo. Si hay algo que necesita ser discutido entre los miembros, eso se puede hacer después del stand-up.

Otras reuniones tienen lugar mientras se planifica una iteración (sprint) y otra después de entregar una iteración (sprint). Estas reuniones son elaboradas, ya que son la clave para la ejecución de la iteración (sprint).

Agile capacita a los desarrolladores para entregar como un equipo sin muchos gastos generales de proceso y colaborar para lograr el objetivo colectivo.

La clave del éxito para Agile es qué tan bien el equipo está familiarizado con Agile y qué tan bien se unen como equipo. Eso sí, hay una velocidad de sprint que se decide por la capacidad del equipo para entregar, no un individuo.

Para aquellos nuevos en Agile, las cosas pueden ser difíciles al principio, pero a medida que progreses comenzarás a cosechar los beneficios. Un mentor con credenciales ágiles sólidas será de ayuda hasta que el equipo se sienta cómodo con los métodos ágiles.

No hay nada llamado metodología ágil. Existen algunos marcos y metodologías que siguen la forma ágil de trabajar.

¿De qué marco o metodología estás hablando?

Autor: El Manifiesto Ágil en inglés

Blog: Agile, Scrum, Kanban, Arquitectura de soluciones

Twitter: @tjain

Debería conducir a reuniones menos inútiles. Si las reuniones son inútiles, deja de hacerlo. Si los desarrolladores están frustrados, pregúnteles por qué y solucione el problema. Creo que muchas personas que hacen este tipo de preguntas quizás nunca trabajaron en un proyecto de Waterfall. Fácilmente diez veces más reuniones y frustraciones que los proyectos ágiles. ¿O tal vez están involucrados con una mala forma de Agile Cargo Cult?

De todos modos, inspeccionar y adaptar es clave aquí. Encuentre formas de mejorar las reuniones o deje de hacerlo.

Con una falta de experiencia y facilitación podría suceder. En caso de que quiera ser ágil y temer la frustración o las reuniones inútiles, vaya con scrum y obtenga un buen scrum master. Solo hay unas pocas reuniones regulares y todas ellas tienen un horario limitado. Con un buen scrum master, que sepa cómo facilitar y moderar las reuniones, esto no debería ser un problema.

Autor de The Agile Manifesto Unfolds y The Scrum Guide Unfolds

Blog Consultores Perdidos

En mi experiencia, todas las reuniones en las que se basa la metodología de Agile: reunión scrum, reunión de planificación de sprint, retrospectiva, etc., son beneficiosas cuando se realizan en un entorno de equipo ideal y con un propietario de producto / maestro scrum ideal. Sin embargo, estas reuniones se convierten en una gran carga de tiempo y son una causa importante de frustración en todos los casos que he visto en la vida real. La mayoría de los desarrolladores de software no son del tipo realmente sociable y social. Les gusta pensar y trabajar con código más que asistir a largas reuniones durante la semana.

Es lo contrario. Ni muchos ni inútiles: cada reunión de timeboxed despeja la niebla y, por lo tanto, funciona contra la frustración ya que los desarrolladores necesitan menos suposiciones para hacer su trabajo.

Es posible que termine una reunión antes, ya que todas las preguntas programadas se discuten positivamente.

Por cierto: ¿qué experiencias llevaron a su pregunta?

De ningún modo. Las personas que implementan enfoques ágiles sin una comprensión real de esto pueden verse fatigadas por las reuniones, pero Agile no se trata de reuniones, sino de entregar valor de manera eficiente a través de la validación y la retroalimentación. Alguien sin la mentalidad ágil puede ver las reuniones como malas, pero las reuniones bien administradas también pueden ser muy efectivas. De todos modos, cómo y por qué organizas una reunión y cómo mides el éxito y te ajustas según los hechos son más importantes que la cantidad de reuniones. Ningún equipo ágil bien dirigido se queja de las reuniones por mucho tiempo porque cuando la estructura no funciona, se adaptan.

Un método ágil muestra principalmente los desechos acumulados en el proceso que impiden la entrega de valor. Corresponde al equipo inspeccionar esto y adaptarse para eliminar ese desperdicio y ajustar el proceso.

He experimentado que los métodos ágiles generalmente reducen las reuniones innecesarias al tiempo que aumentan la comunicación y la colaboración. No estoy al tanto de su situación, pero si ve que tiene reuniones no deseadas en su proceso, es posible que desee trabajar con el equipo para identificar esto y ver cuál es la mejor solución para este problema.

Sus reuniones retrospectivas están ahí para este propósito.

No, las reuniones scrum están bien definidas para un propósito claro, por lo que está bastante bien.

No, a menos que alguien “asigne” desarrolladores a más de un equipo Scrum a la vez. Pero ese es un antipatrón simple con el que lidiar.