Prácticas básicas para la administración de dependencias en un caso real

“Lo más difícil que hacemos es comunicarnos entre equipos”.  - Troy Magennis.

Intro

En ocasiones el trabajo no puede terminarse porque otra persona, área o departamento externo al equipo de trabajo no ha realizado su parte. El trabajo se atora y no avanza, se encuentra en espera o bloqueado. Estamos hablando de que existe una dependencia de un tercero para que el trabajo pueda avanzar. Utilizando el Diagrama de Flujo Acumulado e indicadores visuales de bloque (tickets o etiquetas rosas, para seguir el estándar de Kanban) es posible visualizar estas dependencias. Al revelar las dependencias los equipos pueden tomar acciones para que el trabajo avance. Para este caso en particular se narra la historia del mismo, cuál fue el punto crítico, y se sugieren acciones para lograr más tareas épicas terminada y lograr y mantener el flujo. Al final el trabajo terminado es el que aporta valor para todos los involucrados en el proceso.

El CFD de tareas épicas o pantallas refleja el estado general del proyecto

El proyecto comenzó a principios de Agosto de 2019. Lo primero que se realizó fue un análisis detallado de cada tarea épica (pantalla) y se desglosó en las diferentes tareas. Esto permitió hacer una estimación de esfuerzo muy certera. El proyecto debería de terminar en un mes y medio aproximadamente.

A mes y medio del inicio del proyecto, el estatus el día de hoy es de 6 tareas terminadas de 51, lo que representa el 12% del avance real.

En el siguiente Diagrama de Flujo Acumulado de tareas se puede observar que desde el día 30 de Agosto no hay un avance respecto a la tareas en la franja verde de trabajo terminado. La franja azul, que son tareas en el departamento de Aseguramiento de la Calidad (Quality Assurance) están prácticamente bloqueadas desde el 26 de Septiembre. El bloque se debe a que el cliente no ha proveído el entorno de pruebas.

Por otra parte la franja de trabajo en desarrollo ha ido creciendo (azul claro). Hasta llegar a 34 tareas épicas que por alguna razón, no pueden llegar incluso a Aseguramiento de la Calidad. Estas tareas están bloqueadas por la falta de alguna acción, principalmente de algún elemento a desarrollar por parte del cliente. Ya solo quedan 4 tareas épicas o pantallas que el equipo de desarrollo puede tomar. Pero estas tareas, lo más probable que ocurra es que queden bloqueadas en la franja azul o listas para testing en la franja azul cielo.

El equipo por parte del cliente no puede resolver todos los bloqueos a la vez. Un principio de Lean es “Dar mayor prioridad a terminar que a comenzar”. Por lo tanto las tareas que están más cerca de llegar a terminado son las que se encuentran en Aseguramiento de la Calidad. La acción por parte del cliente es proporcionar el entorno de desarrollo.

El punto de quiebre. No respetar los WIP limits.

Cuando se llegó al límite del trabajo en progreso, y la mayor parte de las tareas estaban bloqueadas el líder del equipo preguntó al Kanban Coach.

• ¿Qué hago ahora, que 8 de las 13 tareas épicas están bloqueadas?, ¿Esas las consideramos dentro del conteo de trabajo en progreso de la fase en turno?
• Así, es. Si no las consideras, que esfuerzo hará el equipo para administrar esos bloqueos o dependencias.
• Dejame ver, porque tenemos que seguir desarrollando.

El equipo tomó la decisión de ignorar el WIP limit. El punto clave de un sistema Kanban, es este
límite de trabajo en progreso. Si no pueden avanzar, porque el límite se alcanzó, ¿qué alternativas hubiera tenido el equipo? Una opción era pedir al cliente la liberación del entorno de pruebas antes de seguir avanzando para que las tareas épicas en aseguramiento de la calidad pudiesen avanzar. Incluso se podría haber ayudado al cliente a que el entorno de pruebas pudiera liberarse.

El comportamiento de equipo de desarrollo es racional. La política empresarial consiste en pagar por horas trabajadas. Por ello, el líder de proyecto desea que su equipo termine más tareas aunque se bloqueen más adelante. Si el equipo de desarrollo y el líder de proyecto no avanzan,  no se obtiene la productividad esperada y no hay pago. Esta política genera el comportamiento del equipo.

El pizarrón Kanban muestra bloqueos a nivel tarea

Por otra parte, el pizarrón Kanban, muestra la mayor parte de los tickets en las tres primeras
columnas con una etiqueta rosa. Esa etiqueta implica un bloqueo.

Reiterando, ya que el equipo de desarrollo por parte del cliente no puede resolver todos los asuntos a la vez. ¿Cuál es la mejor estrategia para llevar más tickets a terminado? La respuesta radica, en agrupar cada uno de los tickets para ver causas comunes. La dependencia que esté bloqueando más tickets es la que debe resolverse primero.



Nota. En la figura del tablero, es intencional que no se vea el detalle de las tareas, solo es una vista que da una idea sobre la cantidad de etiquetas rosas en las primeras tres columnas que tienen tickets. Es decir, la mayoría está bloqueado.

El CFD a nivel tarea muestra la eficiencia del equipo de desarrollo y como la tendencia es a entregar menos debido a los bloqueos

Estas son las tareas del equipo de desarrollo de software, a este nivel el proyecto parece avanzar sin problema. Aquí, el equipo ha mantenido la disciplina y tiene un límite de trabajo en progreso (WIP limit) y ha terminado tareas con una eficiencia mayor en la mitad del inicio del proyecto y con una tasa de entrega menor ,en gran parte por los problemas ya mencionados en párrafos anteriores.

En el siguiente diagrama puede verse como el proyecto se ha detenido. El backlog en las últimas dos semanas prácticamente se mantiene en el mismo status.

¿Qué podemos aprender de este caso?

• Primero. Respetar los WIP limits. El punto de quiebre del sistema fue el no respetar los límites de trabajo en progreso (WIP limits). Cuando las mayor parte de las tareas están bloqueadas, no tiene caso a llevar más tareas al estado de bloqueado. 
• El flujo importa. Si mejoramos la eficiencia del equipo de desarrollo, en lugar de mejorar la entrega al cliente la empeoramos. Principio de Teoría de restricciones: “Las eficiencias locales afectan de manera negativa al sistema. Debemos de buscar la eficiencia global”.
• Gestionar las dependencias. Para ello, la primera acción que deberíamos de realizar es alguna acción de trabajo que esté más cercano a llegar a terminado. Este trabajo es el bloqueo de las tareas de aseguramiento de calidad. Que en este caso, se deben a la falta del entorno de pruebas que el cliente debe proporcionar al proyecto.
• Un proyecto que se alarga afecta a todos los involucrados. Un tiempo de entrega que crece y crece afecta de manera negativa tanto a la empresa como al proveedor. El cliente no cuenta con el valor que la herramienta agrega valor a su negocio y el proveedor no puede finalizar, cobrar el proyecto y tomar nuevos proyectos.

¿Qué podemos hacer para mejorar el flujo?

• Tener mayor disciplina en el USO de límites de trabajo en progreso y gestionar las dependencias.
• Se puede proponer al cliente formación, cursos de certificación de Kanban, consultoría  para manejar un enfoque completo de entrega de valor. Al ser un cliente recurrente, es un beneficio para él y para la empresa. 
• Mostrar esta información en las juntas de status con el cliente y tomar acciones para eliminar dependencias.