En un tablero Kanban… evita que un item se pueda mover de derecha a izquierda

Fíjate en la imagen de más abajo. Es una foto de hace ya sus años, fue uno de los primeros tableros Kanban que yo utilicé y fíjate en esa flecha roja que apunta a la izquierda y a la que continúa una X también roja. Aquella flecha de prohibido mover items de derecha a izquierda ya la puse yo hace años en aquel tablero para evitar lo que hoy te quiero contar.
rp_tableroReal-1024x768.jpg

La previa: El conocido (aunque no suficientemente popular) problema del cambio de contexto

No debería extenderme mucho en este punto, porque ya le he dedicado mucho (léase Trabajar en más de una tarea (ya no digo proyecto) a la vez genera perdidas de tiempo y disminuye la productividad)

Resumidamente, en Agilidad, Scrum, Kanban, y otros, se enfatiza mucho el evitar el cambio de contexto, ya que es… desperdicio “en vena”, porque:

– Empezar a hacer cosas (muchas) y no terminarlas de una… provoca cambios de contexto: cosas que se empiezan, no se terminan, se empiezan otras, vuelta a la primera, vuelta a pensar en qué estado quedó, etc.
– Esos cambios de contexto, conllevan volver tiempo después a algo no terminado, volver a recordar en qué estado quedó, volver a retomar la concentración necesaria, la información necesaria.
– Y esos cambios de contexto conllevan incertidumbre de saber en “qué estado estamos”, habiendo muchas cosas empezadas y ninguna terminada.

Así resumidamente, empezar algo, no terminarlo, dejarlo y volver tiempo después es malo. Cuando más grande sea ese tiempo después… más malo.
En Scrum este problema se trata no cambiando el alcance al iniciarse un Sprint y con el importante y desconocido Swarming, “flujo continuo de una sola pieza” o One-Piece Continuous Flow. Y en Kanban, con el WIP y manteniendo un flujo siempre de izquierda a derecha.

A partir de ahora, asumo que sabes lo que es Kanban y lo que es el WIP, por ello ahí no voy a entrar, si hay dudas, lee antes los siguientes:

– ¿Qué es el método Kanban para la gestión de proyectos? (año 2011)

– Como lograr el mejor WIP de un KANBAN

– Una buena manera de llevar el seguimiento en Kanban: gráfico acumulativo

Vamos entonces con por qué no es nada bueno permitir que items (posit entre amigos) de un tablero Kanban se puedan mover de una columna hacia otra previa, que esté a su izquierda, mover de derecha a izquierda o desandar camino.

Evita que un item pueda volver a una columna previa

Creo que dicho lo anterior está todo dicho, un tablero Kanban y un tablero de Sprint Backlog en Scrum, siguen un flujo contínuo de izquierda a derecha.

Si empiezas un item, lo mueves a una columna de «doing» y te atascas con él, por alguna razón, y decides volverlo atrás… te has saltado de manera oscura el WIP (que te lo explicaba en los post de antes sobre Kanban) y has empezado algo, para luego posterga, no se sabe hasta cuando, su finalización… cambio de contexto peligroso, desperdicio, cuando vuelvas a trabajar en él.

Además, de que aquello que lo bloqueó se olvida, se olvida perseguir su cierre,

Que no se pueda mover un item de derecha a izquierda evita, además, poner cosas «por poner» en el “doing”

Sí, aquello de, “hoy voy a empezar con este item, lo pongo ya en el doing”, pero luego, no sé por qué razón, no me da tiempo y del item del doing, del que realmente no se está haciendo nada… lo vuelvo a “to do”. Bueno, si nos auto-prohibimos la vuelta atrás nos pensaremos mucho en poner algo «por poner» en el ”doing”.

Otra ventaja… te fuerza a hacer items más pequeños

Que sería lo recomendable, como cuando decimos que las Historias de Usuario deberían ser lo más pequeñas posibles, lo mínimo que aporte valor. Grandes items, tienen más probabilidades de encontrarse con imprevistos que los frenen, y cómo nos hemos impuesto que no vuelvan atrás, si se quedan bloqueados en el «doing»… las métricas (estas, una buena manera de llevar el seguimiento en Kanban: gráfico acumulativo) van a salir mal y una manera de evitarlo, sin hacer trampas es… con items lo más pequeños posibles, que nos llevan por el «camino luminoso» el de entrega continua de valor.

El caso del Testing cuando detecta un bug

Hay otro caso muy típico de tentación de vuelta atrás, el de aquellos items que salen de “doing” y pasan a QA, Testing, Validación, o como cada uno lo llame, si es que hace uso de esa columna del flujo (cosa discutible, por cierto, mírate tableros ágiles sospechosos). Este es el caso de que “testing” encuentra un fallo, entonces no puede pasar a “Done” (terminado), qué hacemos… ¿lo echamos hacia atrás?

La solución más típica para evitar en este caso es re-interpretar la “columna” de Testing (o como la llames) para que además sea “Testing y bug fixing” (recuerda aquello de la multifuncionalidad, de no crear columnas propiedad, que son del equipo y esas cosas).

PARENTAL ADVISORY: EXPLICIT CONTENT – Cuidado con el siguiente párrafo que te puede llevar al lado oscuro

Todo lo anterior que te he contado, partiendo siempre de la premisa de que cada uno puede hacer lo que quiera, si ese “lo que quiera” ha constatado que es la mejor manera de hacerlo en su particular caso, lo cual, yo sólo recomendaría si antes se han seguido durante mucho tiempo las buenas prácticas que mayormente se recomiendan o, dicho de otro modo, se lleva un tiempo, bastante, en la etapa Shu (del Shuhari, mírate esto, Aplicate el Shuhari).

Así que, salvo que seas un gran experto en Kanban… no permitas que un item vuelva hacia atrás.
 

Javier Garzás

2 comentarios en “En un tablero Kanban… evita que un item se pueda mover de derecha a izquierda”

  1. Hola Javier, muy claro los ejemplos. Vayamos a casos prácticos.
    Qué sucede en el caso donde una User Story «A» está en In Progress y conversando con el equipo en la Daily Scrum, encontramos más conveniente comenzar a trabajar en otra User Story «B» no comenzada aún. De esto se trata la coordinación táctica de tareas.
    ¿Qué sugieres hacer? 1) no trabajar en la más conveniente, seguir trabajando en la que ya se comenzó? 2) dejar de trabajar en ella, pero la dejo en la columna de WIP aunque nadie la esté trabajando realmente?
    ¿Y si además ya se alcanzó el WIP Limit? No se puede comenzar la Story B sin antes quitar la A. ¿Que sugieres hacer en ese caso?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba