Por qué Scrum no es Kanban y por qué Kanban no es Scrum

La verdad que es tema es antiguo pero… no por ello lo suficientemente conocido. Y es más que frecuente encontrar que ambos son utilizados como sinónimo. Y, cómo sabes, ni mucho menos lo son, tienen parecidos, sí… pero no son lo mismo.

Hace como casi 5 años que escribí aquel post de ¿Qué es el método Kanban para la gestión de proyectos?, que, con la veteranía que tiene, lo puedes tomar como antecedente a este de hoy, y recordar que Kanban es una de las piezas clave de Lean, algo de historia, etc.

En este caso, vamos con unas cuantas diferencias entre Scrum y Kanban, hay más, pero por ir a lo más importante…

Las reglas de Kanban son muchas menos que las de Scrum

Aunque Scrum no es que tenga muchas reglas, ya sabes que la guía oficial de Scrum son 21 páginas, que, como siempre digo, si le quitas el índice, portada, etc., se te queda en nada. No obstante, Kanban tiene menos, de hecho en Kanban se habla de tres reglas: que el flujo de trabajo exista y sea visible, que se limite el trabajo en cada parte del proceso (lo vemos luego) y que se mida (lead y cycle, lo vemos luego).

En este punto afecta también, aunque sea obvio después de lo anterior, que en Kanban no se habla de roles, es decir, no hay (aunque luego tu puedes hacer lo que quieras) Scrum Master, ni Product Owner ni equipo.

Kanban no define que haya iteraciones ni Sprints

Quizá la diferencia más popular, en Scrum una pieza clave es la división del tiempo en Sprints… que en Kanban no existe. Por ello, hay quien a Kanban le pone el apellido de “trabajo continuo”.

La manera de organizarse en Kanban es teniendo priorizado el trabajo pendiente, lo cual vendría a ser similar en Scrum a tener un Product Backlog claro priorizado por valor, y limitando el máximo de trabajo en cada parte del flujo de trabajo (en cada columna del tablero, para que nos entendamos), es decir…

Kanban limita explícitamente las tareas que se pueden realizar por fase, Scrum lo hace por Sprint

Lo hace con el popular “límite del trabajo en el proceso” o work in progress, para unos, o in process, pero, en cualquier caso, el WIP para todos. Scrum también lo hace de manera indirecta por medio del Sprint Backlog, ya que se cierra en el mismo el tope de cosas a hacer en el Sprint. Pero en Kanban ese límite es más “fino” ya que es por columna, mientras que en Scrum es por Sprint.

Lo anterior provoca que en Scrum, dentro de que es ágil, ya sabes “el cambio es bienvenido”, las opciones de cambio sean menor que en Kanban, ya que durante el Sprint no debería cambiarse nada. En Kanban no deberías tocar una tarea empezada, pero las pendientes pueden cambiarse de orden en cualquier momento.

Kanban tiene dos métricas base

Una es el tiempo desde que algo está pendiente hasta que se termina, la otra es el tiempo desde que se empieza a trabajar en algo hasta que se termina (los llamados tiempos lead y cycle).

Esto es importante, no sólo para mejorar, y ver como van las cosas, sino también porque, a diferencia de Scrum, en Kanban no habla de que cada item en la lista de cosas pendientes debe ser de menor duración al tiempo del Sprint, pero al medir tiempos, Kanban te acaba obligando a descomponer tareas en lo más pequeño posible.

Aunque no es obligatorio, en Scrum, típicamente, la gente usa una métrica que es la velocidad, que viene a ser el trabajo completado en el Sprint.

Consejo final…

Hasta aquí los métodos, ahora… ¿qué te recomiendo yo? Que pruebes, experimentes, mezcles cosas de ambos, si crees que lo necesitas. Que empieces con lo que crees que más te conviene y luego lo vayas adaptando a tu realidad.

Y si quieres leer más, te recomiendo el post de ¿Qué es el método Kanban para la gestión de proyectos? y el libro de “Kanban and Scrum – Making the Most of Both

1 comentario en “Por qué Scrum no es Kanban y por qué Kanban no es Scrum”

  1. Hola!!!
    He hecho el curso de miríadax y quedé encantada con las metodologías ágiles, de hecho es justo lo que buscaba porque aunque ahora mismo no llevo proyectos de programación, trabajo en proyectos de implementación de SAP y creo que puedo estandarizar una metodología ágil a seguir para optimizar nuestro trabajo en equipo.
    Creo que lo ideal en mi caso es unir Scrum y Kanban para aprovechar los beneficios de ambas, pero quiero saber bien cómo usarlas porque hay características de nuestra forma de trabajo con las que me cuesta encajar cualquiera de las dos metodologías. Por esto quisiera saber el libro que mencionas de «Kanban and Scrum – Making the Most of Both» explica cómo trabajar y/o adaptar ambas metodologías en un mismo proyecto.
    Muchas gracias,

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba