¿Puede ocurrir burnout al hacer Scrum sprints continuamente? [cerrado]

De Wikipedia sobre burnout:"el burnout es en gran medida un problema organizacional causado por largas horas, poco tiempo de inactividad y vigilancia continua entre pares, clientes y superior"

También podrían tener una imagen de icono de Scrum junto a la definición de burnout.

Si crees que puedes enviar a alguien a otra cosa para una breve distracción para arreglar el agotamiento, obviamente no lo has pensado bien. Alguna vez ir de vacaciones después de ser quemado y volver al trabajo pensando, Wow! Ahora Estoy refrescado y listo para otros 6 meses de esta tortura hasta que finalmente tenga un descanso de nuevo. No, lo que pasa es que te das cuenta, Wow! Mi trabajo apesta. Ahora puedo ver cómo el estúpido proceso de micro-gestión y desarrollo de mi gerente es solo otra forma de obtener más de mí por menos y la vida es demasiado corta para esto... Debería encontrar algo más que hacer o cambiar de trabajo a algo menos estresante.

EN mi humilde opinión, el Scrum corto de 2 semanas debe prohibirse excepto en pequeñas dosis, no más de 4-8 en una fila. Úsalo como una herramienta para cosas excepcionales o críticas, no continuamente. Usa el sentido común.

Te estás agotando después de 36 semanas de duro trabajo; eso no es Scrum, eso es la naturaleza humana! Scrum no está ahí para hacerte trabajar más duro, está ahí para ayudarte a trabajar de manera más consistente y con mayor previsibilidad. A menudo veo a la gente confundiendo los síntomas de la gestión de proyectos normal con lo que perciben son síntomas de metodologías ágiles (es decir, "el cliente sigue cambiando los requisitos – debe ser culpa de Scrum!"). Sin embargo, es una distinción importante porque sin identificar la causa que no puede tratar los síntomas. Personalmente, estaría buscando formas de reducir el agotamiento, como las técnicas de manejo del estrés. Hay un montón de información sobre cómo tener éxito en un entorno estresante.

Un Sprint no es una carrera de 100 yardas; es una milla (aleatoria) en un maratón, es decir, un ritmo que puedes mantener indefinidamente.

¿Tu equipo está realizando retrospectivas al final de cada Sprint? Esta es la oportunidad para "inspeccionar y adaptar" su proceso? Como ScrumMaster, regularmente le pido al Equipo que califique cómo se siente el Equipo como entidad y si se están divirtiendo. Exploramos por qué o por qué no, y experimentamos con ajustes y alternativas.

En mi experiencia, el Equipo los miembros disfrutan (hasta un límite) de la "presión" que el Sprint timebox limita. La clave es acercarse a esa zona, pero no superarla. Según sea necesario, calibrar esa zona es un punto de control principal en una retrospectiva.

En cuanto a "... tiempo en un entorno Scrum que no está asignado / no rastreado para hacer algunas cosas menores y despejar la cabeza", manteniendo el compromiso del equipo en el x% de la capacidad disponible (puntos, preferiblemente, pero se pueden usar horas si es necesario; en cualquier caso he encontrado algo en el rango de 60-70% parece la norma) es clave para la sostenibilidad dentro de un Sprint, y un ocasional "día de código libre" funciona bien para Sprints externos.

No importa qué proceso de desarrollo estés usando, si el equipo se está quemando algo está mal. Puede ser tan simple como que las personas no se tomen el tiempo de vacaciones que necesitan, o podría estar en los detalles de cómo manejas tus scrums. Los equipos son efectivos a largo plazo porque todos obtienen el descanso que necesitan en el camino.

El equipo en el que estoy trabajando actualmente resuelve este problema muy bien. Después de tres sprints tenemos una semana en la que cada desarrollador puede trabajar en lo que quiere. Esos proyectos paralelos deben estar vinculados al valor comercial, pero no hay presión para lograrlo. Es una medida que nos permite a los desarrolladores explorar nuevas tecnologías, pero también nos proporciona una semana de trabajo más relajado y divertido.

Esto me ayuda a no quemarme.

Una solución es reducir el número de horas en el día dedicado al sprint.

Conozco a algunas personas cuyas jornadas de trabajo consistían en apenas dos horas y media de sprint, con el resto del día centrado en una variedad de otras actividades: apoyo, alivio de la deuda técnica, investigación, etc.. Su velocidad de desarrollo se estableció en consecuencia.

Eso puede parecer un poco extremo, pero si no me equivoco, era una empresa rentable hasta el reciente golpe de choque económico generalizado.

Entiendo completamente lo que estás diciendo. Para aquellos de ustedes que dicen "su ritmo es demasiado rápido", no estoy seguro de estar de acuerdo en que el ritmo siempre es el problema cuando las personas se queman por este proceso. Aunque hacer un seguimiento de todo tu progreso ES algo bueno, también puede ser un factor de estrés en sí mismo (y no hacer un seguimiento también puede ser), no solo porque tu jefe/PM estará contigo si ven que algo no va de acuerdo con el plan, sino para ti mismo. Solo tener esta información registrada es algo eso hará que la mayoría de la gente trabaje un poco más duro de lo que normalmente lo haría TODO EL TIEMPO y no estoy seguro de poner más tiempo en sus estimaciones de tiempo solucionará esto para todos. No creo que un motivador (como tu gráfico de quemadura) sea siempre positivo.

Algunas personas no se sentirán así, otras lo harán. No hay una forma de trabajo que se ajuste a todos. Nunca lo será, en mi opinión.

Además, si dices que estos métodos ágiles y sprints no son cada vez más efectivo / productivo, ¿por qué lo estás usando? ¿Por qué crees que las empresas quieren utilizar estos métodos? No es porque sean divertidos....

La efectividad/productividad siempre viene a algún tipo de precio, en mi opinión. No aparece de la nada simplemente usando los métodos mágicos (si entiendes mi punto).

La única manera de ser más efectivo (trabajo y presión) y hacer menos trabajo es hacer que otra persona haga el trabajo o automatizarlo.

En mi opinión, uno siempre debe revisar los procesos y ver lo que se puede automatizar y pasar tiempo en la automatización de sus procesos en su lugar. La automatización tiene el precio de hacer trabajo extra en lugar de hacer "el trabajo real", pero no importa cuán pequeña sea la tarea automatizada, siempre se beneficiará a largo plazo. ¡SIEMPRE! Si no un día, en dos. No un mes, dos. Ni un año, en dos años. Entiendes la idea.

Sin embargo, me gusta la idea de tener tiempo libre para trabajar en proyectos personales. La mayoría de las empresas nunca permitirá esto sin embargo. Pero tal vez usted puede persuadir a su empleador para obtener este tiempo para automatizar sus procesos y este trabajo podría estar "fuera del control de sprint" para permitir que el tiempo que está hablando para "descansar" y recuperar la energía para un nuevo sprint.

¡Estás en tu 18º sprint!?

Considerando 2 semanas por sprint, eso significa 36 semanas sin parar trabajando en el mismo proyecto. También comentas que trabajan alrededor de 6 horas cada día. ¡Eso suena como mucho!

No se mucho sobre metodologías ágiles (aunque en realidad estamos usando Scrum en nuestro proyecto actual), pero hay un principio sobre tus horas de trabajo (es decir, la cantidad de tiempo que pasas haciendo una tarea) debe ser del 60%~70%. Ahora, haciendo números de nuevo, si su trabajo el día dura 8 horas, y pasas 6 horas trabajando, realmente estás gastando alrededor del 75% de tu tiempo de trabajo. Esto podría ser una pequeña desviación que finalmente te ha hecho tener esa sensación.

OTOH, creo que si su proyecto va a tomar mucho tiempo para ser hecho, sprints deben ser más grandes, no 2 semanas, pero no un mes. Considere una curva descendente en su gráfico de agotamiento: Comience su sprint con una quema de tareas regular y reduzca su actividad en los últimos 2 o 3 días antes del sprint final.

Agile no es una piedra con el grabado:"trabajar más rápido/más fuerte/mejor/más duro", es más como un cielo azul con nubes blancas que dicen:"trabajar bien, hermoso más productivo". (un poco de jajaja al final cortesía de daft punk + radiohead).

El ritmo sostenible es un principio clave de la metodología ágil. Al hacer las prácticas de gestión (SCRUM) junto con las prácticas de ingeniería (XP), un equipo puede entregar sprint tras sprint indefinidamente. Sin embargo, porque uno puede no significa que uno debe.

Parece que necesitas un cambio contra la interminable cadena de sprints que ves delante de ti. Se pueden ofrecer varias opciones. Cada X número de sprints, un miembro del equipo (o pareja) puede rotar fuera de un equipo. Durante su rotación, usted puede apoyar el corre en equipo, toma una clase, concéntrate en un conjunto de picos, toma vacaciones, etc.

Si el equipo tiene 5 pares, y rotas a una persona fuera de la línea, una persona podría tomar una rotación fuera cada 10º sprint (si es una sola persona) o cada 5º iteración (si es una pareja). Los problemas de presupuesto y retorno de la inversión para sus actividades deberán ser abordados por su liderazgo y / o socio comercial. Pero claramente, tener un poco de tiempo para" afilar la sierra " traería beneficio al equipo por lo tanto el proyecto. Mantener la equipo fresco y centrado es una cosa muy buena. Pero debemos recordar, nos están pagando y tenemos que aportar valor por los dólares que ganamos.

Creo que te falta algo, pero no eres el único. Como dice Jim Highsmith: "La velocidad se está utilizando cada vez más como una medida de productividad (no la medida de calibración de capacidad que estaba destinada a ser) que centra demasiada atención en el volumen de puntos de historia entregados."

Supongo que eso es lo que le está pasando a tu equipo. Recomiendo leer este post seminal de Highsmith EN Mi Humilde opinión: La velocidad está matando la agilidad!