Resumen: Todo el que alguna vez ha trabajo con Scrum, ha percibido esa sensación incomoda que se genera cuando al llegar a la daily scrum meeting tienes que decirle al equipo que tus tareas están en rojo.
Es una sensación incómoda y desde luego nada agradable y es tan incómoda para el Scrum Master como para la persona que no ha podido cerrar sus tareas.
El hecho de no haber cerrado una tarea un día concreto es algo que todos podemos entender. Todos tenemos días tremendamente productivos e improductivos, días en que estamos muy centrados y días en que estamos más dispersos (llevo un tiempo queriendo escribir un post sobre la raíz de los problemas del software; la autoestima, motivación y nuestro estado emocional) y siempre pasan cositas que nos impiden tener una jornada ideal. El problema real, viene cuando una tarea sigue en rojo día tras día.
Cuando te encuentres en esta situación que en definitiva significa que puedes incurrir en retrasos de cara al cierre de la iteracción tienes que tratar de paliarla a toda costa. A mi normalmente lo que me suele resultar es una sesión de pair programing. Normalmente involucrando a más gente se suele desbloquear. Una vez cerrada la iteracción y si en las reuniones diarias de Scrum no has identificado cual era el motivo principal por el cual la tarea no podía ser cerrada puedes volver a ella (si lo consideras oportuno) en la reunión de retrospectiva de la iteracción. Pueden ser mil cosas, por ejemplo (y esto sí que es grave) que la tarea no este correctamente dimensionada.
No obstante, de lo que me gustaría hablar es que en esta situación, siempre se responsabiliza al desarrollador de la ejecución de la tarea y retraso de la misma y es el desarrollador en el que termina la tarea a deshoras, sufriendo accesos de estrés etc. Este es un error gravísimo.
La responsabilidad del estado de las tareas (verde o rojo) es una responsabilidad compartida entre el Scrum Master y cada uno de los miembros del equipo.
Aunque en Scrum, cada miembro del equipo, elige que tarea realizar, ha de ser el Scrum Master el que tenga la última palabra y asegurarse de que una tarea concreta la va a realizar un miembro del equipo que sea capaz de cerrarla en el tiempo estimado. Uno de los factores de éxito de un proyecto desarrollado bajo el paraguas de Scrum, es la capacidad del Scrum Master para identificar que personas son más aptas para realizar una tarea concreta.
De ahí que tan importante sea conocer a tu equipo de desarrollo.
A deshoras 