Mejora continua con estas 2 métricas de Kanban: Touch Time y Lead Time.

¿Alguna vez te has preguntado por qué mides todo lo que te rodea y la importancia que tiene? Existen innumerables ejemplos en nuestra vida cotidiana: las interacciones positivas en redes sociales, como LinkedIn, nos indican qué contenidos son populares y cuáles no; los suscriptores de Netflix revelan el nivel de interés que tienen en una serie o película; el peso exacto de los ingredientes para una receta de Thermomix o registrar nuestros pasos diarios contribuye al seguimiento de mi actividad física.

Estos ejemplos demuestran cómo las métricas moldean nuestras acciones y decisiones. ¿Qué ocurre si tu pulsera de medición de pasos diarios te marcara que has bajado tu media en la última semana? Seguramente te propusiera como objetivo aumentar tus pasos en los próximos días.

De forma análoga, las métricas son útiles e igual de relevantes en el mundo del software, especialmente en equipos que utilizan Kanban para la gestión el flujo de tareas.

Para quienes no sepan qué es Kanban, y de forma muy resumida, es un marco de gestión del flujo de trabajo que se enfoca en mejorar la entrega y calidad de un servicio mediante una serie de prácticas como pueden ser la visualización de dicho flujo y la limitación del trabajo en progreso.

Si bien mi compañero Domingo Heras comenta algunas enfocadas a tu tablero kanban, yo quiero ir más allá y que persigamos juntos un objetivo: medir para tener equipos más efectivos y productivos.

Suena bien, ¿verdad? Pues te animo a seguir leyendo el artículo para que pongas en práctica dos métricas que te ayudarán en nuestro objetivo.

Touch Time

El Touch Time (también conocido como tiempo de toque) es el tiempo real invertido por el equipo en desarrollar un elemento de trabajo (de aquí en adelante, ítem por simplicidad). A diferencia de otras métricas, el Touch Time no tiene en cuenta los tiempos de espera o Wait Time, lo que le convierte en un indicador sólido de cuánto tiempo real se invierte en un ítem.

Es un desafío considerable la medición precisa del Touch Time. Aunque dispongas del mejor sistema de seguimiento de tiempo, es difícil ser rigurosos a la hora de registrar ese tiempo real invertido. La naturaleza humana puede complicar esta tarea: a más personas en el equipo, más probable es que se incrementen los errores al registrar el tiempo; o la subjetividad que puede haber en la interpretación de lo que es o no tiempo real. Pero como no todo es negativo, te invito a que exploremos cómo medirlo y no morir en el intento.

Estimaciones como punto de partida

Para incentivarte a usar esta métrica, te planteo un primer Touch Time simple. Usar como valor la estimación que como equipo hayáis dado para desarrollar el ítem.

Por ejemplo, si un ítem se estima en 10 días su desarrollo, su Touch Time se establecerá también de 10 días para completarlo. Cabe destacar que en este ejemplo, entendemos que el desarrollo de un ítem implica cuatro fases: análisis, desarrollo, pruebas y despliegue.

Aunque por supuesto no reflejará el valor real del Touch Time, sí que tienes datos suficientes para, por ejemplo, usarlos en los Replenishment meetings y realizar acciones al respecto: priorizar un ítem frente a otro o conocer antes de empezar un ítem lo que supone en términos de tiempo de desarrollo.

Por supuesto, de nada sirve esta forma de medir el Touch Time si no intentas ser cada vez más preciso en las estimaciones de cada ítem, realizando análisis posteriores que te sirvan de pivotes para futuras estimaciones.

Medir el Waste Time

Un paso crucial para acercarte a un Touch Time más real sería introducir el término Waste Time. La fórmula sería:

Donde:

• Tiempo desarrollo: el tiempo real de desarrollo del ítem.
• Waste Time: el registro de todo el “tiempo de desperdicio”.

Si tomamos como ejemplo un ítem que tarda 15 días en desarrollarse, pero que hubo “tiempo de desperdicio” por valor de 2 días, su Touch Time sería de 13 días.

Ahora profundicemos en el término Waste Time. Se entiende como la suma de todas las veces que un equipo dejó de trabajar en un ítem, todo tiempo que no aporta “valor real” para completar dicho ítem. Este desperdicio de tiempo se puede dar en multitud de distintos escenarios. Por ejemplo:

