Por qué funciona Kanban y cómo saber si tu equipo está listo

La mayoría de los equipos adoptan Kanban porque alguien leyó un artículo. La pregunta más inteligente es si los problemas que Kanban resuelve son realmente los problemas de tu equipo.

Hay un momento que la mayoría de los equipos reconoce, normalmente cuando son más de ocho o nueve personas. El trabajo avanza —se envían correos, se lanzan funciones, se atiende a los clientes—, pero nadie tiene una idea clara de lo que hacen los demás. Los proyectos se acumulan. Se prometen cosas que luego se olvidan en silencio. Pasas veinte minutos antes de cada reunión averiguando en qué punto está realmente un trabajo. La respuesta, por lo general, es «en algún sitio».

Ese es el problema que Kanban se diseñó para resolver. No el de definir la estrategia, contratar a las personas adecuadas o construir una cultura, sino el problema concreto, tedioso y operativo de saber en qué está trabajando tu equipo y qué se interpone en su camino.

Es una herramienta sorprendentemente humilde para lo mucho que ha llamado la atención. Kanban no pretende arreglar tu organización. Solo hace visible el trabajo. Y resulta que la visibilidad, aplicada con constancia, cambia un número notable de cosas más adelante.

De dónde viene realmente Kanban

La palabra es japonesa —significa «letrero» o «cartelera»— y Toyota desarrolló el sistema a finales de la década de 1940 para gestionar el inventario en sus plantas de fabricación. La idea era sencilla: en lugar de producir piezas según un calendario fijo, la fábrica las produciría solo cuando una estación posterior señalara que las necesitaba. Una tarjeta física —el kanban— viajaba de vuelta por la línea como petición. No se fabricaba nada de forma especulativa. Nada se acumulaba innecesariamente.

La idea que tuvo Toyota, y que los equipos de software tomaron después, es que la mayor parte de la ineficiencia de un sistema no viene de que la gente trabaje demasiado despacio, sino de que se hace el trabajo equivocado en el momento equivocado. Demasiadas cosas empezadas a la vez. Cuellos de botella que nadie nota hasta que es tarde. Trabajo terminado que espera en un lugar mientras el siguiente paso se desborda en otro.

Los desarrolladores de software, sobre todo en empresas como Microsoft a principios de los 2000, empezaron a adaptar estas ideas al trabajo del conocimiento. Las tarjetas se convirtieron en tareas. Las estaciones de la fábrica pasaron a ser etapas de un flujo de trabajo. Y el letrero se convirtió en un tablero —físico al principio, digital después— donde cualquiera del equipo podía ver de un vistazo qué estaba en curso, qué estaba esperando y qué estaba terminado.

Lo que realmente te muestra un tablero Kanban

Un tablero Kanban básico tiene tres columnas: Por hacer, En curso y Hecho. Es suficiente para muchos equipos pequeños y un buen punto de partida. Pero el verdadero valor aparece cuando empiezas a personalizar esas etapas para que coincidan con cómo fluye realmente tu trabajo, no con cómo desearías que fluyera.

Un equipo de contenidos podría usar: Idea, Resumen, En borrador, En revisión, Programado, Publicado. Un equipo de software podría dividir «En curso» en columnas separadas para desarrollo, revisión de código y control de calidad. Un equipo de consultoría podría seguir Descubrimiento, Propuesta, Activo, A la espera del cliente y Cerrado. Las etapas deben reflejar traspasos reales y tiempos de espera reales: los lugares donde el trabajo cambia de manos o donde espera hasta que ocurre otra cosa.

Fíjate en la tarjeta de la columna central: el informe de auditoría del almacén, con ocho días en curso, marcada como bloqueada. En un sistema sin tablero, esa tarea podría quedarse dos semanas más antes de que nadie se diera cuenta de que no avanza. Alguien espera a un tercero. O hace falta una decisión de un responsable que no sabe que es el cuello de botella. El tablero hace visible el bloqueo. Esa es la mayor parte del trabajo.

La regla que lo hace funcionar: los límites de WIP

Si hay un concepto que separa a los equipos que usan Kanban de verdad de los que solo tienen una lista de tareas más bonita, son los límites de trabajo en curso, o límites de WIP para abreviar. La idea es que cada columna tiene un número máximo de elementos que pueden estar en ella a la vez. Cuando una columna está llena, no puedes añadir más trabajo hasta que algo salga.

Parece contraintuitivo. ¿Acaso poder tener más tareas en curso no significa que se hace más? No es así. Lo que ocurre en realidad cuando la gente trabaja en demasiadas cosas a la vez es que todo tarda más. Cambiar de contexto es caro. El trabajo a medias genera sobrecarga de coordinación. Y cuando hay diez cosas «en curso», es muy difícil distinguir cuáles avanzan de verdad y cuáles están simplemente atascadas sin marcar.

Un límite de WIP de tres en tu columna En curso significa que, cuando llega la cuarta cosa a la mesa de alguien, alguien del equipo tiene que tomar una decisión: ¿qué tarea existente se termina primero? Obliga a priorizar. Obliga a conversar. Y tiende a producir una finalización más rápida de cada elemento, aunque el ritmo de empezar elementos nuevos se ralentice.

Kanban frente a Scrum: la pregunta que siempre se hacen los equipos

Si has pasado algo de tiempo con equipos de software o con el pensamiento moderno de operaciones, probablemente te has encontrado con Scrum: el marco que organiza el trabajo en sprints fijos de dos semanas, con sesiones de planificación, retrospectivas y roles definidos como Scrum Master y Product Owner. Muchos equipos tratan Scrum y Kanban como metodologías rivales y sienten que tienen que elegir. La diferencia es en realidad más sencilla.

