Métricas Kanban: cómo interpretarlas y buenas prácticas

Kanban es un método de trabajo, aplicado generalmente en equipos de servicio a cliente, que pone foco en la optimización del flujo de trabajo. Para ayudarnos a analizar cómo desarrollamos las actividades (que llamaremos PBIs, o Product Backlog Items) de nuestro trabajo, Kanban pone a nuestra disposición un conjunto de métricas que nos permitirán conocer, con datos objetivos y reales, cómo está funcionando nuestro flujo de trabajo. 

Métricas Kanban: cómo interpretarlas y buenas prácticas

En el artículo “Métricas Kanban: qué son y cómo te ayudan a optimizar tus procesos” explicamos cuáles son estas métricas, qué es lo que miden y para qué nos sirve conocer esos datos a la hora de buscar mejoras en nuestra manera de trabajar. 

Ahora, vamos a ir un paso más allá y veremos cómo interpretar esos datos. 

Ya estoy midiendo y tengo datos. Ahora, ¿qué hago con ellos?

Has estado utilizando las herramientas de gestión que tenéis en el equipo, te has tomado tu tiempo observando vuestro lead time, cycle time, WIP o throughput a lo largo del tiempo y has recogido los datos que te interesan. Ahora ha llegado la parte más difícil: analizarlos. ¿Por qué esos números son los que son? ¿Por qué han cambiado (o no) desde la vez anterior que mediste? ¿Qué ha ocurrido en nuestros procesos, en nuestro entorno o en nuestro equipo para que se den estos cambios? O, ¿por qué, si hemos hecho mejoras, no ha cambiado nada? 

Recuerda que esto es un proceso empírico, no quieres realizar interpretaciones al aire: quieres entender con certeza el porqué de esos números y, para ello, debes conocer y entender bien lo que ha ocurrido en ese período de tiempo. 

Antes de empezar, considera estos consejos: 

• Analizad y comentad los datos en equipo. Si analizas los datos solo, seguramente haya preguntas que no sabrás responder y necesitarás preguntar a tus compañeros. Además, la conversación que se abra en el equipo os abrirá los ojos sobre cómo trabajáis y entenderéis vuestro entorno y vuestros procesos con mucha más claridad. En serio, haz la prueba. 

• No compares nunca, jamás, los datos de las métricas entre distintos equipos. Cada equipo tiene unas tienen un alcance o complejidad diferentes. Los datos sólo deben compararse con otros datos pertenecientes al mismo equipo, para inspeccionar su mejora. 

• Busca siempre la causa raíz antes de tomar decisiones. Es peligroso tomar decisiones si no se conoce el contexto, y las consecuencias de hacerlo así pueden dar lugar a resultados peores. El dato obtenido, por sí mismo, nunca nos va a dar el origen del problema, sino que es un resultado objetivo que nos permite abrir una conversación con el equipo sobre qué ha ocurrido para buscar puntos de mejora entre todos. 

• Haz un buen uso de tus herramientas, o los datos no serán reales. Si no soléis actualizar adecuadamente las herramientas de gestión de trabajo es habitual que los datos que ésta devuelva sean falsos. Ten esto encuentra cuando los analices. 

• Sé paciente: las mejoras no llegan de la noche a la mañana. Seguramente tendréis que aplicar diferentes soluciones hasta dar con la adecuada, y eso llevará tiempo. Considerad también el punto en el que está el equipo para realizar estos cambios (y adaptarse a ellos), y tened también en cuenta los impedimentos de vuestro entorno, que no siempre será posible evitar. 

A continuación, revisaremos las métricas Kanban de las que estamos hablando. Te enseñaré varios escenarios bastante habituales en casi todos los equipos que impactan en los datos de cada una de esas métricas y que, probablemente, os pase a vosotros también. También compartiré algunos consejos a la hora de utilizar e interpretar dichos datos. 

MÉTRICAS KANBAN

Lead Time