• Esperas o bloqueos por falta de requisitos o necesidades con terceros. Estos retrasos pueden detener el flujo de trabajo y reducir la eficiencia general del proceso.
• Revisiones de código. Si se vuelven excesivamente largas o repetitivas, pueden consumir tiempo valioso que podría destinarse a tareas más productivas.
• Implementar características que el cliente no ha solicitado. Es fundamental enfocarse en lo que agrega valor real al proyecto.
• Reuniones ajenas al ítem. Las reuniones que no están directamente relacionadas con el ítem en desarrollo pueden generar interrupciones y desviar la atención del equipo de las tareas cruciales.
• Rellenar formularios para validaciones burocráticas.
• Documentar funcionalmente el software.
• Cambios de contexto en el proyecto. Cambiar constantemente entre diferentes tareas incrementa el tiempo invertido en el cambio de foco.

Es relevante notar que las actividades citadas no tienen por qué ser negativas o inútiles. Necesitas hacerlas visibles para tomar acciones al respecto. En términos generales, tu preocupación debe ser minimizarlas en la medida de lo posible para así maximizar el tiempo en el que estás aportando valor real a un ítem.

A pesar de esta nueva forma de cálculo del Touch Time incluso a mí mismo me surgen preguntas como: ¿La daily es un “tiempo de desperdicio“? Te diré que sí, porque estar reunido en general no es tiempo invertido en el avance del ítem. O ¿Y si cambio de foco y me pongo a trabajar en otro ítem? Sin entrar en el concepto pull de Kanban, sí, también es tiempo “muerto”.

Touch Time por etapas

Una vuelta de tuerca más sería tener Touch Time por etapas. Así podrás conocer el trabajo real que haces en cada una de las fases que junto a tu equipo has definido hasta completar un ítem y poner foco en mejorar la eficiencia de cada una de dichas fases.

Imagina un ítem que transita en su flujo de trabajo por las siguientes fases: análisis (2 días), desarrollo (5 días), pruebas (2 días) y despliegue (1 día). Simplemente, esa duración de tiempo para cada fase serían sus Touch Time. El valor total para el ítem sería la suma de todos los Touch Time, 10 días.

Mediante esta medición puedes detectar si tienes un Touch Time muy alto en fase de análisis porque no hay un procedimiento claro para completar la fase; o todo lo contrario, es muy bajo el Touch Time en fase de desarrollo porque no has incluido validaciones como las revisiones de código por parte de otros compañeros de equipo.

Touch Time promedio

Y para terminar con las fórmulas de Touch Time, si lo que quieres es obtener el promedio con una colección de ítems, la fórmula es:

Si tomas un conjunto de 10 ítems y calculas su Touch Time individualmente, podrías obtener un conjunto de valores que varían desde 3 días hasta 15 días. Si calculas el Touch Time promedio de estos 10 ítems, obtendrás un valor que refleja el tiempo medio que se dedica a completar un ítem en el equipo.

Lead Time

El tiempo es un recurso valioso, que debemos medir para gestionarlo de la mejor forma posible. Nuestra capacidad tanto de medirlo como de comprenderlo nos garantiza cumplir con las expectativas del cliente.

La segunda métrica que te propongo, clave en este sentido, es el Lead Time. Se puede definir como el tiempo que tarda un ítem desde su inicio hasta su fin. Aunque esta definición es demasiado generalista, me detendré más adelante en acotarla para una comprensión más profunda.

Medir el Lead Time es esencial porque permite evaluar la eficiencia del flujo de trabajo en Kanban, en términos de cuánto tiempo tardas en entregar un ítem, y así establecer expectativas realistas. Es un indicador de valor que, en la mayoría de los casos, cuánto menor sea mejor es para el cliente.

Y al igual que ocurre con el Touch Time, debes ir paso a paso a la hora de usar esta métrica. Y en concreto, hay dos Lead Time que me gustaría explicarte.

System Lead Time