Muchos equipos, sobre todo los que no son puramente de ingeniería de software, encuentran que la ceremonia de Scrum es pesada y que su estructura de sprints fijos resulta incómoda para el trabajo operativo continuo. Los equipos de marketing, de éxito del cliente, de operaciones y los fundadores que gestionan todo a la vez rara vez tienen un trabajo que encaje bien en ciclos de dos semanas. El modelo de flujo continuo de Kanban suele irles mejor.

Dicho esto, muchos equipos combinan ambos. Usan ciclos de planificación al estilo sprint para el desarrollo de producto mientras llevan un tablero Kanban para el trabajo operativo y de soporte que entra sin importar en qué sprint estés. Es un híbrido perfectamente razonable.

Las tres preguntas que tu tablero debería responder en treinta segundos

Un tablero Kanban es más útil cuando puedes mirarlo y, sin hablar con nadie, responder rápidamente a estas tres preguntas: ¿En qué está trabajando el equipo ahora mismo? ¿Dónde se atasca el trabajo? ¿Hay algo que debería hacerse y no se ha empezado?

Si no puedes responder las tres en treinta segundos de mirar el tablero, probablemente no se está manteniendo bien. El fallo más común es un tablero donde se crean tareas pero nunca se mueven: se convierte en un cementerio de buenas intenciones en lugar de un mapa vivo del trabajo real. Un tablero que no está al día es peor que no tener tablero, porque crea una falsa sensación de visibilidad.

La disciplina necesaria para mantener un tablero es real. Las tareas tienen que moverse cuando se mueve el trabajo. Los elementos bloqueados deben señalarse en el momento en que se detienen, no dos semanas después. Las tarjetas deben tener responsables claros, y los responsables deben actualizar sus tarjetas. Nada de esto requiere mucho tiempo —una práctica Kanban bien llevada puede costar de cinco a diez minutos por persona al día—, pero exige constancia. Los equipos que más se benefician de Kanban son los que tratan el tablero como la fuente de verdad, no como un ejercicio complementario de registro.

Lo que Kanban no hace

Kanban no es una herramienta de estrategia. No te ayudará a decidir en qué trabajar, solo a gestionar lo que ya has decidido hacer. Si tu organización tiene un problema de priorización, o de mandato poco claro, o un problema de «empezamos demasiados proyectos antes de terminar los anteriores» que tiene su raíz en el comportamiento del liderazgo y no en el proceso, un tablero Kanban sacará esos problemas a la luz, pero no los resolverá.

Tampoco sustituye a una buena gestión. Un tablero no reemplaza las reuniones individuales, ni la delegación reflexiva, ni una comunicación clara sobre por qué importa cierto trabajo. A veces los equipos adoptan herramientas de proceso con la esperanza de que el proceso haga el trabajo relacional y organizativo que en realidad es labor del responsable. No lo hará.

Lo que sí hará es reducir la incertidumbre ambiental que frena a la mayoría de los equipos. Las preguntas de «quién trabaja en qué», «¿esto está hecho?» y «qué debería tomar ahora» generan cantidades enormes de comunicación de poco valor en organizaciones que no tienen un sistema compartido y visible. Kanban elimina la mayor parte de ese ruido. Y para los equipos donde ese ruido es el problema dominante, la diferencia es significativa.

Cómo empezar, sin un taller de tres días

Las mejores implantaciones de Kanban que he visto empezaron pequeñas y fueron evolucionando. Las peores incluyeron a un consultor, dos días fuera de la oficina y un tablero precioso que nadie usaba en la tercera semana.

Empieza con tu equipo tal como es, con el trabajo que realmente tienes. Crea tres columnas: Pendientes, En curso, Hecho. Dedica treinta minutos con tu equipo a poner cada elemento de trabajo actual en una tarjeta. Acuerda una sola regla: cuando empieces algo, va al tablero. Cuando se mueva, mueves la tarjeta. No hagas nada más durante dos semanas.

Pasadas dos semanas, mira el tablero junto con tu equipo. ¿Dónde se acumularon las cosas? ¿Qué se quedó en Pendientes que todos decían que era prioritario? ¿Qué avanzó más rápido de lo esperado? ¿Qué se atascó y por qué? Usa lo que observes para refinar las columnas y añadir especificidad. Quizá «En curso» deba dividirse en «En curso» y «A la espera de terceros». Quizá necesites una columna llamada «En revisión» porque ese paso se sigue perdiendo. Deja que el tablero evolucione en respuesta a lo que revela tu trabajo real, no a lo que un libro de metodología dice que debería parecer.

El largo plazo: las métricas de flujo

Una vez que un sistema Kanban está en marcha, genera datos que la mayoría de los equipos nunca usa. El plazo de entrega —el tiempo total desde que se crea una tarea hasta que se completa— es el más importante. Si el plazo medio de una tarea típica es de doce días y quieres que sea de cinco, ya tienes un número contra el que trabajar y un tablero que te mostrará adónde van esos siete días de más.

El tiempo de ciclo mide solo el periodo de trabajo activo, sin contar el tiempo que una tarea pasa en el backlog. El rendimiento mide cuántos elementos completa tu equipo por semana. Ninguna de estas métricas requiere un software especial si eres disciplinado al anotar cuándo se crean y cuándo se cierran las tarjetas. Y juntas te dan una imagen mucho más honesta de la capacidad de tu equipo que cualquier proceso de planificación basado en estimaciones.

La mayoría de los equipos pequeños y medianos nunca llega hasta aquí. Usan Kanban como herramienta de visibilidad, lo cual ya es valioso por sí solo, y no van más allá. Está bien. Pero si te encuentras queriendo asumir compromisos con las partes interesadas sobre cuándo estará algo hecho, o queriendo entender por qué cierto trabajo tarda el triple de lo esperado, las métricas están ahí cuando las necesites.