agile - metodologia - scrum master
¿Puede agotarse cuando se hace Scrum sprints continuamente? (11)
Tengo una startup bastante pequeña y comenzamos a usar una forma de ciclo de desarrollo de Scrum / Agile.
En muchos sentidos, me gusta Scrum. Tenemos sprints relativamente cortos (2 semanas) y me gusta el gráfico de quemaduras para seguir el progreso del equipo. También me gusta el tablero de funciones así que siempre sé lo que debería hacer a continuación. Se siente bien quitar una tarjeta de característica del tablero, completarla y luego ponerla en la pila de quemar.
Sin embargo, ahora estamos ingresando en nuestro 18º ciclo de lanzamiento 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 el sprint, pasamos un día planificando el conjunto de características y las estimaciones del próximo sprint y luego nos vamos de nuevo.
Para las personas que trabajan en un proceso de desarrollo de Agile / Scrum maduro, ¿es esto normal? ¿O nos estamos perdiendo algo? ¿Normalmente hay tiempo en un entorno de Scrum que no está asignado / no registrado para hacer algunas cosas menores y despejar la cabeza?
¡Estás en tu carrera número 18 !?
Teniendo en cuenta 2 semanas por sprint, eso significa 36 semanas de trabajo continuo en el mismo proyecto. También comenta que funcionan alrededor de 6 horas cada día. ¡Eso suena como 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 (es decir, la cantidad de tiempo que pasa haciendo una tarea) debe ser del 60% ~ 70%. Ahora, volviendo a hacer números, si su día de trabajo es de 8 horas y pasa 6 horas trabajando, realmente está gastando alrededor del 75% de su tiempo de trabajo. Esto podría ser una pequeña desviación que finalmente te hará sentir.
OTOH, creo que si su proyecto tardará mucho tiempo en completarse, los sprints deberían ser más grandes, no en 2 semanas, sino en un mes. Considere una curva descendente en su tabla de burnout: Comience su sprint con una quemadura de tareas regular, y reduzca su actividad en los últimos 2 o 3 días antes de que termine 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 dice: "trabaja agradable, hermosa más productiva". (un poco jaja al final cortesía de daft punk + radiohead).
Creo que te estás perdiendo algo, pero no eres el único. Como dice Jim Highsmith: "La velocidad se utiliza cada vez más como una medida de productividad (no como la medida de calibración de la capacidad que se pretendía) que concentra demasiada atención en el volumen de puntos de la historia entregados".
Supongo que eso es lo que le está sucediendo a tu equipo. Recomiendo leer la publicación fundamental de esta Highsmith en mi humilde opinión: ¡ Velocity is Killing Agility!
De Wikipedia sobre el agotamiento: "el agotamiento es en gran medida un problema organizativo causado por largas horas, poco tiempo de inactividad, y un constante control entre colegas, clientes y superiores"
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 por un breve desvío para arreglar el agotamiento, obviamente no lo has pensado bien. Alguna vez te vas de vacaciones después de haber sido quemado y volver al trabajo pensando: "¡Guau! Ahora estoy refrescado 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 microgestivo de mi estúpido gerente es solo otra forma de sacar más provecho 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, corto de 2 semanas Scrum debe prohibirse, excepto en pequeñas dosis, no más de 4-8 en una fila. Úselo como una herramienta para cosas excepcionales o críticas, no de forma continua. Usa el sentido común.
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 secundarios 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 proporciona una semana de trabajo más relajado y divertido.
Esto seguro me ayuda a no quemarme.
El ritmo sostenible es un principio clave de ágil. Al realizar las prácticas de administración (SCRUM) junto con las prácticas de ingeniería (XP), un equipo puede realizar carreras de velocidad después del sprint de forma indefinida. Sin embargo, porque uno no puede significar que uno debería.
Parece que necesitas un cambio en contra de la interminable cadena de sprints que ves delante de ti. Se pueden ofrecer varias opciones. Cada X cantidad de sprints, un miembro del equipo (o un par) puede rotar fuera de un equipo. Durante tu rotación, puedes apoyar al equipo de correr, tomar una clase, concentrarte en una serie de picos, tomar vacaciones, etc.
Si el equipo tiene 5 pares, y usted rota a una persona fuera de la línea, una persona podría tomar una rotación fuera de rotación cada décimo sprint (si es una sola persona) o cada 5ta iteración (si es un par). 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 algo de tiempo para "afilar la sierra" traería beneficios para el equipo y el proyecto. Mantener al equipo fresco y centrado es algo muy bueno. Pero debemos recordar, nos están pagando y tenemos que aportar valor por los dólares que ganamos.
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 llevar un registro de todo tu progreso ES una buena cosa, también puede ser un factor de estrés en sí mismo (y no mantener el rastro puede serlo también), no solo porque tu jefe / PM estará contigo si ven que algo no va de acuerdo al plan, pero para ti mismo. Simplemente tener esta información registrada es algo que HARÁ que la mayoría de la gente trabaje solo un poco más de lo que normalmente lo haría TODO EL TIEMPO y no estoy seguro de que dedicar más tiempo a las estimaciones de tiempo lo solucione para todos. No creo que un motivador (como su gráfico de reducción) siempre sea positivo.
Algunas personas no se sentirán de esta manera, otras lo harán. No hay UNA FORMA DE TRABAJO QUE SE ADAPTE A TODOS. Nunca lo será, en mi opinión.
Además, si dices que estos métodos ágiles y sprints no se están volviendo más efectivos / productivos, ¿por qué lo estás usando? ¿Por qué crees que las empresas quieren utilizar estos métodos en absoluto? No es porque sean divertidos ...
La efectividad / productividad siempre tiene 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 forma de que sea más efectivo (trabajo y presión) y trabaje menos es hacer que otra persona haga el trabajo o automatizarlo.
En mi opinión, uno siempre debe revisar los procesos y ver qué se puede automatizar y dedicar tiempo a la automatización de sus procesos. La automatización tiene el precio de hacer un trabajo extra 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. No 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 compañías nunca permitirán esto sin embargo. Pero tal vez pueda convencer a su empleador de que obtenga este tiempo para automatizar sus procesos y este trabajo podría estar "fuera del control de velocidad" para permitir que el tiempo en el que está hablando "descanse" y recupere energía para un nuevo sprint.
Esos fueron solo mis 2 centavos. Me da un poco de miedo 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" lo que haces, te obligarás a ti mismo. O me corrijo, la mayoría de las personas trabajan de esta manera, algunos descansarán de todos modos.
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 el ritmo sostenible . Si usted y su equipo pueden mantener su ritmo a largo plazo, eso es excelente: ha logrado la hiperproductividad que todos los equipos de Scrum están luchando.
Alternativamente, si descubre que sobreestima la cantidad de trabajo que realmente puede hacer en un día, entonces es posible que deba volver a evaluarlo durante su retrospectiva. La cantidad de tiempo productivo en un día que un equipo decide reconocer al hacer su planificación de capacidad para un sprint se conoce como un 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 es aquí 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 el ímpetu incesante del sprint después del sprint, no necesariamente tu productividad en un día. Aquí hay algunas sugerencias de cosas que hemos intentado tratar con eso:
- Termina el sprint un viernes por la mañana. Haga su revisión de sprint y retrospectiva en la mañana y deje que el equipo trabaje en otra cosa el resto del día para despejarse. Recoja con la planificación de Sprint el lunes.
- Presentamos la noción de "días de laboratorio". Estos son días enteros en los que el equipo se retira del proyecto y pasan el día trabajando en la mejora de sus propias habilidades técnicas mediante 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.
No importa qué proceso de desarrollo estés usando, si el equipo se está cansando algo está mal. Puede ser tan simple como que las personas no tomen el tiempo de vacaciones que necesitan, o podría ser en los detalles de cómo maneja sus 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 sostener indefinidamente.
¿Su equipo está realizando retrospectivas al final de cada Sprint? Esta es la oportunidad del equipo para "inspeccionar y adaptar" su proceso? Como ScrumMaster, regularmente le pido al equipo que califique cómo se siente el equipo como una 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 timebox de Sprint. La clave es acercarse, pero no superar, esa zona. Según sea necesario, calibrar esa zona es un punto de control principal en una retrospectiva.
En cuanto a "... el tiempo en un entorno de Scrum que no está asignado / sin seguimiento para hacer algunas cosas menores y despejar la cabeza", mantener el compromiso del equipo en x% de la capacidad disponible (puntos, preferentemente, pero pueden usarse horas) si es necesario, en cualquier caso he encontrado algo en el rango de 60-70% parece ser la norma) es clave para la sostenibilidad dentro de un Sprint, y un ''día de código libre'' ocasional funciona bien para Sprints externos.
Una solución es reducir el número de horas del día dedicado al sprint.
Conozco a algunas personas cuyos días de trabajo consistían en solo dos horas y media de carrera, con el resto del día enfocado en una variedad de otras actividades: apoyo, alivio de 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, fue una empresa rentable hasta que golpeó la reciente expansión económica generalizada.
Te estás gastando después de 36 semanas de duro trabajo; eso no es Scrum, ¡eso es la naturaleza humana! Scrum no está ahí para hacer que trabajes más duro, está ahí para ayudarte a trabajar de forma más consistente y con mayor capacidad de predicción. A menudo veo que las personas confunden los síntomas de la administración normal del proyecto 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 puede tratar los síntomas. Personalmente, estaría buscando maneras de reducir el agotamiento, como las técnicas de manejo del estrés. Hay montones de información sobre cómo tener éxito en un ambiente estresante.