El System Lead Time se define como el tiempo que transcurre desde que un ítem entra en tu flujo de trabajo Kanban de tu equipo de desarrollo hasta que el mismo sale. Dicho de otra forma, es el tiempo que empleas en dicho ítem desde que está disponible para trabajar en él hasta que está listo para ser entregado al cliente.

Como cada flujo de trabajo es distinto, es necesario indicar qué definición tienes con tu equipo. Si continuamos con el ejemplo para la métrica del Touch Time, podemos decir que tu flujo de trabajo es el siguiente:

En este caso, tu System Lead Time es el tiempo que empleas desde que el ítem está listo para trabajarse en su fase de Análisis hasta que finaliza la última fase, Despliegue.

Normalmente, los equipos de desarrollo incluyen un estado previo, comúnmente conocido como ‘Por hacer’. De esta forma, además puedes saber la cantidad de ítems que están esperando para ser trabajados, pero que ya entraron en tu sistema.

Customer Lead Time

El otro Lead Time que me gustaría explicarte es el Customer Lead Time. Se trata del tiempo desde que el cliente realiza la petición del nuevo ítem hasta que está totalmente operativo y disponible para ser usado. Este Lead Time se sitúa en un plano superior al System Lead Time.

Tiene en cuenta el tiempo previo desde la petición del ítem hasta que está listo para entrar en el flujo de trabajo de tu equipo de desarrollo, y el tiempo posterior para que ya pueda usarse.

Para verlo con un ejemplo, establezcamos tres premisas:

• Imagina que hasta que el ítem llega a tu flujo de trabajo, existen dos fases previas: Descubrimiento y Análisis funcional.
• Se mantiene el flujo de trabajo de desarrollo en cuatro fases, pero con dos matices: la fase de Análisis será un análisis técnico; y la fase de Despliegue dejará el desarrollo en un entorno no productivo.
• El cliente añade dos fases posteriores: Validación y Despliegue a producción.

De esta manera, el Customer Lead Time sería la suma de todas ellas:

Cómo medir el Lead Time

Para esta métrica no he incluido ninguna fórmula. Y mi intención fue premeditada. Lo habitual para medir los dos tipos de Lead Time es hacerlo a través de un sistema de seguimiento de tiempo y de gestión de proyectos que te permita registrar el tiempo que tardas en completar cada ítem a lo largo de sus distintas fases.

Para ser más efectivo, te propongo que tu flujo de trabajo esté lo suficientemente definido como para poder registrar el inicio y fin de un ítem a lo largo del tiempo y las distintas fases por las que transita.

Si lo hicieras así y si seguimos con el ejemplo del Customer Lead Time para obtener ambas métricas:

El valor del Customer Lead Time sería la suma de todos el tiempo que se invierte en las distintas fases. Un total de 16 días. Y el System Lead Time tiene un valor de 10 días.

Pero no acaba aquí la cosa. Estos datos se pueden explotar para crear gráficas y utilizar herramientas de visualización donde representas los Lead Time y así interpretar mejor los resultados. De hecho, voy a detallarte dos de las gráficas más extendidas.

CFD. Una forma de medir el System Lead Time promedio

Una herramienta valiosa para la visualización y análisis del flujo de trabajo es la CFD (Cumulative Flow Diagram). Esta herramienta se emplea en la gestión de proyectos para medir cómo los ítems avanzan a lo largo de distintas fases en un período específico. La CFD ofrece una representación visual del progreso de los ítems desde su inicio hasta su finalización.

En detalle la CFD representa:

• En el horizontal una línea temporal.
• En el eje vertical el número de ítems que se encuentran en cada una de las fases del proceso.
• Incluye las 4 fases del ejemplo de todo el artículo, así como el estado inicial Por hacer.

¿Y cómo puedes explotar la CFD y obtener el System Lead Time? Pues al ser una gráfica acumulada, lo que tendrás será un tiempo promedio, la suma de todos los System Lead Time individuales entre el número total de ítems.

Y la forma de lograrlo es tan simple como trazar una línea horizontal desde su entrada en el sistema hasta llegar al momento en que se completó.

El System Lead Time promedio para cualquier ítem que entra en el sistema sería de algo más de 35 días.

Histograma. Cómo tener agrupaciones de System Lead Time

Es importante tener en cuenta que la CFD nos da un valor promedio y que no tiene en cuenta numerosos factores como pueden ser: el tipo de ítem, la complejidad, la disponibilidad del equipo o la propia madurez del mismo.

Por ello, podemos profundizar en el uso de una gráfica de tipo histograma. Este tipo de gráficas puede proporcionarte una representación visual efectiva de la distribución del System Lead Time en tu flujo de trabajo.

Un histograma te permitirá observar patrones, identificar tendencias y comprender mejor cómo se distribuyen el tiempo en los distintos ítems.

En estas gráficas es crucial definir el intervalo en el que agrupar los ítems (más conocido como bin), decidir qué System Lead Time vas a representar y pintarlo en el eje x del histograma. El eje y indica la cantidad de ítems.

En definitiva, cada barra vertical indica cuántos ítems comparten el mismo System Lead Time.

Pero tu trabajo no debería quedarse en la representación de los datos, sino que tendrías que interpretarlos:

• ¿Dónde se concentran la mayoría de System Lead Time? Quizás tienes un proceso eficiente y te puedes enfocar en reducir el System Lead Time promedio.
• ¿Existen bins con mucha menor cantidad de ítems respecto del resto? ¿Crees que tu sistema tiene algún área de mejora o anomalía que lo justifique? Seguramente encuentres maneras de estandarizar esta variabilidad o de mejora en las distintas fases del flujo de trabajo.

Al utilizar y representar estos datos en el histograma, eres capaz de identificar tendencias y tomar acciones al respecto. Cuando estas acciones estén en curso y vuelvas a analizar tus datos, podrás incluso medir el impacto de dichas acciones respecto del punto de partida, comparándolo con el histograma anterior.

Además, este histograma ofrece la ventaja de brindar predictibilidad al comprender la distribución del System Lead Time. De hecho, es especialmente útil para estimar el riesgo de cumplir con las expectativas del cliente cuando te solicita una nueva funcionalidad.

Imagínate que el cliente te pide que el siguiente ítem se lo entregues en 3 días. Atendiendo a tu histograma, podrías pensar que lo tendrás en el tiempo solicitado. Además, tienes dos valores estadísticos que así te lo indican:

• Moda. Si calculas el System Lead Time más frecuente, el valor es de 3 días.
• Media. Si realizas el promedio aritmético obtienes un valor de 3,18 días.

Sin embargo, sería aconsejable que pudieras darle un rango de entrega acorde a lo que tu histograma muestra. Si quisieras podrías decirle a tu cliente que en un rango de 3 a 4 días serías capaz de entregar el nuevo ítem con una confianza del 85% (tras calcular el percentil 85).

O incluso si elevas tu confianza al 95%, el rango estaría entre 3 y 6 días.

Ponlas en práctica

En síntesis, y utilizando analogías con el mundo marinero, las métricas como el Touch Time y el Lead Time son faros guía en el vasto océano del desarrollo de software. Son herramientas poderosas que iluminan el camino hacia la eficiencia, la calidad y la satisfacción del cliente. Al adoptar y aplicar estas métricas en tu enfoque de gestión de proyectos Kanban, te embarcas en un viaje hacia la mejora continua y la excelencia operativa.

Visualiza un escenario en el que las estimaciones iniciales se afinan progresivamente, disminuyendo el margen de error y ofreciendo una comprensión precisa de los plazos de desarrollo.

Visualiza un equipo que minimiza el Waste Time y maximiza su contribución de valor real en cada fase del flujo de trabajo.

Visualiza la capacidad de comprometer plazos realistas y construir relaciones sólidas con los clientes, basadas en confianza y resultados tangibles.

Así que, ¿por qué medimos? Medimos para comprender, para mejorar y para liderar. Las métricas no son solo números; son la brújula que guía nuestro camino hacia la excelencia. Al adoptar estas métricas y aplicarlas con diligencia, te unes a una comunidad de profesionales que buscan superar los desafíos y elevar los estándares en el mundo del desarrollo de software.

Gracias a las métricas podrás transformar la incertidumbre en predictibilidad, la complejidad en claridad y la ambición en logros tangibles.

¡Bienvenido al viaje de la mejora continua a través de las métricas!