¿Cómo detener / evitar Over Time en un equipo Scrum?

En realidad, estoy ayudando a una pequeña tienda de software en su Implementación Scrum. Recientemente, el Scrum Master me informó que tiene un problema porque el Equipo está trabajando a lo largo del tiempo para lograr el Alcance (Compromiso comprometido). Entonces tienen una velocidad irreal .

Mi pregunta formal es:

1. Además de hablar sobre la reunión retrospectiva; ¿Crees que es una buena idea implementar algunos bloques duros para evitar Over Time?

2. Si es así, ¿qué técnicas / herramientas sugiere?

   • Sistema de control de revisión (SVN, GIT, HG, etc.), bloques por horas (8 a 5)
   • ¿Bloques de estaciones de trabajo por horas (8 a 5) u horas acumuladas (hasta 8 horas / día)?
   • Otros)...

3. O, tal vez, no bloquee este tipo de cosas; pero implementa algún "sistema de penalización" por horas extra injustificadas ?

@Baqueta (y otros con preguntas similares): No, no se les paga por horas extra. Mi primer consejo para ellos fue revisar sus estimaciones porque tal vez estaban subestimando. Este fue mi consejo favorito:

Si tienen interés en trabajar horas extras, retírelo. El desarrollo no es algo que pueda hacer durante 60 horas a la semana y mantenerse productivo, y existen numerosos estudios que lo demuestran. Si el problema es el pago de horas extras, deshazte de él y mejora su salario base para que obtengan lo que valen.

Además, creo que el problema raíz (para este equipo) es una combinación de lo siguiente:

1. A los desarrolladores se les dice lo que deben lograr en un sprint / no se les consulta sobre lo que se puede lograr / se les ignora cuando dicen que hay demasiado trabajo.
2. Los desarrolladores están constantemente subestimando cuánto tiempo tomarán las tareas / cuántas unidades de trabajo están involucradas en cada tarea.

Resumen: hablaré con el Equipo para revisar sus estimaciones, y con el PO porque siento que no se les está consultando sobre el alcance, como usted mencionó.

Francamente, esos "bloques duros" que mencionas en el n. ° 2 son la peor idea que he escuchado en mucho tiempo. ¿Qué sucede si se encuentra un error de alta prioridad a las 4.45 p.m. y el tipo que tiene la capacidad de anular sus bloqueos está enfermo? En cuanto al número 3: sugieres castigar a las personas por hacer su trabajo .

Si el equipo está trabajando constantemente horas extras para completar sprints, entonces tienen interés en trabajar horas extras, por ejemplo, pago de horas extras o recuperar horas extras como vacaciones, o se están comprometiendo a hacer demasiado trabajo en los sprints.

Si tienen interés en trabajar horas extras, retírelo . El desarrollo no es algo que pueda hacer durante 60 horas a la semana y mantenerse productivo, y existen numerosos estudios que lo demuestran. Si el problema es el pago de horas extras, deshazte de él y mejora su salario base para que obtengan lo que valen.

Si hay demasiado trabajo en los sprints, esto generalmente es por una de tres razones:

1. A los desarrolladores se les dice lo que deben lograr en un sprint / no se les consulta sobre lo que se puede lograr / se les ignora cuando dicen que hay demasiado trabajo.
2. Los desarrolladores están constantemente subestimando cuánto tiempo tomarán las tareas / cuántas unidades de trabajo están involucradas en cada tarea.
3. Los desarrolladores siguen siendo arrastrados a tareas que no son parte del scrum.

Si es el # 1, lo estás haciendo mal . ¡No hay dos formas de hacerlo!

Si es el # 2, la causa habitual es la inexperiencia, ya sea haciendo estimaciones de tiempo o con el sistema que se está desarrollando. Una buena forma de evitar esto es dejar de hacer estimaciones de tiempo y comenzar a estimar 'unidades de trabajo'. Use alguna unidad abstracta, solo asegúrese de que no sean horas en tiempo real (en última instancia, todavía representa un intervalo de tiempo, ¡pero la abstracción es importante!). Luego puede comenzar a calcular cuántas unidades de trabajo realmente se realizan en una semana, luego configurar sprints utilizando esos datos.

Si es el # 3, debe comenzar a tener en cuenta esas otras tareas de alguna manera. Si es consistente, debería ser fácil de tener en cuenta (ver # 2 arriba). Si es frecuente pero impredecible, es mucho más complicado tratarlo. Querrá echar un vistazo a por qué está sucediendo (por ejemplo, errores graves en el código 'en vivo' => ¿su prueba es lo suficientemente exhaustiva?), Pero si eso no se puede solucionar, finalmente, scrum podría no ser el enfoque adecuado para usted. Mi equipo se cambió recientemente a Kanban por esta misma razón ...

Editar: Aclaró mi crítica de las ideas presentadas en la pregunta.

En primer lugar, parece que tuvieron demasiado trabajo en un sprint si tienen que trabajar horas extras para hacerlo. ¿Están registradas todas las horas? Si es así, podría contar cuánto trabajo real es un punto de historia y usar ese número para calcular el trabajo para el próximo sprint.

También es importante asegurarse de que el equipo entienda que solo se están dañando a sí mismos al tomar demasiado trabajo. Incluso el manifiesto ágil habla sobre un ritmo sostenible: "Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente". Trabajar horas extras todo el tiempo no es sostenible.

En general, sugeriría comunicación en lugar de fuerza y ​​penalizaciones. Me imagino que eso solo conduciría a la desmoralización del equipo.

Es probable que los desarrolladores que trabajan horas extras respondan a algún incentivo, ya sea real o percibido. El objetivo es eliminar el incentivo si es real o comunicar que un incentivo percibido no está operativo.

Cada límite duro sugerido tiene algunas soluciones u otros problemas. Los bloques de control de origen solo llevarían a los desarrolladores a mantener sus compromisos hasta que la ventana se abra nuevamente. Los bloques de la estación de trabajo tendrían que desaparecer tan pronto como hubiera algún problema de soporte o uno de los desarrolladores necesitara cambiar sus horas por alguna razón. Los sistemas de penalización solo conducirán a esconderse o enterrar horas extras.

Creo que el problema es más fundamental: el equipo tiene algún incentivo (o cree que tiene un incentivo) para trabajar horas extras.

Esto es lo que debe abordarse. ¿Están sus evaluaciones de desempeño vinculadas a sus números de velocidad? ¿La gerencia trabaja horas extras? ¿Se otorgan promociones y premios a quienes trabajan muchas horas? ¿Son contratistas a quienes se les paga por horas extras?

Simplemente dígale al equipo que no trabaje horas extras. Período.

Esto puede hacer que no puedan terminar algún trabajo. Eso no es un problema, es un punto de datos. Luego pueden usar ese punto de datos para planificar el próximo sprint. Nuevamente, no los deje trabajar horas extras. Ya sea que terminen o no, tienen otro punto de datos. Enjabonar, enjuagar, repetir.

No son necesarios trucos ni límites. Simplemente no trabaje horas extras. Aprende cuánto trabajo puedes lograr y ajusta tu planificación de sprint en consecuencia.

Tal vez hay un problema de no "cuánto" están trabajando sino cuándo. Esto puede ser un problema cuando hay un día de trabajo programado, pero gran parte de las horas normales se componen de reuniones y otras distracciones sociales y personales. ¿Están trabajando durante períodos de tiempo extra porque simplemente se sienten más productivos?

Reduzca la cantidad de trabajo en el sprint y comience a trabajar en el tiempo flexible. Permítales que entren más tarde. La persona a cargo solo debe decirle a la gente que se vaya a casa; todo está bien. Hay algunas culturas corporativas que crean un ambiente en el que salir temprano puede traer algunos ceños fruncidos.

Luché con esto cuando cambié por primera vez a scrum. Es natural querer hacer un esfuerzo adicional cerca de una fecha límite, pero scrum tiene fechas límite cada dos semanas, por lo que es un ajuste. Además de la sugerencia que otros han hecho para recortar los puntos de historia comprometidos en cada iteración, también sugeriría garantizar que las historias se desglosen lo suficiente, para que cada desarrollador pueda terminar al menos dos o tres en una iteración.

Eso no solo garantiza que cada desarrollador sienta que ha logrado algo en cada iteración, sino que también le da cierta holgura en su alcance. Cuando su quemado muestra que no podrá terminar una historia, puede sacarla y reasignar a las personas a las historias que se pueden terminar. Cuando las personas ven que el alcance puede ajustarse, es menos probable que se estresen por plazos poco realistas. Si comienza una iteración con cada historia en progreso, no tiene espacio para ajustes.

Un diagrama de flujo acumulativo ideal debería verse así si todos están terminando dos historias por iteración:

Nunca se ve así porque en realidad es muy difícil cronometrar que todas las historias terminen el último día mientras se mantiene a todos ocupados, pero es una buena regla general. Si está comprometido en exceso, el área roja será más grande y podrá eliminar historias. Si no está comprometido, el área azul será más grande y podrá agregar historias. Si sus historias son demasiado grandes, el área verde será más grande y debe dividir las historias.

Para evitar las horas extraordinarias, debe reducir el alcance del proyecto.

El siguiente cuadro muestra dónde reside la incertidumbre en un proyecto:

Si observa, en las fases de definición y requisitos del producto, tiene una gran variación en la estimación del esfuerzo. No puede estar seguro de si llevará un mes o un día implementar la función.

Apuesto a que ninguna de las tareas se realiza porque son simplemente demasiado grandes y no especificadas y hay demasiadas.

Si su equipo puede manejar 10 tickets en 5 días, y se les asignan 20 tickets, reduzca ese número, dele una patada al propietario del producto / gerente del proyecto / gerente / cliente y dígales que prioricen.

En este punto, esa es la única forma de salvar al equipo del tiempo extra. No puede entregar todo, pero cualquier cosa que entregue será menos probable que tenga errores.

También recomendaría buscar un nuevo trabajo y ayudar a sus compañeros de equipo a hacer lo mismo y arreglar sus currículums y carteras profesionales. Una empresa que espera horas extras es algo para lo que nadie debería trabajar y el software producido estará lleno de errores.

Aconsejo fuertemente contra "bloques duros". Dichos controles podrían percibirse como microgestión y podrían no abordar el problema subyacente.

Le sugiero que descubra por qué los programadores están trabajando horas extras. La respuesta puede sorprenderte. Parece que usted es un "extraño" (no un empleado de la empresa), y los programadores pueden estar dispuestos a ser sinceros con usted si se reúne con ellos en privado (uno a uno).

¿Es la razón para trabajar horas extras realmente la carga de trabajo, o es la razón más relacionada con la cultura o las expectativas?

Las razones de la carga de trabajo podrían ser

• El atraso comprometido es demasiado grande
• Los programadores o el propietario del producto están "dorados" (lo que hace que las funciones sean más complejas de lo necesario)

Las expectativas podrían ser

• Algún tipo de recompensa financiera o de reconocimiento por trabajar horas extras
• Miedo al fracaso. Los programadores temen que se verán mal o serán castigados si no cumplen con la fecha límite
• Los programadores están subestimando los efectos nocivos a largo plazo de trabajar horas extras.