Métricas Kanban

Métricas Kanban

En este artículo exploramos las métricas clave de Kanban y explicamos cómo usarlas para mejorar el rendimiento de la prestación de servicio, incluidos consejos prácticos y consejos basados en nuestra propia experiencia de consultoría.

Métricas Kanban

La mayoría de las métricas Kanban son métricas tradicionales de Lean Manufacturing más algunas adiciones de la industria del software.

El objetivo de Kanban es mejorar la prestación de servicios y el foco está en el flujo de valor. Queremos ofrecer valor sostenible de forma rápida a los clientes con calidad y seguridad. Kanban se trata de diseñar y mejorar sistemas estables y predecibles para entregar a nuestros clientes productos de alta calidad a tiempo.

Entonces, eso es lo que queremos medir. En primer lugar, debemos definir el valor desde el punto de vista del cliente (este será el tema de otro artículo), luego implementamos un Sistema Kanban y comenzamos a medir los criterios de flujo, calidad y estado físico.

Previsibilidad

Si tu proceso es impredecible, es posible que no sepas que tú eres es el responsable de hacerlo de esa manera.

Quizás creas que la razón por la cual tu proceso es impredecible se debe a circunstancias completamente fuera de tu control. Sin embargo, eres mucho más culpable de lo que piensas.

Ya sea explícito o no, existen políticas que impiden específicamente que sea predecible. Por ejemplo, estás comenzando un trabajo nuevo a un ritmo más rápido que terminas el trabajo anterior, trabajas en demasiados elementos al mismo tiempo, ignoras las dependencias e impedimentos, o aceleras el trabajo que no necesita ser acelerado.

Pero todas esas políticas están bajo tu control.

Entre otras cosas, tomar el control de tu proceso significará analizar un conjunto diferente de métricas que las que tradicionalmente has estado observando. Esas métricas te dirán qué tan predecible es tu proceso y qué acciones tomar para mejorar.

El uso de las métricas Kanban sugeridas en este artículo te permitirá ver las políticas implícitas subyacentes que hacen que tu proceso sea impredecible y sugerirán cambios para mejorar la previsibilidad.

¿Cuándo estará hecho?

“¿Cuándo estará hecho?” Esta es la primera pregunta que tus clientes o stakeholders harán una vez que aceptes trabajar para ellos.

Previsibilidad en Kanban - Crystal Ball - AKTIA Solutions

Si tu proceso es predecible o no se juzgará por la exactitud de tu respuesta. Piensa cuántas veces te han hecho esa pregunta y cuántas veces te has equivocado.

Independientemente de la metodología que estés utilizando, si tienes dificultades para responder con precisión esa pregunta, debes echar un vistazo al flujo de tu proceso. Para ilustrar esto, lee las siguientes preguntas y piensa si aplican a tu contexto:

  • ¿Se te pide constantemente que comiences un nuevo trabajo antes de haber tenido la oportunidad de terminar el trabajo anterior?
  • ¿Se te pide constantemente que aceleres el trabajo nuevo además de realizar todo el trabajo actual de acuerdo con las estimaciones y compromisos originales?
  • ¿Cuántas funcionalidades comienzas pero no terminas porque se cancelan mientras estás trabajando en ellas?
  • Cuando algo en lo que estás trabajando se bloquea, ¿simplemente dejas de lado ese trabajo bloqueado y comienzas a trabajar en algo nuevo?
  • ¿Tus estimaciones tienen en cuenta cuántos otros elementos estarán en progreso al momento de comenzar a trabajar?
  • ¿Ignoras el orden en el que trabajas en los elementos actualmente en progreso?
  • ¿Agregas constantemente nuevo alcance o criterios de aceptación a los elementos en progreso porque es más fácil modificar una función existente en lugar de abrir una nueva?
  • Cuando un trabajo tarda demasiado en completarse, ¿alguna vez has dicho o escuchado a alguien decir “es simplemente más grande de lo que pensamos que era ” y/o ” se hará cuando se haga”?

Si alguna de las preguntas anteriores se aplica a su contexto, definitivamente tiene un problema con el flujo.

La causa fundamental de la imprevisibilidad es la falta de flujo. Veamos cuáles son las principales métricas de flujo y cómo usarlas para mejorar la previsibilidad y la entrega de su sistema.

Las Métricas Básicas de Flujo

Si tu proceso es impredecible, lo primero que debes investigar es un flujo deficiente. Un signo típico de un flujo subóptimo es una gran acumulación de trabajo en algún lugar de su proceso. Esta acumulación de trabajo se llama más comúnmente una “cola”. Las colas grandes generalmente significan flujo deficiente, tiempo de ciclo largo, imprevisibilidad, baja moral y mala calidad.

La consecuencia directa de las grandes colas es que el trabajo tarda más en completarse. La métrica de flujo que representa el tiempo que tarda el trabajo en completarse se llama Tiempo de ciclo. Cycle Time finalmente responde la pregunta de “¿Cuándo se hará?”

La consecuencia directa del aumento de los tiempos de ciclo es una disminución en el rendimiento. El rendimiento es la métrica que representa cuanto trabajo se completa por unidad de tiempo. Por lo tanto, una disminución en el rendimiento significa que se está haciendo menos trabajo. Cuanto menos trabajo se realiza, menos valor entregamos.

Para gestionar el flujo, necesitaremos monitorear de cerca esas tres métricas Kanban:

  • Trabajo en Progreso (la cantidad de elementos en los que estamos trabajando en un momento dado)
  • Tiempo de Ciclo (Tiempo de Entrega) (cuánto tiempo lleva a cada uno de esos elementos completar nuestro proceso)
  • Rendimiento (cuántos de esos elementos se completan por unidad de tiempo)

Tablero Kanban con Métricas Kanban - AKTIA Solutions

WIP, Lead Time y Throughput requieren muy poco tiempo recopilarse y ofrecen las mejores revelaciones sobre el estado general, el rendimiento y la previsibilidad de tu proceso.

Las respuestas a las preguntas esenciales de la ejecución predecible del proceso no se encuentran en los planes del proyecto, los cuadros de utilización de recursos o las estimaciones de los miembros del equipo. Las respuestas provendrán del monitoreo, medición y administración de un conjunto específico de métricas Kanban.

La pregunta del cliente “¿Cuánto tiempo tardará?” Se responde mejor con la métrica de flujo conocida como Tiempo de ciclo (Cycle Time o Lead Time). La pregunta del cliente “¿Cuántas funcionalidades nuevas voy a obtener en la próxima versión?” Es una pregunta que se responde mejor con la métrica de flujo conocida como Rendimiento (Throughput). El último de los tres, Work In Progress (WIP), no responde directamente a ninguna pregunta particular del cliente, pero es la métrica la que más influirá en los otros dos.

Trabajo en Curso

Trabajo en Curso (Work in Progress) son todas las unidades individuales de valor para el cliente que han ingresado en un proceso dado pero no han salido.

Para explicar esta métrica Kanban, usamos la metáfora de un sistema de colas simple:

Métricas Kanban - Sistema Kanban - Llegadas & Salidas

En un sistema de colas hay trabajo que llega a un proceso y hay trabajo que sale de un proceso. Al determinar si algo cuenta como en progreso o no, el primer aspecto del sistema que debe considerarse es ¿qué significa que algo haya “llegado”?

El equipo necesita definir un punto específico en el que una unidad de trabajo se transforme de ser solo una idea arbitraria (una opción) en un elemento de trabajo legítimo sobre el que se debe actuar y completar de inmediato.

Antes de ese punto de llegada, el artículo es solo un candidato para el trabajo. Después de ese punto de llegada, el artículo se cuenta como Trabajo en Curso. Este punto de llegada es lo que llamamos Punto de Compromiso en Kanban.

Work In Progress es la métrica de flujo más importante a monitorizar por dos razones:

  1. WIP es el mejor predictor del rendimiento general del sistema
  2. Las otras dos métricas de flujo, tiempo de ciclo y rendimiento, se definen en función del WIP.

Es tan importante que tiene una práctica de Kanban solo para ella: limitar el trabajo en progreso.

Para definir el trabajo en progreso, primero debemos acordar los límites de nuestro proceso. Es por eso que es tan importante y una de las primeras cosas que hacemos al diseñar un Sistema Kanban para establecer los límites de nuestro sistema.

En el otro lado del flujo, la salida se puede definir como la entrega a un usuario final real o la entrega a algún otro equipo o proceso intermedio.

El problema que tienen la mayoría de las empresas es un exceso de WIP, incluso aquellas que practican Agile desde hace tiempo. Un exceso de WIP disminuye la tasa de entrega, aumenta el time-to-market, reduce la calidad, aumenta el estrés y la frustración, conduce a una baja moral y baja calidad.

Tiempo de Ciclo

El Tiempo de Ciclo es la métrica Kanban que representa la cantidad de tiempo que un elemento de trabajo pasa como trabajo en progreso. En otras palabras, el tiempo transcurrido desde que el elemento de trabajo cruza el punto de compromiso hasta que cruza el punto de entrega.

Es importante definir el tiempo de ciclo en términos de los límites del sistema, porque ese es el lugar dónde tenemos influencia y podemos cambiar las cosas, fuera de esos límites no tenemos nada que hacer.

En otros de nuestros artículos verás que usamos el término Tiempo de Entrega (Lead Time) en lugar de Tiempo de Ciclo. No hay una razón específica para esto, y no queremos comenzar una discusión semántica aquí.

