Kanban: origen y definición
El término japonés Kanban, acuñado por Taiichi Onho (Toyota), se puede traducir como tablero o tarjeta de señalización, y su origen se remonta finales de los cuarenta o principio de los cincuenta. Hace referencia a un sistema de visualización empleado en los procesos de producción para coordinar en una cadena de montaje la entrega a tiempo de cada parte que cada parte, y sólo cuando se necesita, reduciendo al mismo tiempo la sobreproducción o almacenamientos innecesarios.
Su aplicación en el sector TIC
El uso de tableros kanban facilita la visualización y gestión del flujo constante de avance y entrega evitando los dos problemas más importantes: cuellos de botella y tiempos muertos. El desarrollo ágil de software emplea prácticas de gestión visual por ser las que mejor sirven a los principios de comunicación directa y simplicidad en la documentación y gestión. Desde 2005 es cada vez más frecuente reemplazar los formatos de lista para las pilas de producto y de sprint por notas adhesivas, que resultan más versátiles al poder cambiar su posición: para reordenar las prioridades de las historias de una pila de producto, e informar desde su posición cuáles se están programando, o probando, o ya se han terminado. Las prácticas kanban son una ayuda especialmente útil en la gestión de proyectos evolutivos con entregas continuas. Como herramienta de control visual debe emplearse con criterios de flexibilidad, sin considerar prescripciones ni excepciones en el método de trabajo, para lograr la implementación personalizada, que de la mejor respuesta a los principios ágiles, de ingeniería concurrente o de síntesis de ambos, con los que trabaje la organización.
Gestión técnica vs. gestión experta
Algunos autores consideran a Scrum y Kanban marcos o métodologías que prescriben prácticas, artefactos y roles concretos. Según Kniberg & Skarin se dibujan las siguientes diferencias entre ellos Kniberg & Skarin, 2009:
- Scrum prescribe roles, kanban no.
- Scrum trabaja con iteraciones de tiempo fijo, kanban con cadencias (simples, múltiples o dirigidas por eventos).
- Scrum limita el wip por iteración, kanban limita el wip por estado del flujo de trabajo.
- Los equipos de scrum son multidisciplinares, en kanban pueden ser de especialistas.
- Scrum no permite cambiar tareas del sprint, en kanban la tarea puede alterarse hasta entrar en el flujo.
- En scrum la pila de producto debe tener la longitud de al menos un sprint. En kanban se debe atender al ritmo de arrastre de tareas.
- En scrum se deben estimar las historias y las tareas y calcular la velocidad, kanban no mide tareas ni velocidad.
- Scrum necesita una pila de producto priorizada, en kanban es la siguiente historia o tarea arrastrada desde el cliente.
- Scrum prescribe reuniones diarias, kanban no.
- Scrum emplea diagramas burndown, kanban no.
- Los tableros scrum se resetean al final de cada sprint.
Al entrar en un modelo de gestión basado en la experiencia y conocimiento propio, y abandonar el modelo de gestión técnica, se flexibilizando las prácticas, y pierden relevancia cuestiones “técnico-metodológicas” como las siguientes:
Situación A: “Por un lado se desea usar kanban, pero por otro se quiere estimar las tareas (por ejemplo para registrar la velocidad por razones organizativas de mi empresa) …”
Situación B: “La empresa gestiona proyectos simultáneos con una organización de oficina de proyectos y por eso encaja mejor el establecimiento de roles; pero sin embargo se quiere trabajar con kanban en lugar de con scrum… ¿Debería hacer scrumban? ¿qué es eso? ¿o lo que se va a hacer es Scrumbut? ¿es la solución de un mal gestor?.”
El uso de kanban como metodología definida es una opción de trabajo para la gestión técnica, pero no para la autogestión y la gestión experta, porque limita la flexibilidad en la implantación