Método Kanban: ¿qué es y por qué es la mejor opción para tu entidad social?
Nivel intermedio
A raíz de un debate que he tenido en una entidad con la que colaboro, me he animado a realizar esta entrada en mi blog para explicar con detalle qué es Kanban y por qué es una de las mejores opciones para trabajar en un proyecto que no sea informático. Inevitablemente voy a realizar referencias a SCRUM, que es la otra gran opción en entornos ágiles, aunque estos sean esencialmente tecnológicos.
En primer lugar cabe decir que la filosofía ágil implementada con SCRUM es una de las mejores maneras de afrontar un proyecto tecnológico y que, con sus reuniones, enfoques y artefactos contribuye a realizar software de manera muy rápida e intuitiva: sobre todo si eres informático. Está pensado para tener todas las herramientas necesarias y construir, en base a la técnica de la refinación historias de usuario (las unidades de acción que utiliza) en grandes formas de manejar un aplicativo.
Una historia de usuario realmente lo que hace es mostrarnos una funcionalidad y desglosarla en tareas que tienen sentido para un informático: además es el sistema de información perfecto cuando quieres separar lo que es la funcionalidad en sí y que sea entendible para “todo el mundo” con las propias de las tecnologías.
La forma en la que SCRUM puede acercarse a un proyecto sería, como mínimo, que éste fuera cerrado: pero abarcar toda la complejidad de una empresa requiere de sistemas más generalistas. Aunque Kanban está también pensado para sistemas informáticos, en cambio es más aplicable a las diferentes idiosincrasias de una entidad por lo que, habitualmente, suele ser de mayor calado y aceptación entre las diferentes partes: creativos, tecnólogos, estrategas, negocios, operaciones, etcétera. Ojo que no estoy diciendo que SCRUM no pueda adaptarse, pero necesita de un cambio de pensar totalmente radical.
Por otra parte, en una misma organización pueden convivir perfectamente un sistema general Kanban y ciertos proyectos, fundamentalmente tecnológicos, realizarlos con SCRUM, XP o alternativas muy enfocadas a estos entornos.
Fijémonos también que para una startup también estaría indicado utilizar la filosofía ágil enmarcada dentro de lo que se llama Lean Startup, donde se pone especial énfasis en la interacción con el cliente: también para productos y servicios: quizá la alternativa más parecida y sensata a Kanban.
La primera parte que debemos desterrar de la cabeza de mucha gente es que el sistema Kanban es como un SCRUM pero más sencillo. Esto no es así y la diferencia con dicha metodología es, de base, sustancial.
En primer lugar Kanban se basa en un sistema de arrastre (pull) por parte del beneficiario o el cliente. Los sistemas de arrastre se basan en el enfoque Lean. Esto es, estamos adaptando nuestro trabajo al límite que podemos asumir siendo el principal beneficio el poder regular el trabajo mediante los límites en las listas de trabajo que utilizamos en el tablero. Así el límite del trabajo en curso lo que hace es que no podemos iniciar los nuevos elementos del trabajo hasta que lo anterior no ha sido hecho: tener demasiado trabajo no finalizado o parcialmente no completado es un desperdicio de tiempo, dinero y alarga los tiempos de entrega impidiendo que la organización pueda responder a sus clientes y a las circunstancias cambiantes.
Gestión del cambio en Kanban
Dado que el cambio es esencial, no hay que imponer soluciones desde diferentes contextos, sino buscar la mejora evolutiva en todos los niveles de la organización.
Principios directores de Kanban
Estos son los principios que realizar una llamada a la acción.
Las prácticas generales de Kanban son las que definen en sí la forma de funcionar de Kanban y son estas:
Los ciclos de feedback propuestos por Kanban son los siguientes:
A pesar de todo cada organización debe esperar a estar preparada evolutivamente para realizar estas revisiones de manera que tengan sentido. Es decir, es inútil proponer una revisión de riesgos cuando aún no se tiene claro cuál es el propósito de Kanban. Introducir aquí que este sistema es estupendo cuando tenemos un equipo en funcionamiento pero no tanto cuando se inicia un proyecto, ya que primero deberemos entender quién está suponiendo hasta este momento el cliente.
El feedback que obtendremos del cliente va a ser diferente cuando nos ponemos manos a la obra con un proyecto nuevo que cuando estamos funcionando desde hace años. La gestión del cambio debe actuar siempre en consecuencia y no es aconsejable definirlo en función de las prisas si no del nivel madurativo en cuanto a la comprensión del sistema del equipo.
Roles
En cuanto a los roles, no hay roles definidos en Kanban, se basa todo en “empieza por donde estás”. Eso no significa que no pueda haber roles nuevos si no que podemos no incluir nuevos: y si así fuera, son más funciones específicas. Kanban, aún así, ha visto que con la experiencia se empiezan a hablar de dos roles:
Si te embarcas en un proyecto ágil debemos ser conscientes de muchas cosas, sobre todo de que el cambio en Kanban no es de un día para otro y que la agilidad requiere de hablar y profundizar de las diferentes formas de realizar las cosas: las mejoras y la transparencia son elementos fundamentales para no suponer una caja negra dentro del equipo. Las experiencias al respecto han sido de varios tipos: todas son legítimas pero todas requieren de nuestra atención desde la empatía.
Y también una advertencia a navegantes: no todas las entidades pueden ser ágiles.
Referencias
David J. Anderson y Andy Carmichel. 28 de Julio de 2016. Kanban Esencial Condensado