En otros de nuestros artículos verás que usamos el término Tiempo de Entrega (Lead Time) en lugar de Tiempo de ciclo. El tiempo de entrega (Lead Time) es el equivalente al tiempo de comercialización o tiempo desde el concepto hasta el efectivo (concept to cash). Algunos autores se refieren al tiempo de comercialización como Customer Lead Time o Tiempo de Flujo en lugar de Lead Time del sistema, que es el tiempo que un ítem pasa dentro del sistema Kanban. Otros autores se refieren al Lead Time del sistema como Tiempo de Ciclo, y aún otros diferencian entre Upstream Lead Time y Downstream Lead Time.

Puedes utilizar el que más te guste, siempre y cuando te asegures de que se calcula dentro de los límites del sistema.

Rendimiento

El Rendimiento es la métrica Kanban que representa la cantidad de WIP (cantidad de elementos de trabajo) completada por unidad de tiempo.

El rendimiento es una medida de la rapidez con la que los elementos salen de un proceso. La unidad de tiempo que elijas para la medición de tu rendimiento depende completamente de ti. Por ejemplo, Historias de usuario/Semana o Funcionalidades/Mes o Experimentos/Día.

La métrica de rendimiento responde la pregunta muy importante de “¿Cuántas funcionalidades voy a obtener en la próxima versión?”

Ley de Little

Las tres métricas Kanban de flujo están intrínsecamente vinculadas por una relación directa y poderosa conocida como Ley de Little:

Métricas Kanban - Ley de Little

Si alguna vez has visto la Ley de Little, probablemente la hayas visto en la forma de la ecuación anterior. Pero, la Ley de Little se estableció originalmente en una forma ligeramente diferente:

Métricas Kanban - Versión original de la Ley de Little

La Ley de Little original explica la relación entre el tamaño de la cola, el tiempo de espera y el tiempo de procesamiento.

La gran ventaja de la Ley de Little es la simplicidad general de su cálculo. Específicamente, si uno tiene cualesquiera dos de las métricas anteriores, entonces uno puede calcular fácilmente la tercera.

Observa también que la Ley de Little es una relación de promedios. La mayoría de las personas descuidan este detalle tan importante. El hecho de que la Ley de Little se base en promedios no es necesariamente bueno o malo. Solo es malo cuando las personas intentan aplicar la ley para usos que nunca se pretendieron.

Para aplicar la Ley de Little necesitas un sistema estable que requiere que algunos supuestos sean ciertos:

  1. La entrada promedio o tasa de llegada (λ) debe ser igual a la salida promedio o tasa de salida (rendimiento).
  2. Todo el trabajo que se inicia se completará y saldrá del sistema.
  3. La cantidad de WIP debe ser aproximadamente la misma al principio y al final del intervalo de tiempo elegido para el cálculo.
  4. La edad promedio del WIP no aumenta ni disminuye.
  5. El tiempo de ciclo, WIP y rendimiento deben medirse utilizando unidades consistentes.

Los dos primeros supuestos (# 1 y # 2) comprenden una noción conocida como Conservación del flujo. Los segundos dos supuestos (# 3 y # 4) hablan de la noción de estabilidad del sistema.

En otras palabras, si deseas ser predecible y predecir la entrega, debes tener un sistema estable que tiene que cumplir con esos supuestos (reglas).

Comprender los supuestos detrás de la ecuación es la clave para comprender la ley misma. Una vez que comprendas los supuestos, puedes usar esos supuestos como una guía para algunas políticas de proceso que puedes implementar para ayudar a la previsibilidad.

Después de estudiar la Ley de Little, debes darte cuenta de que si los tiempos de ciclo son demasiado largos, lo primero que debes considerar es reducir WIP.

Si deseas más detalles sobre cómo estas tres variables se relacionan entre sí y también una excelente explicación de los diagramas de flujo acumulativos, debes leer “Actionable Agile Metrics for Predictability” de Daniel S. Vacanti.

Las suposiciones como políticas de proceso

The real power of Little’s Law lies in understanding the required assumptions for the law to work. Because, every time you violate an assumption of Little’s Law your process becomes less predictable.

Podemos utilizar estos supuestos como base para algunas políticas simples que regirán el funcionamiento de nuestro proceso. Estas políticas servirán para controlar las cosas que podemos controlar y servirán para hacer que nuestro proceso sea más predecible.

Según los supuestos anteriores, algunas políticas de proceso que podrías implementar:

  • Solo comenzaremos un nuevo trabajo aproximadamente al mismo ritmo que terminamos el trabajo anterior. El famoso “DEJAR DE EMPEZAR Y EMPEZAR A TERMINAR” es una especie de eslogan para esta política.
  • Haremos todos los esfuerzos razonables para terminar todo el trabajo que se inicia y minimizar el esfuerzo perdido debido a los elementos de trabajo descartados.
  • Si el trabajo se bloquea, haremos todo lo posible para desbloquear ese trabajo lo más rápido posible
  • Llegaremos a acuerdos de nivel de servicio (SLA) entre diferentes equipos para asegurarnos de que las dependencias se gestionen adecuadamente y minimicemos el tiempo de espera para los elementos de trabajo en progreso.
  • Seguiremos de cerca nuestras políticas sobre el orden en el que extraemos elementos a través de nuestro sistema para que algunos elementos envejezcan innecesariamente.

La Ley de Little no es para hacer predicciones

La Ley de Little especifica una relación exacta entre el promedio de WIP, el tiempo de ciclo promedio y el rendimiento promedio, pero solo se aplica cuando se analizan datos históricos. La ley no puede usarse para hacer pronósticos sobre el futuro.

Por ejemplo, supongamos un equipo que históricamente ha tenido un promedio de trabajo en curso de 40 elementos de trabajo, un tiempo de ciclo promedio de 10 días y un rendimiento promedio de 8 elementos por día. No podemos afirmar que vamos a aumentar el promedio de WIP a 80, mantener el tiempo de ciclo promedio constante en 10 días y, mágicamente, el rendimiento aumentará a 16 elementos por día.

Todo lo que dice la Leey de Little es que un aumento en el promedio de WIP dará como resultado un cambio en el tiempo de ciclo promedio y/o el rendimiento promedio, y que la relación entre las tres métricas seguirá satisfaciendo la ley.

Si nuestro sistema se ajusta principalmente a todos los supuestos de la ley, podemos comenzar a confiar en los datos que estamos recopilando. Es entonces cuando nuestro proceso es probabilísticamente predecible. Una vez aquí, podemos comenzar a usar la simulación de Monte Carlo en nuestros datos históricos para hacer pronósticos creíbles.

Otra razón por la que no debemos usar la Ley de Little para hacer predicciones es porque representa una relación de promedios, y no debemos pronosticar basándose en promedios nunca.

De todos modos, ser predecible no se trata de hacer pronósticos. La mayor parte de la previsibilidad es operar un sistema que se comporta de la manera que esperamos. La previsibilidad es una propiedad de un sistema, no qué tan bien se puede predecir el futuro.

Métricas Kanban Adicionales

Echemos un vistazo a algunas métricas Kanban adicionales importantes. Estas métricas Kanban solo tienen sentido una vez que estás utilizando y dominando las tres métricas Kanban básicas que hemos explicado anteriormente.

Eficiencia de Flujo

La eficiencia del flujo es la métrica Kanban que mide el porcentaje del tiempo de entrega total que se utiliza realmente agregando valor (o conocimiento) versus espera.

Fórmula de la Eficiencia de Flujo

Es la relación del tiempo total transcurrido en que hemos trabajado activamente sobre un elemento respecto el tiempo total transcurrido que tardó en completarse un elemento (su tiempo total de ciclo o tiempo de entrega).

Esta métrica es de especial importancia ya que en la mayoría de las empresas el trabajo pasa mucho tiempo esperando y las personas frecuentemente realizan multitarea.

Cuando un elemento fluye a través del sistema, solo puede estar en dos estados. Se está trabajando o no se está trabajando. Ejemplos de un elemento en el que no se está trabajando son:

  • Está bloqueado por alguna dependencia externa (equipo, proveedor, etc.)
  • Está haciendo cola esperando.

Es bastante habitual que los equipos que recién comienzan a gestionar su flujo muestren eficiencias de flujo en el rango de 5% – 10%. Si una historia de usuario tardó 20 días en completarse y tuvo una eficiencia de flujo del 10%, eso significa que solo pasó 2 días siendo trabajada activamente y pasó 17 días en algún tipo de estado inactivo.

Esto es muy común en Scrum, ya que las historias de usuario que comenzaron al inicio del sprint tienen que esperar a que termine todo el lote para poder implementarse.

Si una historia de usuario tuvo solo 2 días activos de trabajo y estuvo 18 días inactiva, ¿dónde crees que deberías enfocar tus actividades de mejora de procesos? Probablemente va a ser muy difícil mejorar esos 2 días de tiempo activo, pero supongo que hay muchas oportunidades para mejorar esos 18 días. Cualquier reducción del tiempo inactivo, por definición, mejorará el tiempo de ciclo general. Mirar el tiempo de espera suele ser la mejor área, la más fácil y la más barata para investigar primero.

He tenido innumerables discusiones a lo largo de mi carrera con personas que argumentan que necesitan mejorar el desarrollo de software, por ejemplo, cuando solo echando un vistazo al Diagrama de Flujo Acumulativo para el proceso mostró claramente que el desarrollo de software ocupa solo el 5% del tiempo total transcurrido.

Deuda de Flujo (Envejecimiento del Trabajo)

La deuda de flujo ocurre cuando el tiempo de entrega se reduce artificialmente para algunos elementos de trabajo en progreso al “tomar prestado” el tiempo de ejecución de otros elementos de trabajo en progreso. Es una métrica Kanban muy importante, ya que es un indicador adelantado de la imprevisibilidad y del aumento del tiempo de entrega.

Algunos ejemplos de escenarios que conducen a la creación de deuda de flujo son:

  • Clases de Servicio
  • Bloqueos
  • Otro orden de políticas de pull vigentes (sean explícitas o no), como acelerar el trabajo, cambiar prioridades o cambiar objetivos

También nos referimos a la deuda de flujo como trabajo envejecido, lo que significa que un elemento ha estado en progreso por más tiempo que el tiempo de ciclo promedio. Cuando un artículo acumula deuda de flujo, de hecho está envejeciendo artificialmente. Como dijimos, esto sucede cuando el trabajo en progreso se deja de lado para trabajar en otros elementos que entraron al sistema más tarde.

Cuando el envejecimiento es mayor que el tiempo de entrega (Lead Time), es una señal clara de que tu sistema no es estable y no está fluyendo correctamente. Hay mucho trabajo que está esperando o al que se le bajado la prioridad, pero todavía están en el sistema consumiendo recursos, tiempo y complicando la entrega. Mientras tanto, otros trabajos en el sistema pasan mucho más rápido.

Pregúntate:

  • ¿Por qué entré ese trabajo en el sistema en primer lugar?
  • ¿Cuál es el criterio para comprometerse a entregar algo?
  • ¿Por qué ya no estamos trabajando en las tareas “viejas”?
  • ¿Qué nos impide terminar tareas “viejas”?
  • ¿Por qué mantenemos las cosas en progreso y las retrasamos? ¿Podríamos cancelar? ¿Podríamos entregar?
  • ¿Por qué estamos entrando más trabajos si todavía tenemos muchas cosas en progreso en el sistema?

Si estás utilizando alguna herramienta electrónica, puedes calcular fácilmente el envejecimiento. Si tu envejecimiento es mucho mayor que tu tiempo de entrega (Lead Time), ¡tienes un problema! En un sistema estable, el percentil 85% del tiempo de entrega y el percentil 85% del envejecimiento deberían ser similares.

Si no estás limitando correctament el WIP o tus políticas de programación no son explícitas, tendrás elementos de trabajo envejecidos que acumularán deuda de flujo.

Aquí hay algunas cosas importantes que debes recordar sobre la deuda de flujo y el envejecimiento de trabajo en Kanban:

  • Cuando el tiempo promedio de trabajo en progreso es mayor que el tiempo promedio de ciclo, entonces tu proceso está acumulando deuda de flujo.
  • Cuando el tiempo promedio de trabajo en progreso es menor que el tiempo promedio de ciclo, entonces tu proceso está pagando la deuda de flujo.
  • Cuando el tiempo promedio de trabajo en progreso es similar al tiempo promedio de ciclo, entonces tu proceso es estable desde una perspectiva de deuda de flujo.
  • La deuda de flujo conduce a la imprevisibilidad del proceso porque los elementos de trabajo que se permitieron envejecer artificialmente eventualmente abandonarán el sistema. Este envejecimiento artificial conduce no solo a tiempos de ciclo generales más largos, sino a una mayor variabilidad en el tiempo de ciclo. Que se reflejará en una cola más larga en tu histograma de tiempo de entrega.

Puedes medir la deuda de flujo para todo el sistema, pero si utilizas la herramienta electrónica adecuada, también podrás medir la deuda de flujo para cada etapa de tu proceso. Este es un indicador adelantado muy poderoso que te proporcionará información en tiempo real sobre la estabilidad de su sistema.

Tasa de Descarte

La tasa de descarte es la métrica Kanban que mide la cantidad de opciones que se descartan y, por lo tanto, se eliminan del proceso upstream, antes del punto de compromiso.

Puedes medir la tasa de descarte en cualquier etapa del proceso upstream. Piensa en ello como un embudo de opciones que se están desarrollando hasta que están listas para el desarrollo. En cualquier paso del proceso debe haber una cierta tasa de descarte.

Las organizaciones eficaces muestran altas tasas de descarte en todos los pasos del proceso upstream y los backlogs de los equipos no están saturados con cientos de opciones. Esta es una señal de que la compañía tiene un marco para el triaje upstream y los equipos pueden decidir claramente qué entra, qué no entra todavía y qué se elimina.

Por otro lado, las empresas con baja tasa de descarte generalmente están dirigidas por opiniones, intuición y no tienen un marco para desarrollar opciones y decidir en qué trabajar. Este es un indicador principal de que el proceso downstream será impredecible debido a la falta de flujo. Porque si no pueden gestionar las opciones de manera adecuada y descartar el trabajo inútil, también acelerarán el trabajo, cambiarán las prioridades, detendrán el trabajo en progreso mientras comienzan nuevo trabajo.

Bloqueos

Los bloqueos no son estrictamente una métrica Kanban, pero pueden proporcionar mucha información útil para reducir el tiempo de entrega y mejorar la previsibilidad.

Las dependencias y los bloqueos detienen el flujo normal de trabajo e introducen mucha variabilidad en el sistema. Algo que se evidencia con una larga cola en el histograma de tiempo de entrega.

La reducción de la longitud de la cola significará una previsibilidad mejorada, aunque no necesariamente un tiempo de entrega más corto.

Una práctica muy simple y útil que no practican muchos equipos es reunir a todos los bloqueos y revisarlos periódicamente para detectar patrones y oportunidades para reducir el riesgo de entrega del sistema. Esta técnica se llama técnica de agrupación de bloqueos y, si no lo estás haciendo, deberías incluirla como una práctica habitual en lugar de tantas retrospectivas inútiles.

Coaching con Métricas Kanban

Veamos ahora algunas de las herramientas y técnicas que utilizamos en nuestra práctica de Kanban coaching para ayudar a las empresas y equipos a mejorar su agilidad en la prestación de servicios mediante la monitorización de las métricas Kanban clave.

Diagrama de Flujo Acumulativo (Cumulative Flow Diagram)

Ahora, veamos qué es un Diagrama de flujo acumulativo (CFD), qué información puede proporcionar y cómo interpretar los resultados.

El CFD muestra las llegadas y salidas acumuladas a un proceso a lo largo del tiempo y, como tal, son una de las mejores herramientas disponibles para visualizar el flujo.

El diagrama de flujo acumulativo trata sobre llegadas y salidas. Es una excelente manera de visualizar el flujo de trabajo a través de un proceso. Son uno de los gráficos menos entendidos del mundo “agile”. Sin embargo, representan uno de los indicadores de rendimiento de proceso más potentes disponibles para nosotros.

Son una herramienta poderosa por un par de razones. Primero, estos gráficos ofrecen una visualización sucinta y consistente de las tres métricas Kanban de flujo que acabamos de presentar. En segundo lugar, ofrecen grandes cantidades de información en un vistazo.

No obstante, otra nota de precaución aquí. Los CFD solo se pueden usar para explicar el pasado y medir los primeros indicadores de cambios en el flujo, pero no se pueden usar para hacer predicciones o pronósticos de ningún tipo.

Métricas Kanban - Cumulative Flow Diagram

Visualizar el flujo a través de un CFD nos da una visión cuantitativa y cualitativa de los problemas en nuestro proceso. Obtener una comprensión del rendimiento real del proceso es uno de los primeros pasos necesarios para introducir la previsibilidad general del sistema.

El eje X representa la línea de tiempo del proceso. El eje Y representa el recuento acumulativo de elementos en el proceso en cada intervalo de reporte.

La línea superior de un diagrama de flujo acumulativo siempre representa las llegadas acumuladas a un proceso. El resultado final de un CFD siempre representa las salidas acumuladas de un proceso.

Las bandas, visualizadas con diferentes colores en el gráfico, representan las diferentes etapas en el sistema Kanban. Cualquier cosa que esté fuera de los límites del sistema Kanban no debe formar parte del CFD (por ejemplo, el Backlog).

Debido a su naturaleza acumulativa, ninguna línea en un CFD puede descender (disminuir). Si eso sucede, algo está mal. Si un elemento ingresa al sistema y luego se elimina inesperadamente, debes eliminar el elemento de tu herramienta de seguimiento o no tenerlo en cuenta al calcular el CFD.

Trabajo en Progreso en el CFD

La distancia vertical entre dos líneas cualesquiera en un CFD es la cantidad total de trabajo que está en progreso entre los dos pasos del flujo de trabajo representados por las dos líneas elegidas.

Tiempo de Ciclo Promedio Aproximado

La diferencia horizontal entre la línea superior de un CFD y la línea inferior de un CFD en cualquier punto del gráfico es el tiempo de ciclo promedio aproximado de tu proceso.

Aunque los elementos que comenzaron en la primera columna del tablero no son necesariamente los elementos que terminaron en la columna de salida, este cálculo aún producirá un Tiempo de ciclo promedio aproximado. Y cuán buena aproximación sea este cálculo dependerá de qué tan bien cumplamos con los supuestos de la Ley de Little.

Hay mucha desinformación sobre los CFD. Si investigas un poco sobre los diagramas de flujo acumulativo, probablemente encontrarás que muchas personas afirman que este cálculo de línea horizontal te dará un tiempo de ciclo exacto o el tiempo de ciclo promedio exacto. No es así. El motivo es obvio. Esto se debe a que los elementos que comienzan en la línea superior del Diagrama de flujo acumulativo (al comienzo de la línea horizontal) no son necesariamente los elementos que terminan en la línea inferior del Diagrama de flujo acumulativo (al final de la línea horizontal). Sin embargo, esta aproximación puede ser muy buena.

La comparación del tiempo de ciclo promedio aproximado del CFD con el tiempo de ciclo promedio exacto de los datos reales puede brindarte una visión tremenda de la salud de su proceso. Por ejemplo, si el tiempo de ciclo promedio aproximado es mayor que el tiempo de ciclo promedio real, significa que tu proceso está acumulando deuda de flujo.

Rendimiento Promedio

Si la línea inferior del CFD representa las salidas de tu proceso, entonces la pendiente de esa línea entre dos puntos es el rendimiento promedio exacto entre esos dos puntos.

Por lo tanto, si la pendiente de la línea inferior del CFD es el rendimiento promedio, entonces la pendiente de la línea superior es la tasa promedio de llegada. La pendiente de esa línea superior representa la rapidez con la que el trabajo ingresa a nuestro sistema, mientras que la pendiente de la línea inferior representa la rapidez con que el trabajo abandona nuestro sistema.

Interpretando CFDs

El CFD nos permite obtener una perspectiva general del flujo del sistema e identificar fácilmente patrones disfuncionales. Echemos un vistazo a algunos patrones comunes de CFD.

  • Llegadas y salidas no coincidentes: este es un patrón clásico que se produce cada vez que los trabajos llegan a nuestro proceso más rápido de lo que salen. La mayoría de las empresas que visito que tiene un problema de previsibilidad tienen un CFD con este patrón. ¿Por qué es tan malo? Cada vez que tenemos elementos que llegan a nuestro proceso más rápido que los elementos que salen de nuestro proceso, significa que WIP crecerá con el tiempo.
  • Líneas planas: otro patrón que buscamos en un CFD es cuando hay líneas que se aplanan durante largos períodos de tiempo. Estas líneas podrían representar períodos de cero llegadas o períodos de cero salidas.
  • Pasos de escalera: una transferencia por lotes en tu proceso se manifestará como “pasos de escalera” en el CFD. Esto es típico de los equipos Scrum, donde cada sprint se representa visualmente como un paso de escalera en el diagrama.
  • Bandas abultadas: cada vez que veamos una banda “abultada” en un CFD, indica claramente una explosión de WIP en ese paso de flujo de trabajo en particular. Esta es la formación de colas, que son indicadores principales de previsibilidad reducida y mayor tiempo de entrega.
  • Bandas que desaparecen: una causa de una banda que desaparece puede ser que cierta variabilidad aguas arriba (upstream) en nuestro proceso está causando la escasez aguas abajo (downstream). Otra posibilidad es que el equipo con frecuencia decida omitir un cierto paso en el flujo de trabajo, lo que da como resultado que ese paso no tenga ningún trabajo en progreso en un momento dado.

Histograma de Lead Time

El histograma de tiempo de entrega es la mejor herramienta que tienes para determinar la previsibilidad en la prestación de tu servicio. Cuanto más larga sea la cola, menos predecible será su entrega.

Veamos un ejemplo. ¿Cuál de los siguientes servicios es más predecible?

Comparando Histogramas para Previsibilidad - AKTIA Solutions

El servicio de la izquierda es más rápido ya que el 85% de sus elementos se entregan entre 0 y 12 días. El servicio a la derecha es más lento ya que el 85% de sus elementos se entregan entre 7 y 13 días. Sin embargo, el servicio de la derecha es más predecible porque la distribución del tiempo de entrega es más estrecha. El servicio de la izquierda, en cambio, tiene una cola larga y una distribución más amplia que lo hace menos predecible.

Agregación de Distribuciones

Histogramas como los de los ejemplos anteriores muestran la distribución del tiempo de entrega para todo el servicio. Sin embargo, si tu adopción Kanban está avanzando adecuadamente, tendrás diferentes tipos de elementos de trabajo o clases de servicio.

Si ese es el caso, te recomendamos que analices la distribución del tiempo de entrega por cada una de las diferentes clases de servicio y/o tipo de trabajo. En nuestra experiencia, eso te proporcionará información valiosa con respecto a los riesgos en la prestación del servicio, políticas implícitas de extracción y también formas de mejorar el flujo.

Histogramas por clases de servicio - AKTIA Solutions

Gráfico de Dispersión de Lead Time

La aleatoriedad existe en todos los procesos. Una de las mejores formas de visualizar la aleatoriedad en su proceso es colocar sus datos de Tiempo de entrega en un diagrama de dispersión.

Los diagramas de dispersión son uno de los mejores análisis para visualizar datos de tiempo de entrega (Lead Time). Este tipo de visualización comunica mucha información cuantitativa y cualitativa de un vistazo.

La forma de un diagrama de dispersión es:

  • El eje X representa la línea de tiempo del proceso.
  • El eje Y representa el tiempo de entrega para que se complete un elemento.

Gráfico de dispersión de Lead Time - AKTIA Solutions

Lo primero que podemos hacer para comprender mejor el rendimiento del tiempo de ejecución de nuestro proceso es dibujar las líneas de percentiles estándar en nuestro diagrama de dispersión.

La línea del percentil 50 va a representar el valor de un tiempo de entrega tal que si dibujamos una línea completamente a través del gráfico en ese tiempo de entrega, el 50% de los puntos en el gráfico caen debajo de esa línea y el 50% de los puntos están arriba esa linea.

En este ejemplo, la línea del percentil 50 ocurre a los quince días. Eso significa que el 50% de los elementos de trabajo que fluyeron a través de nuestro proceso tardaron quince días o menos en completarse. Otra forma de verlo es que cuando un elemento de trabajo ingresa a nuestro proceso tiene un 50% de posibilidades de terminar en veinte días o menos.

La siguiente línea que podría interesarnos es el percentil 85. Nuevamente, esta línea representa la cantidad de tiempo que le tomó al 85% de nuestros elementos de trabajo terminar.

En el ejemplo, puede ver que la línea del percentil 85 ocurre a los 51 días. Eso significa que el 85% de los puntos en nuestro gráfico están por debajo de esa línea y el 15% de los puntos en nuestro gráfico están por encima de esa línea. Esta línea de percentil nos dice que cuando un elemento de trabajo ingresa a nuestro proceso, tiene un 85% de posibilidades de terminar en 51 días o menos.

Los percentiles 50, 85 y 95 son probablemente los percentiles “estándar” más populares para dibujar.

Obviamente, a medida que aumentamos nuestro nivel de confianza, tenemos que aumentar la cantidad de tiempo que lleva completar los elementos de trabajo. Esto se debe a la variabilidad inherente a nuestro proceso. La “cola larga” en los histogramas.

Intepretando los gráficos de dispersión de Lead Time

Algunos patrones para buscar en diagramas de dispersión del tiempo de entrega:

  • Un patrón de triángulo que nunca se aplana, lo que significa que el tiempo de entrega aumenta continuamente probablemente debido a la deuda de flujo o una tasa de llegada más alta que la tasa de salida.
  • Acumulaciones de puntos, lo que significa que algo sucedió en algunos períodos de tiempo, como trabajar horas extras o demandas inesperadas con alta prioridad
  • Largos períodos en blanco en los datos, lo que significa que hay períodos de tiempo sin entrega, situación típica de los equipos de scrum o incluso situaciones peores.
  • Valores atípicos extremos, que deben analizarse para determinar la causa raíz y asegurarse de que no vuelvan a ocurrir

Simulación Monte Carlo

El análisis de Monte Carlo es una técnica matemática que encuentra patrones en los resultados de una ecuación dados valores de entrada aleatorios que están restringidos entre los valores probables del mundo real para esas entradas.

Se construye un modelo de software o simulación del mundo real, y las entradas probables (pero aleatorias) se introducen en este modelo miles de veces para encontrar patrones en los resultados.

Por ejemplo, si sabes que hay un centenar de historias de usuaris en tu próximo proyecto, y que a partir del historial (o estimación informada), sabes que el tiempo de entrega más corto es de un día y el más largo es de 5 días, entonces ejecutaríamos una simulación de Monte Carlo completando estas cien historias con un tiempo de entrega aleatorio entre uno y cinco días; y lo haríamos miles de veces

El resultado sería un histograma del tiempo total para cada ejecución simulada del proyecto.

Ejemplo de resultado de simulación Monte Carlo - AKTIA Solutions

Puedes construir estos modelos con hojas de cálculo o puedes usar herramientas específicas disponibles en el mercado para la simulación.

Una simulación de Monte Carlo siempre se ejecuta contra una variable de salida. En el ejemplo anterior, utilizamos la fecha de finalización, pero también puede modelar el número de historias terminadas en una fecha determinada.

Estableciendo una SLA (Service Level Agreement)

La transparencia es uno de los valores de Kanban. Entonces, una vez que conocemos nuestro desempeño y hemos definido nuestro conjunto de métricas Kanban, debemos hacerlas visibles para todos, acordar los SLA con otros equipos y partes interesadas y usarlos para mejorar continuamente.