¿Puede ocurrir el agotamiento cuando se realizan sprints de Scrum continuamente? [cerrado]

Estoy con una startup bastante pequeña y comenzamos a usar una forma de ciclo de desarrollo Scrum / Agile.

De muchas maneras disfruto Scrum. Tenemos sprints relativamente cortos (2 semanas) y me gusta el Burn Down Chart para seguir el progreso del equipo. También me gusta el panel de funciones, así que siempre sé qué debería hacer a continuación. Se siente bien quitar la carta de una característica del tablero, completarla y luego ponerla en la pila de quemado.

Sin embargo, ahora estamos entrando en nuestro ciclo de lanzamiento número 18 de Sprint y estoy empezando a sentirme un poco agotado. No es que no me guste el trabajo o mis compañeros de trabajo, es solo que estos sprints son ... bueno, sprints . De principio a fin, literalmente siento que estoy compitiendo contra el reloj para mantener nuestra velocidad de desarrollo. Cuando terminamos con el sprint, pasamos un día planificando el conjunto de funciones y las estimaciones del próximo sprint y luego nos vamos de nuevo.

Para las personas que trabajan en un proceso maduro de desarrollo Agile / Scrum, ¿es esto normal? ¿O nos falta algo? ¿Normalmente hay tiempo en un entorno Scrum sin asignar / sin seguimiento para hacer algunas cosas menores y aclarar su mente?

Esto es relativamente normal y, a veces, puede ser una queja de los miembros de nuestro equipo si los proyectos continúan durante un largo período de tiempo.

La clave de lo que estamos hablando aquí es un ritmo sostenible . Si usted y su equipo son capaces de mantener su ritmo a largo plazo, eso es excelente: ha logrado la hiperproductividad por la que se esfuerzan todos los equipos de Scrum.

Alternativamente, si encuentra que sobrestima la cantidad de trabajo que realmente puede hacer en un día, es posible que deba reevaluarlo durante su retrospectiva. La cantidad de tiempo productivo en un día que un equipo elige reconocer cuando realiza su planificación de capacidad para un sprint se denomina factor de enfoque .

Henrik Kniberg tiene esto que decir:

El factor de enfoque "predeterminado" que utilizo para los equipos nuevos suele ser del 70%, ya que ahí es donde la mayoría de nuestros otros equipos han terminado con el tiempo.

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Sin embargo, de lo que parece que estás hablando es simplemente del impulso ininterrumpido de sprint tras sprint, no necesariamente de tu productividad en un día. Aquí hay algunas sugerencias de cosas con las que hemos tratado de lidiar con eso:

• Termina el sprint un viernes por la mañana. Haga su revisión de sprint y retrospectiva por la mañana y deje que el equipo trabaje en otra cosa el resto del día para aclarar sus mentes. Retirar con planificación de Sprint el lunes.
• Introdujimos la noción de "días de laboratorio". Estos son días completos en los que el equipo se aleja del proyecto y pasan el día trabajando para mejorar sus propias habilidades técnicas a través de la investigación entre ellos y la colaboración en temas técnicos específicos. La mayoría de las veces no tienen absolutamente nada que ver con el proyecto específico y permiten que los miembros del equipo piensen en temas más ligeros.

De Wikipedia sobre el agotamiento: "El agotamiento es en gran medida un problema organizativo causado por las largas horas de trabajo, el poco tiempo de inactividad y la vigilancia constante de pares, clientes y superior"

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

Si cree que puede enviar a alguien a otra cosa para una breve distracción para arreglar el agotamiento, obviamente no lo ha pensado bien. ¿Alguna vez te vas de vacaciones después de quemarte y vuelves al trabajo pensando, Wow! Ahora estoy renovado y listo para otros 6 meses de esta tortura hasta que finalmente tenga un descanso nuevamente. No, lo que pasa es que te das cuenta, ¡guau! Mi trabajo apesta. Ahora puedo ver realmente cómo el proceso de desarrollo de microgestión de mi estúpido gerente es solo otra forma de sacar 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 por algo menos estresante .

En mi humilde opinión, el Scrum corto de 2 semanas debe estar prohibido, excepto en pequeñas dosis, no más de 4-8 seguidas. Úselo 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 arduo trabajo; eso no es Scrum, ¡es la naturaleza humana! Scrum no está ahí para hacer que trabajes más duro, está ahí para ayudarte a trabajar de manera más consistente y con mayor previsibilidad. A menudo veo personas que confunden los síntomas de la gestión normal de proyectos con lo que perciben como 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 no se pueden tratar los síntomas. Personalmente, estaría buscando formas de reducir el agotamiento, como técnicas de manejo del estrés. Existe mucha información sobre cómo tener éxito en un entorno estresante.

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 quiera. Esos proyectos paralelos deben estar vinculados al valor comercial, pero no hay presión para hacerlo. Es una medida que nos permite a los desarrolladores explorar nuevas tecnologías, pero también nos brinda una semana de trabajo más relajado y divertido.

