Las 3 métricas claves del kanban

Me gusta explicar Kanban a equipos de TI con las siguientes tres reglas esenciales:

1. Mostrar el proceso y el trabajo en curso
2. Limitar el trabajo en curso
3. Optimizar el flujo de trabajo

En este post quiero detenerme en particular sobre 3 métricas que me parece fundamental monitorear para trabajar la tercera regla.

¿Cuáles son las tres métricas?

Cycle Time: Es la métrica que registra el tiempo que sucede entre el inicio y el final del proceso, para un ítem de trabajo dado. Se suele medir en días de trabajo. 

Lead Time: Es la métrica que registra el tiempo que sucede entre el momento en el cual se está pidiendo un ítem de trabajo y el momento de su entrega (el final del proceso). Se suele medir en días de trabajo. 

La siguiente traducción de la explicación de Corey Ladas sobre la diferencia entre Cycle Time y Lead Time ayuda a entender mejor estos conceptos:

"El reloj del Lead time se inicia cuando se hace el pedido y termina cuando se entrega. El reloj de Cycle Time se inicia cuando el equipo empieza a trabajar sobre el ítem y se termina cuando el ítem está listo para la entrega. El Cycle Time es una medición más mecánica de la capacidad del proceso. El Lead Time es lo que ven clientes. El Lead Time depende del Cycle Time, pero también depende de la buena disposición para mantener un backlog de ítems de trabajo, de la paciencia de clientes y de la disponibilidad para recibir la entrega por clientes. Otra forma de mirarlo: el Cycle Time mide el ritmo de terminación, mientras el Lead Time mide el ritmo de entrega."

Touch Time: Descubrí el concepto en el libro Lean From The Trenches, de Henrick Knibberg (y al poco tiempo lo empezamos a registrar en el kanban de un equipo de testing):

Es la métrica que registra el tiempo en el cual un ítem de trabajo fue realmente trabajado (o "tocado") por el equipo. Dicho de otra forma: cuantos días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo.

Con lo cual, para un mismo ítem: 

¿Cómo registrar las tres métricas?

No soy muy amante de las herramientas para soportar los tableros kanban, pero en el caso de usarlos, seguro tendrán funcionalidades muy lindas para registrar y monitorear estas 3 métricas (y mucho más).

Para quienes tienen suerte usando tableros fiscos de kanban, es bastante fácil mantener el registro de estas métricas sin que sea una carga administrativa pesada. Lo que en mi experiencia funciona bien es anotar en los post-its de los items de trabajo alguna información y luego completar una planilla digital con esta información en el momento de finalización del proceso de trabajo de cada ítem.

• Información a registrar para Cycle Time y Lead Time

El tablero debería contar con una columna "Backlog" donde se agrega un post-it de ítem de trabajo cada vez que se hace un pedido de trabajo. La idea es anotar en el mismo post-it la fecha en la cual se agregó el post-it al tablero (=fecha de pedido). Por otro lado, cuando un ítem de trabajo se empieza a trabajar (y su post-it ingresa a la primera columna de trabajo del tablero), se registra la fecha en el mismo post-it (=fecha de inicio).

• Información a registrar para Touch Time

Un mecanismo simple para eso es agregar un punto rojo en el post-it de un ítem de trabajo para cada día en el cual el equipo no hizo nada para este ítem. Típicamente esto ocurre cuando un ítem permanece en una columna de cola / buffer, cuando surge un bloqueo externo al equipo o cuando el equipo está trabajando sobre otros ítems. Si el equipo hacer reuniones diarias de actualización del tablero, es bastante fácil de implementar durante la reunión. 

• Planilla de calculo de las métricas

El ultimo paso es ingresar esta información en una planilla de calculo. La idea es que cada vez que un item se entrega (=ingresa a la columna de "Terminado" del tablero), se vaya guardando cierta información del post-it en una planilla de calculo. En particular: la fecha de pedido (1), la fecha de inicio (2), la fecha de entrega (3)  y la cantidad de días bloqueados (4). 

En esta planilla se pueden armar los cálculos siguientes para las 3 métricas: 

• Cycle Time = DíasHabilesEntre(3-2)
• Lead Time = DíasHabilesEntre(3-1)
• Touch Time = Cycle Time - 4

DiasHabilesEntre(fecha1, fecha2) se puede resolver por ejemplo con la función "NETWORKDAYS" en las planillas de google docs. Ver esta planilla de ejemplo (con los feriados del 2012 de Argentina).

¿Qué monitorear?

En mi experiencia, es importante revisar periódicamente o durante retrospectivas los números a continuación. En la tabla también explico posibles interpretaciones de las tendencias y algunas pistas para mejorar: 

¿Qué monitorear?	Tendencia	Posibles Interpretaciones	Posibles Acciones
Promedio del Cycle Time	Está bajando	- El equipo está mejorando - Proceso más fluido	- Seguir así!
Promedio del Cycle Time	Está subiendo	- Se complejiza el trabajo - Hay bloqueos y/o cuellos de botella - Se desmotiva el equipo	- Analizar cuellos de botella y bloqueos de trabajo - Revisar motivación del equipo y/o capacidad del equipo para el trabajo
Promedio del Lead Time	Está bajando	- No hay pedidos - El equipo está sobre-dimensionado - Mejoramos	- Analizar si no deberían llegar más pedidos - Analizar dimensionamiento del equipo
Promedio del Lead Time	Está subiendo	- Hay muchos pedidos - El equipo está sub-dimensionado - El ritmo de trabajo no es suficiente	- Revisar validez de los pedidos - Analizar dimensionamiento del equipo - Revisar motivación del equipo y/o capacidad del equipo para el trabajo
Variabilidad Cycle Time	Muy variable	- Muchas diferencias de complejidad entre los items - Deuda técnica acumulada surge en cualquier ítem en forma aleatoria	- Separar items en varias clases de servicios o según complejidad (alta, media, baja) - Atacar la deuda técnica e implementar prácticas para bajarlas (XP)
Promedio Touch Time / Promedio Cycle Time	Baja proporción	- Mucha espera en el proceso - Muchos bloqueos en el proceso y cuellos de botella - Mucho mult-tasking	- Bajar los limites de WIP y trabajar sobre puntos de bloqueos y cuellos de botella - Identificar puntos de espera externa y trabajar sobre su optimización
Promedio Cycle  Time / Promedio Lead Time	Baja proporción	- El equipo está sub-dimensionado - El ritmo de trabajo no es suficiente	- Analizar dimensionamiento del equipo - Revisar motivación del equipo y/o capacidad del equipo para el trabajo

¿Usan estas métricas? ¿Tienen otras en su Kanban?

Para aprender más sobre Kanban, te recomiendo el taller Lean y Kanban en acción, de Kleer. 

Quinta Reunión de la Comunidad Ágil de Neuquén (Kanban)

Próxima Reunión de Comunidad Ágil de Neuquén

Cuándo: Miércoles 4 de Julio del 2012, a las 18h

Dónde: Salón Azul del la Biblioteca Central - Universidad Nacional del Comahue - Buenos Aires 1400, Neuquén 

Tema: Kanban

Kanban es un mecanismo japonés ancestral de visualización de información. Fue adaptado en distintas industrias en Japón y en particular en la industria automotriz en el famoso Toyota Production System a mitad del siglo pasado. Hace años se empezó a aplicar en proyectos de Tecnología de la Información y aparece como una evolución y/o complemento de algunas metodologías ágiles.

Es uno de los temas "hot" que hace ruido en los círculos de ingeniería de software y de metodologías ágiles. 

En este encuentro Milena y Thomas contarán qué es Kanban y cómo se implementa. Luego veremos un  caso de aplicación real, y en particular aspectos de diseño del tablero, combinación con otras practicas agiles, integración con la norma ISO, etc.

Facilitadores: Milena Armada y Thomas Wallet

La reunión es gratuita, solo hay que inscribirse a través del siguiente link.

Las 10 mejores extensiones para tunear tu tablero

