Lamentablemente, este simple tema de asegurar que nadie trabaje muchas horas por día (más de 10 ó 12) en un equipo a veces no sucede. Cuando un equipo está atrasado con respecto a la planificación, la primera cosa con la que un líder novato (o no hábil) es presionar para que su equipo haga muchas horas de trabajo. En una organización de desarrollo, si un líder hace ésto alguna vez es inmediatamente puesto en la lista negra por la gente que lo rodea.
Sin embargo, en la misma organización de desarrollo, algunos desarrolladores pueden quedarse ellos mismos a terminar cierta cantidad de trabajo, aún si el líder no le pidío que lo haga. Esto suele estar bien bien visto. Se entiende que cuando estás programando una solución a un problema no querés abandonarlo por la mitad sólo porque son las 6 pm... pero a veces los desarrolladores se van de tema con esto.
De hecho, si estás en un proyecto de XP (o no), es mejor para vos que no trabajes muchas horas de más. Por ejemplo, si estás trabajando 12 horas todos los días en una iteración y terminás entregando 10 puntos en esa iteración, cuando el líder mire la velocidad anterior va a planear cerca de 10 ó 12 puntos de trabajo en la próxima iteración. Si esto pasa continuamente tu líder va a olvidar que ésto era sólo un excepción en una iteración en la que te mataste por 12 horas, y rápidamente se va a convertir en la norma. Un líder novato o poco orientado a las personas va a estar propenso en caer fácilmente en este error. La próxima vez, si estás de vacaciones por una iteración, la gente restante en el equipo debe alcanzar el mismo resultado al que llegaban con vos, lo que implícitamente significa que ellos trabajarán 12 horas o más.
Mientras que tu equipo (y la mayoría de los líderes) serán bien vistos por los stakeholders por tener terminado un montón de trabajo constante en una iteración, vos como desarrollador vas a sufrir de agotamiento. Y sabés bien que la próxima vez que no estés ahí tu equipo va a sufrir, ya que otros en el equipo pueden no estar preparados para una maratón de 12 horas.
De lo que estoy hablando acá es de como lograr un ritmo sostenible en el equipo. No sólo da predecibilidad para que la gente planifique sus iteraciones mejor, sino que también mantiene al equipo en marcha juntos por meses, sin agotarse.
Si sos desarrollador o líder, por favor no abuses de vos mismo o de tu equipo matándose de trabajo todas las noches.