{"id":32850,"date":"2021-07-29T09:30:31","date_gmt":"2021-07-29T07:30:31","guid":{"rendered":"https:\/\/partners.sngular.com\/atlassian\/?p=32850"},"modified":"2026-02-12T11:28:57","modified_gmt":"2026-02-12T10:28:57","slug":"verdades-inmutables-kanban","status":"publish","type":"post","link":"https:\/\/partners.sngular.com\/atlassian\/verdades-inmutables-kanban\/","title":{"rendered":"Verdades inmutables de Kanban: no muevas las tarjetas hacia atr\u00e1s en el tablero"},"content":{"rendered":"
<\/div>

Verdades inmutables de Kanban: no muevas las tarjetas hacia atr\u00e1s en el tablero<\/h1><\/div><\/div><\/div><\/section>
<\/div>

Cuando comenc\u00e9 mi aventura\u00a0en\u00a0Kanban,\u00a0una de las primeras frases que\u00a0escuch\u00e9\u00a0fue: “No muevas\u00a0las tarjetas\u00a0hacia atr\u00e1s en el tablero”.<\/span>\u00a0<\/span><\/h2>\n

En aquella \u00e9poca ten\u00eda dudas similares sobre las que le\u00ed recientemente cuando me preparaba para escribir este art\u00edculo: \u00bfpor qu\u00e9 no se aconseja hacerlo?<\/strong> \u00bfQu\u00e9 pasa si necesitamos retrabajar algo? \u00bfQu\u00e9 sucede si un elemento necesita un an\u00e1lisis adicional o un \u201ctester\u201d encuentra un defecto que un desarrollador debe resolver?<\/span>\u00a0<\/span><\/p>\n

No\u00a0muevas el coche<\/span><\/b>\u00a0<\/span><\/p>\n

La primera respuesta que\u00a0me\u00a0convenci\u00f3 vino\u00a0del\u00a0mundo\u00a0de la fabricaci\u00f3n\u00a0de autom\u00f3viles.<\/strong> Imaginemos una l\u00ednea de producci\u00f3n de\u00a0coches. Si se detecta\u00a0un defecto en la etapa de instalaci\u00f3n de la puerta\u00a0de un coche, pero\u00a0est\u00e1\u00a0relacionado con la fase anterior, el autom\u00f3vil no se devuelve a la fuente del error, sino que se mantiene en el lugar donde se\u00a0ha\u00a0detectado\u00a0el defecto\u00a0y es en ese punto donde\u00a0los operarios se re\u00fanen para\u00a0tratar de solucionar el problema\u00a0\u201cin situ\u201d.<\/strong><\/span>\u00a0<\/strong><\/p>\n

El equivalente en nuestro tablero ser\u00eda\u00a0mantener\u00a0el\u00a0elemento\u00a0en\u00a0la columna<\/strong>\u00a0donde ocurri\u00f3 el defecto,\u00a0marcarlo\u00a0como bloqueado<\/strong>, crear un nuevo elemento (defecto) y hacer el seguimiento de \u00e9ste hasta que se resuelva (incluso dependiendo del caso se puede catalogar como urgente\/expedite). Como digo, esta aproximaci\u00f3n ten\u00eda sentido, pero a\u00fan faltaba revisarlo m\u00e1s en detalle.<\/span>\u00a0<\/span><\/p>\n<\/div>[vc_single_image image=”31061″ img_size=”full” alignment=”center”]

Incertidumbre<\/span><\/b><\/p>\n

Cuando no podemos predecir los resultados con confianza y precisi\u00f3n,\u00a0y por lo tanto\u00a0existe\u00a0una variedad de resultados posibles, necesitamos cubrir el riesgo de\u00a0obtener\u00a0resultados\u00a0no deseados<\/strong>.\u00a0Si\u00a0no\u00a0disponemos de\u00a0datos hist\u00f3ricos,\u00a0o\u00a0no comprendemos el rango y la incertidumbre\u00a0a la que nos enfrentamos, debemos protegernos contra los peores resultados posibles.<\/span><\/p>\n

Uno de\u00a0los m\u00e9todos para gestionar el riesgo de un futuro incierto es aplicar opciones reales a nuestras iniciativas.<\/strong><\/span><\/p>\n<\/div>

El\u00a0punto de inflexi\u00f3n<\/span><\/b><\/p>\n

Gracias a\u00a0las discusiones, la lectura y el aprendizaje, pude identificar los problemas\u00a0derivados\u00a0de mover elementos hacia atr\u00e1s en\u00a0un\u00a0tablero\u00a0Kanban:<\/span><\/p>\n

    \n
  1. Rompemos\u00a0los l\u00edmites del\u00a0<\/span>WIP\u00a0<\/span><\/b>(del ingl\u00e9s\u00a0Work\u00a0In\u00a0Progress)<\/span><\/li>\n<\/ol>\n
      \n
    1. Perdemos\u00a0la pista de\u00a0las\u00a0m\u00e9tricas<\/span><\/li>\n<\/ol>\n
        \n
      1. Complicamos el\u00a0flujo y es probable que la distribuci\u00f3n del tiempo de entrega se\u00a0convierta en una distribuci\u00f3n\u00a0impredecible y poco confiable.<\/span><\/li>\n<\/ol>\n
          \n
        1. Nos\u00a0cargamos\u00a0la l\u00f3gica. Un tablero\u00a0kanban\u00a0no significa simplemente dividir\u00a0el\u00a0proceso en fases:\u00a0se trata de\u00a0mapear\u00a0la secuencia de pasos dominantes\u00a0con la que descubrimos\u00a0y aprendemos\u00a0nueva\u00a0informaci\u00f3n. (1)<\/span><\/li>\n<\/ol>\n

          Esta\u00a0\u00faltima\u00a0frase\u00a0es la clave para comprender por qu\u00e9 no debemos\u00a0mover elementos hacia atr\u00e1s en el tablero\u00a0kanban. El\u00a0punto donde se descubre\u00a0esa nueva informaci\u00f3n\u00a0es el paso en el que se detect\u00f3 el defecto y no en el que se cre\u00f3.<\/span><\/p>\n

          Pero\u00a0antes de centrarnos en esta frase,\u00a0echemos un vistazo al resto de puntos.<\/span><\/p>\n

          Rompemos\u00a0los l\u00edmites del\u00a0WIP<\/span><\/b><\/p>\n

          Cuando\u00a0movemos\u00a0un\u00a0elemento\u00a0hacia atr\u00e1s, es probable que lo estemos\u00a0moviendo a un estado anterior en el flujo de trabajo que ya est\u00e1 en su l\u00edmite WIP. Mover una tarjeta\u00a0hacia atr\u00e1s es el equivalente a\u00a0devolverlo al\u00a0\u201c<\/span>Upstream\u201d<\/span><\/b>, es decir al paso anterior en el flujo y esto en ocasiones provoca que el paso que lo recibe pueda romper el l\u00edmite de WIP; lo que el reproceso sobrecarga el sistema.<\/span><\/p>\n

          Todo\u00a0retrabajo\u00a0necesita una clase de servicio\u00a0expl\u00edcita, en este caso,\u00a0dejar in situ\u00a0el elemento\u00a0y\u00a0hacer\u00a0que\u00a0los trabajadores\u00a0dejen lo que estaban haciendo para\u00a0acelerar una reparaci\u00f3n, mientras se bloquea parte del trabajo existente, es la clase de servicio m\u00e1s alta, mientras que enviar\u00a0el elemento\u00a0hacia atr\u00e1s\u00a0provoca que este espere en la cola\u00a0para volver a trabajar donde se cre\u00f3 el problema, es decir, si aplicamos esta forma\u00a0de trabajo,\u00a0le estamos dando a la resoluci\u00f3n del problema una prioridad\u00a0baja.\u00a0\u00a0Adem\u00e1s,\u00a0esta forma de trabajo puede provocar ambig\u00fcedades\u00a0si no existe una pol\u00edtica clara y expl\u00edcita: \u00bfdeber\u00edamos\u00a0sentarnos\u00a0y esperar hasta que alguien est\u00e9 libre? \u00bfO deber\u00edamos\u00a0bloquear otro elemento mientras se realiza la reparaci\u00f3n de inmediato?\u00a0\u00bfO\u2026?<\/span><\/p>\n<\/div>[vc_single_image image=”24622″ img_size=”full” alignment=”center”]

          Perdemos la pista\u00a0a las m\u00e9tricas<\/span><\/b><\/p>\n

          Las m\u00e9tricas no\u00a0deben ser\u00a0utilizadas\u00a0solo\u00a0por los gestores o\u00a0por aburridos bur\u00f3cratas.\u00a0Puesto que las m\u00e9tricas<\/strong> se basan en datos, deben ser una herramienta utilizada por los equipos para\u00a0comprender lo que sucede en y con sus\u00a0procesos<\/strong>.\u00a0Las m\u00e9tricas nos ayudar\u00e1n a analizar el pasado y en base a este an\u00e1lisis\u00a0anticipar patrones futuros de nuestro flujo de trabajo o\u00a0incluso\u00a0sobre el comportamiento de\u00a0nuestros clientes. En definitiva, las\u00a0m\u00e9tricas bien utilizadas hacen que nuestro servicio sea\u00a0estable y predecible<\/strong>.<\/span><\/p>\n

          Ahora bien, \u00bfqu\u00e9 sucede con las m\u00e9tricas si\u00a0movemos\u00a0los elementos\u00a0hacia atr\u00e1s?<\/span><\/p>\n

          Podemos mostrarlo de\u00a0una forma m\u00e1s sencilla\u00a0usando el\u00a0diagrama de flujo\u00a0acumulado (CFD, del ingl\u00e9s\u00a0Cumulative\u00a0Flow\u00a0Diagram).<\/span><\/p>\n

          Si usamos la definici\u00f3n cl\u00e1sica de CFD como “un gr\u00e1fico de \u00e1rea que representa la cantidad de trabajo en un estado dado, mostrando las llegadas, el tiempo en\u00a0espera, la cantidad\u00a0de elementos\u00a0en curso\u00a0y la salida” (2), podemos ver claramente que los elementos\u00a0que se mueven en direcci\u00f3n contraria<\/strong>:<\/span><\/p>\n