Antes que todo, disculpen el efecto marketinero del titulo, pero me divierte mucho poner algo así!

Estoy muy alineado con Tobias Mayer cuando dice que el tablero de tareas (físico, con post-its en la pared) es el Corazón de Scrum, y con Daniel Markham que habla de la Tiranía de las Herramientas. Me parece que vale la pena invertir en mejorar el tablero, buscando  visualizar de forma simple los elementos claves del trabajo del equipo. Admiro por ejemplo el trabajo de Xavier Quesada Allue sobre Visual Management.

Seguro conocen esta versión básica del tablero de tareas de scrum (del libro Scrum and XP from the Trenches):

Si bien es una buena base para armar el primer tablero del equipo, he notado que a lo largo de los sprints, se suelen incorporar mejoras visuales en los tableros, propias de cada equipo, que resultan en nuevas áreas del tablero, hojas adicionales pegadas al lado, nuevos gráficos, trucos visuales para distinguir alguna información critica, etc. Estas extensiones al tablero, a veces se acercan al tuning de los autos, pero en muchos casos suelen dar información valiosa para la mejora continua y en mi opinión aportan a la construcción de identidad de un equipo ágil. En particular me provoca mucha satisfacción cuando quienes conforman un equipo pausan orgullosos con su tablero.

Seleccione 10 de las mejores extensiones que experimente en distintos equipos con tableros Scrum y Kanban. Gracias al equipo de Nora, a los Caesar girls and boy, al primer grupo QV y al team multi-aplicaciones TecP por compartir las fotos!

1. Tacho

Se agrega una hoja al costado del tablero, con un tacho de basura dibujado, donde ubicar ítems o tareas que fueron canceladas o suspendidas. 

Esta extensión aporta la posibilidad de visualizar fácilmente el nivel de "basura" en nuestro backlog y tareas.

2. Mini-Kanban

Se dispone de un espacio del tablero (muchas veces abajo) con un mini-kanban de tareas diversas que no suelen trabajarse de la misma forma que los ítems clásicos de un tablero Scrum, o que no siguen la misma secuencia de estados de los ítems principales de un tablero Kanban. Varias veces vi este espacio mini-kanban con 3 columnas (pendiente, en curso, terminado). Se suelen registrar tareas diversas como mejoras pequeñas, temas no planificados, inducciones sobre un tema, investigaciones, actualización de documentación general, etc. 

Es útil para registrar pequeñas tareas que se hacen además de los ítems planificados, y también para escoger algunas de estas tareas en pequeños momentos libres de la iteración. Si una de estas tareas lleva demasiado tiempo, suele ser mejor incluirla en los ítems principales del tablero luego de una priorización.  

3. Niko-Niko Calendar

En este caso se agrega una hoja donde dibujar las caras del niko-niko calendar (ver esta buena explicación del concepto) cada día.  

Me parece un muy buen indicador visual para darse cuenta del estado de ánimo del equipo en el tiempo. 

4. Sobre de Release

En la columna o lugar del tablero donde se ubican los ítems o tareas terminadas, se pega un sobre donde dejar los post-its de ítems o tareas correspondientes a un release dado. 

Está extensión permite tener un sobre con todo lo que se hizo para un release en particular, y simplifica la depuración del tablero. En tableros Kanban con un flujo continuo, es común que se vayan acumulando las tareas terminadas hasta que alguien las quiera depurar. 

Este mecanismo esta bueno para ordenar estas tareas por release. Eventualmente los sobres se pueden sacar del tablero después de un tiempo y archivar en algún lado. 

5. Lista de Impedimentos

En este caso se publica al lado del tablero una lista de los impedimentos más críticos detectados por el equipo (por ejemplo en las retrospectivas). Se puede priorizar y marcar el estatus de los impedimentos (por ejemplo tachar cuando se elimina el impedimento). 

Visualizar tan explícitamente los impedimentos del equipo suele tener un efecto interesante, ya que ayuda a responsabilizar a las personas involucradas para trabajar en resolverlos. También el hecho que lo puedan ver personas externas al equipo (por ejemplo una gerenta) a veces dispara reflexiones o acciones de resolución de los impedimentos fuera del equipo. 

