El principio, el medio y el final: Plazos largos en proyectos y sus problemas

¿Alguna vez has notado cómo una fecha límite aparentemente interminable puede, paradójicamente, hacer que sea más difícil hacer las cosas? Si bien puede parecer contradictorio, ampliar los plazos en los proyectos de software puede tener efectos negativos en la productividad. Comprender por qué sucede esto es crucial para optimizar el flujo de trabajo de tu equipo y entregar software de alta calidad a tiempo.

El principio, el medio y el final

“El principio, el medio y el final”, independiente del largo de la tarea, es claro que es posible distinguir estas tres partes. Con los plazos largos, inevitablemente, estas distinciones se estiran. Y, “en el medio”, se observa una caída significativa en la prodcutividad. El ‘Fin’ se convierte entonces en un período de actividad intensa y comprimida, lo que lleva a un progreso desigual a lo largo del tiempo asignado a la tarea. Este estallido final tiene consecuencias en la calidad y probablemente en el agotamiento cuando se repite el patrón.

Las iteraciones más cortas, al comprimir el  tiempo, intentan eliminar el “medio” en donde la productividad disminuye naturalmente. Idealmente, quisiéramos que los equipos experimentaran un ciclo constante de comienzos y finales.

¿Es dos semanas de duración el período ideal?

Es difícil decir cuál es el punto ideal de duración. En mi experiencia, el período ideal depende de elementos contextuales y ambientales en los que se inserta cada equipo. Ciertamente, las prácticas recomendadas han cambiado los consejos con el paso del tiempo (es decir, hace 15 o 20 años, la “norma” para Scrum era un ciclo de 30 días, ahora lo más frecuente es ver dos semanas). 

Este período de dos semanas se ha convertido en una fuente de Número mágico en metodologías ágiles. Algunas observaciones de por qué esto es asi:

1. Lapso de atención humana: El enfoque, y la motivación a menudo comienzan a decaer después de aproximadamente dos semanas de trabajo en un solo objetivo. Si bien la capacidad de atención individual varía, los sprints de dos semanas se han convertido en un período de tiempo práctico que funciona bien para la mayoría de los equipos.
   
2. Valor del feedback: El valor del feedback disminuye con períodos largos. Los comentarios recibidos después de dos semanas aún pueden influir significativamente en el valor de una tarea. El feedback recibido despues de un tiempo (15 días, tres eses) a menudo llega demasiado tarde para ser accionable.
   
3. Cierre Psicológico: Completar el trabajo crea recompensas psicológicas que alimentan la motivación. Las finalizaciones quincenales proporcionan dosis regulares de dopamina que mantienen el compromiso del equipo (solía haber un momento en el que mover Post-It notes en una pared daba una sensación de “tarea completada”, pero lo perdimos un poco con la llegada de herramientas soportan las metodologías ágiles).
   

Atención humana: el recurso crítico

Quizás el argumento más convincente a favor de las iteraciones cortas proviene de comprender la naturaleza del desarrollo de software como trabajo de conocimiento. 

Los plazos prolongados crean una ilusión de tiempo abundante que nuestro cerebro interpreta como un permiso para retrasar el esfuerzo concentrado. Necesitamos crear la “cantidad adecuada” de sentido de urgencia. Si estableces un plazo demasiado corto, tu equipo trabajará demasiado; si lo estableces demasiado largo, la sensación de urgencia comenzará a disminuir.

La conexión con la velocidad y las historias de usuarios

Aquí es donde se vuelve clara la conexión con las métricas ágiles. Velocidad –la capacidad de un equipo para entregar puntos de la historia—se estabiliza notablemente cuando las iteraciones permanecen consistentes. Con ciclos estables, los equipos desarrollan un sentido intuitivo de lo que “encaja” dentro de un sprint.

Mientras tanto, las historias de usuarios ganan disciplina a través de esta restricción. Cuando los equipos saben que deben completar el trabajo a intervalos regulares, naturalmente dividen los requisitos complejos en partes manejables. Este proceso de descomposición en sí mismo a menudo revela conocimientos sobre el dominio del problema que, de otro modo, podrían permanecer ocultos hasta la implementación.

¿Cómo puedo utilizar esta información?

Las implicaciones para su proceso de desarrollo son profundas:

1. Resistí la tentación de los plazos largos: Incluso para funciones complejas, mantené la disciplina de incrementos de entrega consistentes (¿dos semanas?). Dividiendo el trabajo en lugar de aumentando el tiempo.
   
2. Optimizar para completar: Asegúrese de que cada ciclo de dos semanas ofrezca algo de valor real. Las funciones a medio terminar en múltiples áreas brindan menos información que una sola capacidad completa.
   
3. Crear límites claros: Establecer rituales que marquen definitivamente el inicio y el final de cada ciclo, reforzando el poder psicológico de estos puntos de transición.
   

Cambiar a una metodología disciplinada y consistente (¿dos semanas?) representa un cambio fundamental en la dinámica del equipo, no solo un ajuste de programación. Esta transición es donde El coaching experto ofrece un valor excepcional..

Los equipos que implementan iteraciones cortas adecuadas experimentan inmediatamente los efectos positivos del feedback. ¿Sientes que tus iteraciones necesitan mejorar? ¿Está estancado el flujo de su proceso? Haga clic en este enlace para comunicarse y demos juntos el primer paso para romper esas barreras.