Qué es la metodología Kanban y cómo aplicarla

Ahora que es Agosto y mucha gente anda de vacaciones o pensando en ellas, hemos pensado escribir sobre un tema algo más ligerito. Suele ser buena época, el verano, además, para aprovechar un poco que el ritmo baja un poco, para revisar procesos, darle un repaso a los temas que tenemos pendientes, pensar si es que igual siguen ahí en pendientes desde hace tiempo por algo (un poco hacer un reset, como bien explicaba Corti aquí en twitter: https://twitter.com/josek_net/status/1554086781557129219 ), etc.

Puestos a repasar metodologías y tareas, y como lo tenemos reciente porque es una de las cosas que estuvimos viendo con el par de chavales de la FP básica que han estado este año con nosotros de prácticas:

hemos pensado que igual era buen tema para traer aquí. Al final Kanban es una cosa de la que muchísima gente ha oído hablar, al menos en el mundillo todo el mundo tiene unas nociones básicas sobre el tema, pero a veces el por qué de las cosas o determinados flecos se quedan sueltos. Así que aquí va, un resumencillo sobre Kanban, su relación con otras metodologías que podemos aplicar y cuestiones a tener en cuenta. Explicado, como siempre, para humanos.

¿Qué es Kanban?

En japonés, Kanban significa tarjeta, o señal. La primera vez que se usó el nombre para procesos de trabajo fue por Toyota en los años 50, como parte de una forma de trabajar a la que llamaban JIT (Just in Time o Justo a Tiempo). Una de las ideas fundamentales que había detrás era pasar de metodologías push a metodologías pull. Esto, que así puesto suena raro, básicamente es pasar de que las partes iniciales de la cadena de producción vayan fabricando sin parar y enviando las piezas (push) a la siguiente parte de la cadena, a trabajar por petición desde las partes finales de la cadena (pull). Es decir, el último proceso pide al anterior lo que necesita, este fabrica solo lo que le han pedido, nunca de más y si necesita piezas para hacerlo, las pide hacia atrás, siempre solo las que necesita.

¿Y esto para qué? Bueno, pues entre otras lo del "justo a tiempo" era para no tener un montón de cosas esperando a ser usadas (con el desgaste), y con esto de pedir solo lo que se necesita y cuando se necesita, se ahorran piezas, se pueden medir cuellos de botella y flexibiliza la producción (es más fácil ajustarse a cambios), etc.

Esta introducción sobre el origen la cuento por dos motivos, la primera, entender que aunque la aplicación del Kanban al mundo del Software o de la gestión es relativamente reciente, y hay un montón de adaptaciones que se han hecho en ese proceso, el proceso en sí original tiene ya casi 75 años y sí que hay mucho de la idea original que podemos trasladar al desarrollo de software o gestión de tareas de cualquier tipo. De hecho, creo que es fundamental entender los puntos de partida y los fundamentos que han llevado a desarrollar una metodología, para poder aplicarla (como con cualquier otra cosa, en realidad).

¿Qué es kanban aplicado a la gestión de proyectos?

Una vez entendido de dónde viene, ahora vamos a ver Kanban aplicado a la gestión de proyectos. Es una forma de trabajar en la que vamos a:

• Visualizar el flujo de trabajo
• Limitar la cantidad de trabajo que hacemos a la vez
• Pondremos el foco en ese "flujo" del trabajo
• Y haremos mejora continua del proceso

Ahora punto por punto.

• Visualizar el flujo de trabajo: Como decía al comienzo, Kanban en japonés significa tarjeta o señal, y de hecho la mayor parte de aplicaciones que permiten trabajar con Kanban suelen usar tarjetitas, como por ejemplo Trello. Seguro que también has visto la típica foto de la gente con post-its en los cristales o paredes de una oficina. Queda cool y moderno, aunque yo reconozco haberlo hecho en algún trabajo anterior. Como queremos visualizar el flujo de trabajo, pondremos nombres claros en las columnas de un tablero y pondremos en cada columna las tareas que estén en esos estados. Si quieres, elige un proyecto con el que vayas a empezar en breve y hazlo a medida que lees este artículo. Decide unos estados para las tareas, es mejor pecar por escasez al comienzo, quizá un Pendientes, Haciendo y Hechas nos pueda valer.
• Limitar la cantidad de trabajo que hacemos a la vez: Desde un punto de vista del tablero esto sería limitar la cantidad de tareas que tenemos en cada columna al mismo tiempo. En inglés se habla del stop starting, start finishing, o dejar de empezar a hacer cosas y empezar a terminarlas. Te habrá pasado en alguna situación que te atascas un poco con un tema y comienzas otro un poco más sencillo, aparcando el anterior, y quizá pasan los días y de repente en un momento dado te das cuenta de que el tema que dejaste aparcado lleva semanas así. No es que cambiar de contexto sea siempre malo, o dejar tareas bloqueadas para comenzar otras, pero es bueno limitar esto y fomentar que terminemos lo que se empieza, antes de ponernos con otras cosas.
• Poner el foco en el flujo del trabajo: Ahora que ya tenemos el tablero montado y hemos limitado la cantidad de trabajo que hacemos a la vez, las tareas deberían fluir. Con este punto lo que queremos es fijarnos en ese fluir de tareas, en los posibles cuellos de botella, interrupciones, mecanismos que hacen que las tareas no avancen lo fluidas que debieran.
• Mejora continua del proceso: Con el punto anterior, bien porque la experiencia o porque hayamos decidido medir algunos parámetros de las tareas (el tiempo medio del estado inicial al final, cantidad de tareas terminadas a la semana, etc), tendremos una idea de posibles cosas que mejorar en el proceso. Con esto y la mentalidad de que Kanban es una metodología para ayudarnos en equipo a hacer mejor nuestro trabajo, podemos decidir qué cambiar para hacernos la vida más fácil.

Relación con el Kanban original

Un tema interesante que comentamos al principio sobre el Kanban original, era que se trataba de una metodología pull en vez de push. En vez de ir haciendo cosas y pasándoselas al siguiente de la cadena, desde el final se iba pidiendo lo que hiciera falta para terminar el producto (un coche en este caso). Esto llevado a la gestión de otro tipo de proyectos y con el punto 3 del anterior listado en mente, cuando nos fijemos en el flujo de trabajo o queramos desatascar un tablero de Kanban, lo suyo es ir siempre de derechas a izquierdas. Si, por ejemplo, tenemos los estados "Listo, Haciendo, Bloqueadas, En Revisión, Hechas". Antes de empezar a meter más trabajo, miraremos si hay cosas en revisión que ya podamos dar por cerradas, qué les falta a las cosas bloqueadas para poder pasarlas a revisión y así.

Esto mejora tiempos desde que las tareas se empiezan hasta que se acaban y reduce la cantidad de temas en el aire.

Diferencias con Scrum

Si estás leyendo esto probablemente hayas oído hablar también de Scrum o de otras metodologías ágiles y quizá pienses en si sería mejor usar una u otra para tu próximo proyecto.

La diferencia fundamental entre Scrum y otras metodologías similares, es que en Scrum fijamos un horizonte temporal para hacer un trabajo determinado y en Kanban no. En Scrum tenemos ciclos de desarrollo, o Sprints, en los que nos comprometemos a entregar cierta carga de trabajo, a condición de que esa carga de trabajo no cambie durante el ciclo de desarrollo. Para proyectos de desarrollo nuevos y desarrollo de producto, es muy utilizada, porque por un lado tenemos la flexibilidad de irnos adaptando a los cambios (decidiendo ahora lo que se hará en el próximo ciclo de desarrollo) y por otro el equipo no tiene el caos del cambio constante de foco, ya que en lo que está trabajando ahora se mantiene firme en el ciclo de desarrollo actual.

Kanban por otro lado funciona muy bien en proyectos en mantenimiento y equipos con una menor estructura para la planificación de los distintos ciclos de desarrollo de Scrum o cuando el cliente no quiere implicarse tanto como es necesario que lo haga en Scrum.

En el día a día se ve que muchos proyectos que usan Kanban podrían usar Scrum perfectamente, trabajando con el cliente las expectativas temporales de los cambios y las tareas de última hora, y muchos proyectos que usan Scrum en realidad usan un Kanban disimulado, ya que se cambia el ciclo de desarrollo en mitad de proceso o no se entregan los ciclos completos nunca, etc.

Cosas a tener en cuenta

Como idea final, una metodología de estas debería ayudar, después de un tiempo usándola, el equipo debería notar una mejora en algo, en lo que sea que se quiere mejorar (que no siempre tiene que ser hacer más tareas, puede ser que las queramos hacer con menos estrés, viviendo mejor). Es importante tener esto en mente todo el rato, usarlo en el apartado de mejora continua, a veces nos empeñamos en usar Kanban, Scrum o la-nueva-metodología-de-moda porque hemos leído por ahí que está muy bien, pero quizá hay aspectos de esa metodología que no encajan bien con la forma de trabajar de nuestro equipo, etc. Una parte importante de todas estas formas de trabajar es sentirse suficientemente libre para adaptarlas y hacer que encajen con nuestros equipos.