Agile: El carril de items detenidos o bloqueados.

Muchos seguimientos de  proyectos tienden a ser optimistas, demasiado optimistas. No se contempla ni el desperdicio, el retraso o el trabajo detenido. Actividades que se detienen o quedan en espera se agregan al carril de cada desarrollador engordando el trabajo en progreso  artificialmente. Si hay muchos items en cada carril significa que todos están trabajando mucho. El tablero de actividades es importante, no para ver como se asigna el trabajo, sino para ver la situación actual del proyecto, sea buena o mala y así tomar decisiones. Un tablero que no refleja la realidad no sirve para nada. Cualquier decisión que se tome con una mentira solo producirá otra mentira.

Contar el trabajo detenido o en espera es importante.

Que el trabajo se detenga no es un asunto de ineficiencia o mediocridad, pasara en cualquier proyecto. Algunas actividades quedaran en espera por las circunstancias mismas del flujo de trabajo. Por ejemplo: si surge un incidente mayor productivo, es natural, incluso obligado que todo recurso en capacidad de ayudar a resolver el incidente este disponible para reducir el tiempo de caída. ¿Que sucede con las actividades en proceso?, se recorren o posponen, y esta bien. El trabajo que no esta siendo atendido debe ser catalogado como trabajo bloqueado o detenido. Si en el tablero de actividades no hay un carril especializado en trabajo detenido o bloqueado va a haber problemas.

Catalogar items bloqueados como “en proceso” es malvado.

Un item en algún proyecto que trabaje tenia la siguiente nota: Sigue en proceso, se pauso un poco para resolver un incidente. De la siguiente nota no se puede concluir nada, ¿que significa se pauso un poco?, si toda la atención del desarrollador fue para resolver el incidente, ¿cual fue el avance?. El item en cuestión estaba en las actividades en proceso del desarrollador. Si solo se ocupa un carril es complicado saber que se esta haciendo justo ahora. Esto se presta a ambigüedades y malos entendidos.

Tener muchas actividades en proceso no te hace mas productivo.

Puede causar inseguridad en algunos interesados del producto mover items de lugar o comunicar que algo no esta avanzando. Un carril de un desarrollador con una sola actividad puede verse mal en algunas empresas. Ya que hacer solo una cosa puede representar holgazanería en algunos casos. En realidad es lo contrario, decir que estas haciendo muchas cosas a la vez para poder tener una vía de escape cuando te pregunten: ¿en que estas? suena peor, no debes buscar verte ocupado virtualmente. Lo correcto es que los items de tu carril  reflejen las actividades que estas haciendo ahora, o lo que te dispones a completar en el sprint. Engordar tu WIP (trabajo en progreso) del tablero del proyecto crea desconfianza y en lugar de ocultarte te señala. Crea un carril de trabajo bloqueado y asigna los items a ese carril para dejar en claro en que estas.

El trabajo bloqueado es desperdicio.

Si tienes muchos items en progreso que llevan varios sprint arrastrándose tienes un problema, obvio, no están en progreso, se detuvieron hace mucho. Cada sprint en el que siguen vivos los esta haciendo mas costosos de pagar y con menos valor para el usuario. Si ya creaste un carril para mantener los items detenidos, entonces ¡felicidades!, tu trabajo de marcar los items como hechos o borrarlos del backlog acaba de empezar. Estos elementos una vez identificados deberían de tener prioridad alta para poderse deshacer de ellos cuanto antes. Si a nadie le interesa deshacerse de un item en concreto puedes regresarlo al backlog o borrarlo definitivamente.

El carril de bloqueados es una herramienta útil para detectar cuellos de botella.

Si el trabajo que se detiene tiene orígenes comunes o circunstancias comunes estas ante un cuello de botella que hay que remover. Por ejemplo: todas las adecuaciones de determinado cliente están en progreso desde hace 2 sprints, no se ha avanzado en la actividad debido a que el cliente en cuestión ha cancelado la reuniones varias veces. Bueno, el trabajo no es urgente, ni tampoco importante estos items pueden regresar al backlog con problemas para que los desarrolladores tomen items mas valiosos y que si puedan completar, ya habrá tiempo mas adelante para resolver esas adecuaciones.

Conclusiones.

El carril de bloqueados es mas afín a Kanban, otras metodologías ágiles no lo contemplan explicitamente, sin embargo lo veo como una herramienta útil a la hora de usar el tablero como herramienta de diagnostico y toma de decisiones del proyecto. Es tentador decir que algo esta en progreso cuando no lo esta, le da al programador un aura de multitasking, pero no es útil a la hora de llevar un proyecto. La atención de las personas es limitada, cada cambio de actividad o multitasking es costoso y representa desperdicio. Si el trabajo se detuvo, hay que marcarlo de ese modo, no es necesario inventar rebuscadas historias de porque algo que no esta en progreso, lo esta.

Autor imagen: Bernard Spragg. NZ