Verdades inmutables de Kanban: no muevas las tarjetas hacia atrás en el tablero
Cuando comencé mi aventura en Kanban, una de las primeras frases que escuché fue: «No muevas las tarjetas hacia atrás en el tablero».
En aquella época tenía dudas similares sobre las que leí recientemente cuando me preparaba para escribir este artículo: ¿por qué no se aconseja hacerlo? ¿Qué pasa si necesitamos retrabajar algo? ¿Qué sucede si un elemento necesita un análisis adicional o un “tester” encuentra un defecto que un desarrollador debe resolver?
No muevas el coche
La primera respuesta que me convenció vino del mundo de la fabricación de automóviles. Imaginemos una línea de producción de coches. Si se detecta un defecto en la etapa de instalación de la puerta de un coche, pero está relacionado con la fase anterior, el automóvil no se devuelve a la fuente del error, sino que se mantiene en el lugar donde se ha detectado el defecto y es en ese punto donde los operarios se reúnen para tratar de solucionar el problema “in situ”.
El equivalente en nuestro tablero sería mantener el elemento en la columna donde ocurrió el defecto, marcarlo como bloqueado, crear un nuevo elemento (defecto) y hacer el seguimiento de éste hasta que se resuelva (incluso dependiendo del caso se puede catalogar como urgente/expedite). Como digo, esta aproximación tenía sentido, pero aún faltaba revisarlo más en detalle.
Incertidumbre
Cuando no podemos predecir los resultados con confianza y precisión, y por lo tanto existe una variedad de resultados posibles, necesitamos cubrir el riesgo de obtener resultados no deseados. Si no disponemos de datos históricos, o no comprendemos el rango y la incertidumbre a la que nos enfrentamos, debemos protegernos contra los peores resultados posibles.
Uno de los métodos para gestionar el riesgo de un futuro incierto es aplicar opciones reales a nuestras iniciativas.
El punto de inflexión
Gracias a las discusiones, la lectura y el aprendizaje, pude identificar los problemas derivados de mover elementos hacia atrás en un tablero Kanban:
- Rompemos los límites del WIP (del inglés Work In Progress)
- Perdemos la pista de las métricas
- Complicamos el flujo y es probable que la distribución del tiempo de entrega se convierta en una distribución impredecible y poco confiable.
- Nos cargamos la lógica. Un tablero kanban no significa simplemente dividir el proceso en fases: se trata de mapear la secuencia de pasos dominantes con la que descubrimos y aprendemos nueva información. (1)
Esta última frase es la clave para comprender por qué no debemos mover elementos hacia atrás en el tablero kanban. El punto donde se descubre esa nueva información es el paso en el que se detectó el defecto y no en el que se creó.
Pero antes de centrarnos en esta frase, echemos un vistazo al resto de puntos.
Rompemos los límites del WIP
Cuando movemos un elemento hacia atrás, es probable que lo estemos moviendo a un estado anterior en el flujo de trabajo que ya está en su límite WIP. Mover una tarjeta hacia atrás es el equivalente a devolverlo al “Upstream”, es decir al paso anterior en el flujo y esto en ocasiones provoca que el paso que lo recibe pueda romper el límite de WIP; lo que el reproceso sobrecarga el sistema.
Todo retrabajo necesita una clase de servicio explícita, en este caso, dejar in situ el elemento y hacer que los trabajadores dejen lo que estaban haciendo para acelerar una reparación, mientras se bloquea parte del trabajo existente, es la clase de servicio más alta, mientras que enviar el elemento hacia atrás provoca que este espere en la cola para volver a trabajar donde se creó el problema, es decir, si aplicamos esta forma de trabajo, le estamos dando a la resolución del problema una prioridad baja. Además, esta forma de trabajo puede provocar ambigüedades si no existe una política clara y explícita: ¿deberíamos sentarnos y esperar hasta que alguien esté libre? ¿O deberíamos bloquear otro elemento mientras se realiza la reparación de inmediato? ¿O…?
Perdemos la pista a las métricas
Las métricas no deben ser utilizadas solo por los gestores o por aburridos burócratas. Puesto que las métricas se basan en datos, deben ser una herramienta utilizada por los equipos para comprender lo que sucede en y con sus procesos. Las métricas nos ayudarán a analizar el pasado y en base a este análisis anticipar patrones futuros de nuestro flujo de trabajo o incluso sobre el comportamiento de nuestros clientes. En definitiva, las métricas bien utilizadas hacen que nuestro servicio sea estable y predecible.
Ahora bien, ¿qué sucede con las métricas si movemos los elementos hacia atrás?
Podemos mostrarlo de una forma más sencilla usando el diagrama de flujo acumulado (CFD, del inglés Cumulative Flow Diagram).
Si usamos la definición clásica de CFD como «un gráfico de área que representa la cantidad de trabajo en un estado dado, mostrando las llegadas, el tiempo en espera, la cantidad de elementos en curso y la salida» (2), podemos ver claramente que los elementos que se mueven en dirección contraria:
- alteran la cantidad de trabajo en un estado de trabajo dado – porque un elemento se contará dos veces (o más) en uno o más estados;
- afectan al tiempo y a la cantidad en espera– del elemento dado (que hemos movido hacia atrás) pero también de los otros elementos del flujo;
- rompe el flujo de entrada de los estados – cuando un elemento regresa al comienzo de un proceso;
- el CFD ya no tendrá sentido, sería necesario hacer una métrica para comparar las entradas frente a salidas (y rezar para que nuestro elemento no vuelva a la lista de «tareas pendientes»).
Complicamos el flujo
Mover elementos hacia delante y atrás dificulta la gestión del proceso. Cuando lo hacemos con frecuencia, perdemos la pista del trabajo realizado. La primera bandera roja serán las métricas. Y aunque el tiempo de entrega siempre funciona porque solo se toma el dato al principio y al final, la reelaboración significa que los elementos no fluyen de manera predecible y el resultado es una distribución de tiempo de entrega “fat tail”, es decir, un servicio poco predecible. Eliminar los elementos que se mueven hacia atrás es una parte clave para llegar a tener un sistema confiable y predecible.
Si se mantiene esta forma de trabajar, en poco tiempo, el tablero no nos proporcionará información, más allá del hecho de que el trabajo está en curso. El lugar donde visualizas la información debe ser una única fuente de verdad y un vistazo a nuestro tablero debería darnos información inmediata sobre lo que sucede.
Si los elementos vuelan de derecha a izquierda y viceversa, ¿cómo podemos saber qué les sucedió cuando no estábamos mirando? ¿Cómo diseñaríamos las políticas? ¿Pondríamos un límite de movimientos por semana? Cuando los elementos de trabajo cambian de posición con frecuencia y de forma aleatoria, ¿cómo podríamos saber cuál fue su estado anterior? Estas pérdidas de información hacen que la historia de los elementos de un flujo así sea difusa y oscura y se pierdan importantes oportunidades de aprendizaje.
Nos cargamos la lógica. Recordemos que este es un viaje de descubrimiento
Es importante dejar de tratar el tablero como un muro dividido en columnas que representan trabajo, personas o funciones concretas y comenzar a pensar en él como un proceso de descubrimiento y aprendizaje, que nos permite visualizar el estado del trabajo y conocer la información que tenemos sobre este. Al cambiar este concepto nuestra perspectiva cambia drásticamente.
No queremos mover elementos hacia atrás porque, siguiendo la lógica de aprendizaje, eso significaría que hemos “desaprendido” algo. Por otro lado, no deseamos manipular u ocultar la realidad manteniendo en desarrollo un elemento que realmente pertenece a la parte de análisis. De hecho, el nuevo conocimiento, el aprendizaje, está sucediendo donde se descubrió la necesidad de volver a trabajar. Mover un elemento hacia atrás implica que hemos desperdiciado el conocimiento o que hemos desaprendido y esto es algo poco probable.
Hay posibles opciones para salir de este estado:
“Recordemos que las columnas en un tablero (…) son una abstracción del ciclo de vida del aprendizaje que resulta en una solución a una necesidad del usuario final. Y todo el trabajo puede ocurrir en todas las columnas. La columna actual es solo la actividad dominante. Está bien, por ejemplo, tener una columna de desarrollo y tener a los ‘tester’ trabajando en algunas tareas de prueba preliminares mientras un elemento está en ‘desarrollo’ o a los desarrolladores corrigiendo errores mientras el elemento está en la columna ‘prueba’». (3)
Debemos discutir con el equipo el proceso actual. Si notamos, que todos en el equipo, sentimos una fuerte tentación de comenzar este pequeño ejercicio de movimiento en contra del flujo, es necesario reaccionar. Reunámonos y pensemos: ¿por qué queremos hacer esto? ¿Por qué pensamos que era la mejor idea para reflejar la realidad? La solución puede estar en el rediseño del flujo, ten en cuenta que el tablero es un organismo vivo que debe ir evolucionando. (4)
Nunca es fácil, ¿verdad?
Como probablemente ya habrás notado, Kanban está muy lejos de las respuestas sencillas donde todo es blanco o negro. Un claro ejemplo es el tema expuesto en este artículo.
Normalmente ocurre que la regla de «no mover elementos hacia atrás en el tablero kanban» es un factor de estrés muy fuerte para el proceso actual. Incluso, podemos llegar a observar una gran resistencia, especialmente en los niveles corporativos de madurez más bajos. Lo que nos puede llevar a no desear imponer esta regla en un equipo. En estos casos, lo que podemos hacer es permitir que el equipo se enfrente a las consecuencias de esta elección (de mover elementos hacia atrás). Si dicen: “queremos hacer esto, no pueden detenernos”, debemos explicar los resultados esperados y dejar que el equipo cargue con las consecuencias. Cuando se den cuenta de dónde se encuentran los problemas con las métricas, la transparencia y la comunicación, es cuando nos encontraremos en posición de hablar sobre la causa raíz de estos problemas.
Lo importante es asegurarse de que el mecanismo de aprendizaje esté en su lugar para permitir la mejora. En organizaciones de baja madurez, tendremos que permitir que los elementos se muevan hacia atrás. Esto implica, asegurarse de que exista una política explícita sobre la clase de servicio para el reproceso y trabajar en que la recopilación y el informe de métricas se utilizan en la revisión del flujo (o service delivery review) y en la revisión de riesgos (blocker clustering) para garantizar e impulsar el aprendizaje continuo.
En conclusión, las soluciones expuestas que van desde “parar la línea de producción y solucionar el problema de forma urgente” a “mandar el elemento de vuelta a estados anteriores” debe estar alineado con la madurez de cada organización. Nuestro objetivo debería ser llegar a parar la línea de producción y solucionar el problema de forma urgente, pero evidentemente, esto solo se puede hacer cuando la organización tenga la suficiente madurez para soportar el stress que esta política genera.
(1) https://www.linkedin.com/pulse/statik-systems-thinking-approach-implementing-kanban-david-anderson/
(2) https://en.wikipedia.org/wiki/Cumulative_flow_diagram
(3) por Paul Klipp at KanbanPoland slack channel
(4) Esto es lo que sucedió con el proceso en el que trabajé. Teníamos 3 columnas (análisis, diseño, desarrollo) donde las tareas tienden a moverse hacia adelante y hacia atrás. Una breve retro con el equipo ayudó a identificar que nuestro flujo de trabajo requería un rediseño. Eliminamos la fase de «diseño» y agregamos «revisión» después de «desarrollo» (que era el control con la empresa antes de la prueba). Se solucionó el problema de mover elementos hacia atrás.
Referencias
Kanban Evergreen: Don’t move items backwards on the kanban board de Anna Radzikowska
Equipo de Transformación. 29 de julio de 2021.
