En esta nueva entrega, quiero presentar otra herramienta que se usa en sistemas Kanban para medir su eficiencia. Se trata del diagrama de flujo acumulativo o CFD por su nombre en inglés, y que se encuentra entre los que proporciona JIRA.

Este diagrama nos proporciona una representación de la evolución del estado de nuestro backlog, visualizando la fluidez de nuestro flujo de entrega de valor, es decir, mostrándonos su eficiencia. Igualmente, es una herramienta que nos va a permitir llevar un control de la evolución del equipo en el tiempo, evidenciando si las prácticas y procedimientos aplicados están funcionando o no, ayudándonos en nuestro proceso de mejora continua. En definitiva, es una herramienta que nos proporciona información sobre el funcionamiento de nuestro sistema, ayudándonos a tomar decisiones.

El eje horizontal es el eje temporal, mostrando generalmente una escala de días o semanas. En el eje vertical se presenta el contaje de órdenes de trabajo dentro del sistema. Dado que las órdenes pueden encontrarse en distintos estados dentro de nuestro flujo, se diferencian cada uno de ellos asociándoles un color, de manera que la evolución del backlog se presenta en forma de bandas de colores cuya anchura va evolucionando en función del número de órdenes que hay en cada estado en cada momento.

Este es el aspecto de un CFD generado por JIRA:

Huelga decir que el diagrama presenta la situación acumulada de nuestro sistema. Toda orden de trabajo entrante llegará a la banda Done (marrón) al cabo de un tiempo. Este periodo  dependerá de la complejidad de la orden, tras haber pasado las bandas intermedias. Por tanto, esta banda nunca disminuirá de anchura sino que irá aumentando a medida que el equipo va entregando (en un caso límite de no entrega continuada, su anchura se mantendrá constante pero no disminuirá).

¿Qué tipo de información podemos obtener de este gráfico?

Hagamos zoom al gráfico anterior:

Hemos marcado con una línea vertical roja un día determinado (día D). La anchura de la banda naranja, asociada al estado To Do, nos informa del tamaño de nuestro backlog pendiente en ese día concreto (son las órdenes que han entrado sobre las que aún no hemos comenzado a trabajar). De modo análogo, la anchura de las bandas situadas entre las bandas To Do (naranja) y Done (marrón), nos informan de la cantidad de trabajo en curso (WIP) que tenemos en ese día. La suma de ambos será nuestro backlog no entregado.

Vamos con las flechas horizontales. La longitud de la fecha marcada como tiempo de entrega nos informa del tiempo que la banda Done ha tardado en alcanzar el nivel de backlog no entregado que teníamos el día D, por tanto, mide el tiempo que se ha tardado en entregar un número de órdenes equivalentes a las que teníamos pendientes el día D. Recordemos que, en el primer artículo de esta entrega, definimos el Lead Time como el tiempo transcurrido desde que entra la orden de trabajo a nuestro sistema hasta que se realiza la entrega de la misma. Dado que en ese periodo de F-D días se han entregado n órdenes, dividiendo ambos parámetros, tenemos el tiempo de entrega medio en el periodo. Evidentemente, llegado el día F, podemos haber entregado exactamente todas las órdenes pendientes del día D, o algunas de esas, más otras que entraron después. El caso es que, independientemente de  cuándo entrarán, el día F tenemos la banda Done incrementada en un número equivalente al número de órdenes pendientes de entregar que había el día D.

La segunda flecha horizontal, marcada como tiempo de ciclo, nos informa del tiempo que la banda Done ha tardado en alcanzar el nivel de WIP que teníamos el día D, por tanto, mide el tiempo que se ha tardado en trabajar un número de órdenes equivalentes a las que teníamos en curso el día D (en el mismo sentido que se ha explicado antes). Como ya definimos, el Cycle Time es el tiempo transcurrido desde que empezamos a trabajar en una orden de trabajo hasta que la dejamos lista para su entrega (tiempo de desarrollo). Dado que en ese periodo de E-F días se han trabajado n órdenes, dividiendo ambos parámetros, tenemos el tiempo de ciclo (o desarrollo) medio en el periodo.

¿Qué tipo de estudios podemos realizar a partir de este gráfico?

Estudiando cómo varían las anchuras de las bandas a lo largo del tiempo, podemos saber mucho del funcionamiento de nuestro sistema:

  • En general, si una banda aumenta de anchura con el tiempo significa que el rendimiento de la fase asociada está cayendo, es decir, se está produciendo un cuello de botella en esa fase. Por razones obvias, esto no aplica a la banda asociada al estado final, Done.
    • Por ejemplo, si la anchura de la banda asociada a To Do no dejara de crecer en el tiempo, significaría que, con el dimensionamiento actual, no estamos siendo capaces de absorber toda la cantidad de trabajo que entra en el flujo, por lo que sería conveniente reforzar el equipo.
    • En las bandas intermedias entre To Do y Done, un aumento de anchura puede deberse a que la fase del flujo en cuestión no esté correctamente dimensionada para la demanda actual y se convierte en un cuello de botella, por lo que bien deberíamos revisar el límite de WIP de esa fase, o bien deberíamos dimensionarla correctamente (generalmente esto es más complicado).
  • Por contra, si una banda se estrecha paulatinamente en el tiempo, llegando incluso a desaparecer en algún periodo de tiempo, es indicativo de que el equipo está sobredimensionado en esa fase concreta del flujo. En el caso de que esto ocurriera en la banda To Do, implicaría que el sistema está sobredimensionado para la demanda real de trabajo que soporta.
  • Si la anchura de la banda se mantiene estable (o más o menos estable, pues siempre habrá fluctuaciones debido a la variabilidad de la complejidad de las órdenes que van entrando), significa que el sistema funciona a un ritmo estable y constante. En el caso concreto de la banda To Do, una anchura estable indicaría no solo una entrada regular de nuevas órdenes de trabajo, sino también un ritmo de absorción del trabajo entrante adecuado, pues de lo contrario la banda To Do crecería.
  • Los cambios bruscos en la anchura de una banda se suelen deber a eventos o situaciones no habituales: el equipo se ha redimensionado, el equipo ha revisado su límite de WIP, ha habido un cambio en la complejidad de las órdenes, se ha empezado a aplicar un nuevo procedimiento, etc.

Como a medida que pasa el tiempo, la banda Done crece y crece, suele ocurrir que su gran anchura termina dificultando mucho la observación del comportamiento del resto de bandas, mucho más estrechas. JIRA nos permite configurar el diagrama para mostrar u ocultar determinadas bandas. Si, por ejemplo, queremos centrarnos en el ciclo de desarrollo más que en la entrega, puede ser interesante eliminar la banda Done para ver más claramente el resto. Haciendo esto, el diagrama anterior se vería así:

Otro posible uso de este filtrado de bandas sería centrarnos en la banda To Do para analizar la evolución en el tiempo de la demanda (entrada de órdenes de trabajo) así como nuestra capacidad de absorción de la misma, de manera que podamos examinar si existe algún patrón temporal o estacional:

En este gráfico, correspondiente a un CFD de un equipo de mantenimiento de aplicaciones, se observa la presencia periódica de picos de entrada debido a la ejecución periódica de ciclos de regresión que generan la entrada de defectos a corregir.

Ya hemos indicado antes que la banda Done es un caso especial. Representa el trabajo entregado y, por ello, nunca puede estrecharse. El estudio de la pendiente del borde superior de esta banda nos informará de la velocidad con que cerramos las órdenes. Perfiles muy planos (casi horizontales) indicarán que la entrega se produce de una manera lenta, siendo posible que tengamos cuellos de botella en las fases previas. Por el contrario, perfiles más escarpados indicarán que la entrega es rápida. Por tanto, una manera de ver si nuestro equipo está mejorando en el tiempo es analizar si existen variaciones de pendiente de esta banda y cómo son. Por último, también podemos centrarnos en las métricas Lead time y Cycle time.

Como hemos visto, este diagrama nos proporciona la manera de determinar el valor medio de estas métricas en diferentes periodos y estudiar cómo están variando, convirtiéndose en una herramienta fundamental para optimizar la gestión de equipos y las cargas de trabajo.

También te invito a leer la segunda entrega de esta serie para así completar todo el ciclo.

Antonio Martín Vivas
Digital Banking Tech & Channel – Web Channel Scrum Master