Si observas que el lead time ha aumentado, puede significar que estéis poblando vuestro backlog con PBIs que no aportan valor inmediato, por lo que tardarán en priorizarse y, por tanto, en entregarse. 

En el caso de disminuir, seguramente los PBIs que habéis desarrollado en ese período de tiempo han sido creadas en el backlog recientemente. Esto suele ocurrir cuando el producto (o servicio) es nuevo y el backlog se está empezando a poblar. 

Tips:  

• Considera, al interpretarlo, el tiempo que los PBIs están despriorizados o, si tienes dependencias, ten en cuenta el tiempo que esos PBIs pasaron previamente por otros equipos. 
• No ignores el cycle time de esa actividad; no es lo mismo tener un lead time largo y un cycle time corto que al revés, aunque el tiempo total sea el mismo. 

Cycle Time

Cuando el cycle time aumenta significa que el período de desarrollo ha sido mayor al habitual (que no es lo mismo que el tiempo efectivo o real de desarrollo). Tu deber y el del equipo es conocer la causa (bloqueos, tiempo de aprendizaje sobre la actividad o sobre una herramienta nueva, exceso de reuniones…). 

Si se redujese, podría significar que los PBIs eran más pequeños de lo habitual o que los bloqueos y tiempos de espera se han reducido de nuestro Kanban. 

Tips:  

• Nunca sacrifiques o reduzcas el tiempo de las pruebas de calidad para reducir el cycle time y acelerar la entrega. Si lo haces, te arriesgas, entre otras cosas, a que esa actividad os sea devuelta. 
• Céntrate siempre en atacar la raíz del problema para eficientar el flujo, reduciendo bloqueos, tiempos de espera, desperdicios… si no lo haces, tus acciones no solucionarán el problema real. 

WIP

Si el WIP sube, quizás estéis intentando abordar más trabajo del que podéis. También puede significar que algunos desarrollos están bloqueados y que, mientras tanto, se han abierto nuevos PBIs. 

Si desciende, puede significar que no estáis cubriendo vuestra capacidad completa. Esto puede ocurrir cuando hay cambios en el equipo como, por ejemplo, en períodos vacacionales, por enfermedades y permisos o por nuevas incorporaciones. 

Tips:  

• Aunque parezca lo contrario, aumentar el límite WIP no hará que entreguéis más trabajo. Para un flujo de trabajo eficiente hay que centrarse en cerrar los PBIs en curso, no en abrir más. La ley de Little te lo explicará mejor. 

• Si quieres entregar más, reduce el WIP, pero no demasiado (seguramente no te ayude tener un WIP de 2 en un equipo de 9 personas). Tendréis que ir reduciendo y aumentando vuestro límite de trabajo en curso hasta que encontréis el que mejor se adapta a vuestra forma de trabajar.  

Throughput

Cuando el troughput aumenta, el equipo podría estar llegando a la etapa de madurez, habiendo optimizado sus procesos y alcanzado por tanto una velocidad de entrega mayor. También podría significar que los PBIs han llevado menos tiempo de desarrollo, por lo que se han podido entregar más, o que en ese período de tiempo los tiempos de espera han sido mínimos o nulos. O, simplemente, que estáis en un período de estabilidad. 

Si el throughput desciende, puede significar que los PBIs han tenido un desarrollo más complejo que ha llevado más tiempo, que habéis tenido más bloqueos o impedimentos de lo habitual, o que el equipo ha disminuido (vacaciones, bajas…). Podría ocurrir, además, en un equipo que esté realizando cambios y experimentos para adaptar su forma de trabajar. 

Tips: 

• Es tentador, pero no confundas el throughput con un indicador de desempeño. Un troughput alto, en comparación con uno más bajo, no significa que lo estéis haciendo mejor o que tu flujo de trabajo necesariamente se haya hecho más eficiente o que estés entregando más valor. ¿Qué te interesa más, entregar más PBIs o entregar más valor?

Sigue aprendiendo sobre Kanban

Para saber más visita nuestros cursos de Kanban Agilist.