6. Resumen de Retrospectivas

En complemento o reemplazo de la Lista de Impedimentos, se puede agregar al tablero una hoja (o varias) con el resumen de la última retrospectiva. En particular se pueden destacar las acciones de mejora elegidas y sus eventuales responsables. 

Exponer esta información aporta mucho a la transparencia, y también es un buen recordatorio de los compromisos asumidos durante las retrospectivas. 

7. Curva de Defectos

Se expone en un lugar del tablero una curva de los bugs/incidentes surgidos. Se puede refinar en incidentes Abiertos / Cerrados y/o hacer distinciones por el ambiente donde surgieron los incidentes (QA, Pre-Producción, Producción). Es interesante registrar los incidentes en el tiempo (por ejemplo por sprints o por semana), para poder detectar tendencias e identificar mejoras a realizar en consecuencia.

Esta extensión me gusta mucho porque permite agregar información visual sobre la calidad del desarrollo al tablero, que muchas veces está enfocado a aspectos de planificación y seguimiento. En particular nos da una buena idea de la deuda técnica de las aplicaciones desarrolladas, o de su nivel de estabilidad. Es un elemento visual bastante expresivo para disparar reflexión sobre la calidad de nuestros desarrollos y pensar en mejoras técnicas para prevenir incidentes.  

8. Asignación con Mini-Fotos

Esta extensión permite informar visualmente del responsable de una tarea en el tablero. Muchas veces se usan las iniciales de la persona en algún espacio del post-it correspondiente. Personalmente me gusta mucho imprimir pequeñas fotos de quienes conforman el equipo (por ejemplo de 2 cm x 2 cm), que luego se pegan al post-it correspondiente (con pinche si usan un tablero de corcho o cinta). 

Es la forma visual más clara para representar la asignación de una tarea a una persona. Si bien a veces se usan avatares elegidos por las personas, a mi gusto la mini-foto es la forma más transparente y clara que vi. 

9. Escala de Estimaciones

En equipos ágiles es moneda corriente usar estimaciones relativas con los ítems a desarrollar (features, user stories, etc.). Por ejemplo se estima que el ítem A es aproximadamente 2 veces más complejo de desarrollar que el ítem B. En esta extensión, se busca referencia explícitamente a ítems de iteraciones anteriores para las estimaciones relativas. Por ejemplo en un equipo usábamos kilogramos como unidad abstracta de complejidad para estimar user stories (un ítem de 10 kg es aproximadamente 5 veces más complejo de desarrollar que uno de 2 kg). Al final de cada sprint se revisaba cada "peso" de los ítems terminados para ver si estaba bien estimado, si el valor de kg necesitaba algún ajuste y finalmente si su "peso" ajustado era representativo para poder ser utilizado como referencia en estimaciones posteriores. Con todos los ítems representativos se fue armando al lado del tablero una escala de referencia para estimaciones relativas. 

He visto que tener una escala de referencia visible para estimaciones relativas a lo largo de los sprints es un mecanismo que permite acelerar la maduración del equipo en sus estimaciones. Lo bueno es que se puede ir construyendo de a poco, agregando ítems representativos a lo largo de los sprints. 

10. Cumulative Flow Diagram

En esta extensión se agrega al tradicional diagrama de burn-down del tablero un diagrama CFD (Cumulative Flow Diagram), que permite ver en el tiempo la evolución de los ítems trabajados por el equipo según su estado. En un equipo, en lugar de registrar la cantidad de ítems por estado, registrábamos la suma de complejidades de desarrollo de los ítems por estado, en este caso expresados en kilogramos. 

Es un buen elemento visual para detectar cuellos de botella, o empezar a introducir el concepto de limite de WIP en un equipo usando Scrum.

Espero que algunas de estas extensiones te den ideas para extender tableros y mejorar siempre la comunicación visual asociada...

Y en tu equipo, usan algunas de estas extensiones o tienen otras extensiones para compartir?