Esto seguro que me ayuda a no agotarme.

No importa qué proceso de desarrollo esté utilizando, si el equipo se está agotando, algo está mal. Puede ser tan simple como que las personas no se tomen el tiempo de vacaciones que necesitan, o podría ser 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.

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

¿Su equipo está realizando retrospectivas al final de cada Sprint? ¿Esta es la oportunidad del equipo de "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, los miembros del equipo disfrutan (hasta un límite) de la "presión" que restringe el tiempo de Sprint. La clave es acercarse, pero no sobrepasar, esa zona. 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 / sin seguimiento para hacer algunas cosas menores y aclarar su mente", mantener el compromiso del Equipo al x% de la capacidad disponible (puntos, preferiblemente, pero se pueden usar horas si es necesario; en cualquier caso, he encontrado algo en el rango del 60-70% que parece la norma) es clave para la sostenibilidad dentro de un Sprint, y un 'día de código gratuito' ocasional funciona bien para Sprints externos.

Una solución es reducir el número de horas diarias dedicadas al sprint.

Conozco a algunas personas cuyas jornadas laborales consistieron en tan solo dos horas y media de sprint, con el resto del día enfocado 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 que golpeó la reciente conmoción económica generalizada.

¡¿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 trabajas alrededor de 6 horas diarias. ¡Eso suena a mucho!

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

OTOH, creo que si su proyecto va a tardar mucho en realizarse, los sprints deberían 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 de que finalice el sprint.

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

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 es siempre el problema cuando la gente se agota con este proceso. Aunque hacer un seguimiento de todo su progreso ES algo bueno, también puede ser un factor de estrés en sí mismo (y no hacer un seguimiento también puede serlo), no solo porque su jefe / PM estará sobre usted si ven que algo no está funcionando según el plan, pero para ti. El solo hecho de tener esta información registrada es algo que 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 que dedicar más tiempo a sus estimaciones de tiempo solucione este problema para todos. No creo que un motivador (como tu tabla de quemado) sea siempre positivo.

Algunas personas no se sentirán así, otras sí. No hay UNA forma de trabajo que sirva para todos. Nunca lo será, en mi opinión.

Además, si dice que estos métodos ágiles y sprints no se están volviendo más efectivos / productivos, ¿por qué los usa? ¿Por qué cree que las empresas quieren utilizar estos métodos? No es porque sean divertidos ...

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

La única forma de volverse más eficaz (en el trabajo y en la presión) y hacer menos trabajo es hacer que otra persona haga el trabajo o automatizándolo.

En mi opinión, siempre se deben revisar los procesos y ver qué se puede automatizar y dedicar tiempo a automatizar sus procesos. La automatización tiene el precio de hacer un trabajo adicional en lugar de hacer "el trabajo real", pero no importa cuán pequeña sea la tarea automatizada, siempre obtendrá ganancias a largo plazo. ¡SIEMPRE! Si no es 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. Sin embargo, la mayoría de las empresas nunca permitirán esto. Pero tal vez pueda persuadir a su empleador para que obtenga este tiempo para automatizar sus procesos y este trabajo podría estar "fuera del control del sprint" para permitir que el tiempo del que está hablando "descanse" y recupere energía para un nuevo sprint.

Esos fueron solo mis 2 centavos. Me asusta un poco cuando la gente dice que estos métodos no están aquí para hacernos más efectivos y trabajar más duro. ¡Por supuesto que lo son! Cuando no tenga rastro de lo que está haciendo, descansará cuando su cuerpo se lo indique. Cuando se rastrea "todo" que haces, te esforzarás. O me corrijo, la mayoría de la gente trabaja de esta manera, algunos descansarán de todos modos.

El ritmo sostenible es un principio clave de la agilidad. Al realizar las prácticas de gestión (SCRUM) junto con las prácticas de ingeniería (XP), un equipo puede realizar sprint tras sprint de forma indefinida. Sin embargo, porque uno pueda no significa que deba hacerlo.

Parece que necesitas un cambio frente a la interminable serie 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, puede apoyar al equipo de carrera, tomar una clase, concentrarse en un conjunto de picos, tomar 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 de la rotación cada décimo sprint (si es una sola persona) o cada quinta iteración (si es un par). Las cuestiones de presupuesto y retorno de la inversión para sus actividades deberán ser abordadas por su liderazgo o socio comercial. Pero claramente, tener algo de tiempo para "afilar la sierra" beneficiaría al equipo y al proyecto. Mantener al equipo fresco y concentrado es algo muy bueno. Pero debemos recordar que nos pagan 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 utiliza cada vez más como una medida de productividad (no la medida de calibración de capacidad que se pretendía que fuera) que centra demasiado la atención en el volumen de puntos de historia entregados".

Supongo que eso es lo que le está pasando a su equipo. Recomiendo leer esta publicación fundamental de Highsmith en mi humilde opinión: ¡La velocidad es matando la agilidad!