Openness

Midiendo la eficiencia de nuestro flujo de entrega en Kanban (II)

En el artículo anterior, vimos qué tipos de métricas se podían definir para determinar si nuestro flujo de entrega de valor es eficiente, introduciendo los conceptos de Lead Time (tiempo de respuesta) y Cycle Time (tiempo de desarrollo). La siguiente pregunta que nos puede venir a la cabeza es cómo podemos obtener los valores de estos tiempos en nuestros flujos de entrega. La herramienta JIRA nos ofrece una serie de informes que nos permiten manejar fácilmente esta información.

En concreto, en este artículo vamos a ver el Control Chart. Esta herramienta de gestión no es una novedad introducida por Kanban, su aparición se remonta a los años 20 del siglo pasado, si bien no se popularizó su uso hasta los años 50 y 60, cuando se empezó a utilizar como una herramienta gráfica estadística que permite visualizar la diferencia entre las desviaciones naturales y especiales que aparecen en un flujo de entrega. Debido a ello, pronto se extendió su uso a Lean y Kanban, utilizándose para estudiar las variaciones del lead time, cycle time o la tasa de entrega en un periodo de tiempo, así como para visibilizar anomalías o la evolución del proceso de mejora. 

Con la ayuda de este gráfico podemos establecer el tiempo (de respuesta o desarrollo) máximo y mínimo, también denominados Upper Control Limit (UCL) y Lower Control Limit (LCL), entre los cuales se suelen mover las órdenes de trabajo de nuestro flujo debido a las variaciones naturales (o normales) del mismo. Todas aquellas órdenes que se muevan por encima del límite máximo o por debajo del límite mínimo, constituyen variaciones especiales u anomalías a estudiar.

Si trabajamos con JIRA, el Control Chart es uno de los informes que están asociados a los tableros Kanban. En función de los estados de nuestro flujo que consideremos, podemos configurar el gráfico para que, en el periodo seleccionado, nos muestre bien las variaciones de Lead Time (cuando tomamos los estados de nuestro flujo de extremo a extremo), bien las variaciones del Cycle Time (cuando tomamos solo aquellos estados que corresponden al trabajo del equipo sobre la orden de trabajo).

Vemos a continuación un ejemplo del gráfico generado por JIRA:

El gráfico muestra para el periodo y los estados considerados el tiempo medio (línea roja) y el tiempo medio móvil (línea azul). 

El tiempo medio se calcula como el promedio del tiempo de respuesta/desarrollo de todas las issues trabajadas en el periodo considerado.

 El tiempo medio móvil no se calcula en base a un periodo temporal sino que se calcula para cada orden entregada en el periodo considerando la ventana compuesta por las dos órdenes  inmediatamente anteriores, la propia orden y las dos órdenes inmediatamente posteriores. Este parámetro es, como su nombre indica, variable a lo largo del periodo considerado, siendo obvia interpretación de las variaciones que sufre:

          – Cuando disminuye en el tiempo, implica que el rendimiento del flujo está aumentando. Si aumenta, estaríamos en el caso opuesto.

          Por contra, si se mantiene más o menos estable significa que el flujo ha alcanzado un ritmo consistente en el tiempo. 

          Si el nivel que presenta el promedio móvil está muy por encima o por debajo de la media (línea roja), es posible que en el conjunto de datos del periodo considerado haya algún sesgo (existen anomalías en alguno de los extremos).

Para el tiempo medio móvil también se muestra la desviación típica (zona sombreada en azul) que, como indicamos en el artículo anterior,  es necesario considerar pues nos indica cómo se distribuyen los datos de nuestra muestra alrededor del valor medio, siendo, por tanto, una medida de la predictibilidad de nuestro flujo. Cuanto más estrecha sea la zona sombreada, menos variarán los tiempos de las órdenes de trabajo alrededor del promedio móvil, es decir, el flujo será más predecible y tendremos más certeza en lo que podemos tardar en concluir órdenes de trabajo futuras.

JIRA permite realizar un filtrado de las órdenes que queremos que se consideren o excluyan de la confección del gráfico, ya sea en función de su estado, como hemos comentado antes, ya sea por algún etiquetado que estemos aplicando a las órdenes que entran en nuestro flujo, etiquetado por el cual podemos definir un filtro que aplicar a la construcción del gráfico. Esto es muy útil para eliminar del cómputo órdenes de trabajo anómalas que introducen sesgos por distintos motivos:

Órdenes que han presentado un comportamiento extraño, generalmente por algún error humano. JIRA las denominada outliers.

Órdenes que, por sus valores extremos, pueden estar aportando un sesgo no deseado al promedio. Por ejemplo, las que entran duplicadas y que tienen un tiempo de procesamiento muy inferior a lo que es habitual. JIRA las denomina triage casualties.  

Otra utilidad de la aplicación de filtros es la obtención de gráficos particularizados para las distintas clases de servicio que podamos tener en nuestro flujo.

Por último, el gráfico también permite acceder al detalle de las órdenes que se han tomado en cuenta para su confección:

En un próximo artículo de esta serie, analizaremos otra potente herramienta de análisis, el diagrama de flujo acumulado (DFA o CFD en inglés), también disponible en JIRA y que permite analizar el nivel de estabilidad y la eficiencia de nuestro flujo.