Semejanzas y diferencias entre Kanban y Scrum.
Fuente: Pixabay
Quisiera empezar este post con dos afirmaciones:
La primera:
«No, no es lo mismo Kanban que Scrum!»
La segunda:
«Kanban y Scrum no son excluyentes!
Aunque para la mayoría son obvias, no quiero dejar de compartirlas a tenor de lo que se ve y escucha en algunos foros y en algunas organizaciones.
Dicho esto y antes de pasar a ver en que se parecen y en que se diferencian, quizás quieras tener presente y echar un vistazo a estos dos artículos:
¿En qué se parecen Kanban y Scrum?
Empecemos por señalar algunas de sus similitudes:
- Ambos son modelos Lean y Agile: foco en el objetivo, optimización de medios, entrega frecuente de valor y mejora continua.
- Son herramientas de proceso que gestionan el flujo de valor: maximizan el valor entregado, visualizan el proceso en curso, dividen el trabajo y limitan el trabajo en curso (WIP).
- Son prácticas empíricas orientadas a la eficacia y a la eficiencia del proceso.
- Facilitan la transparencia del proceso mediante tableros visuales.
- Permiten la detección temprana de impedimentos. No los resuelven, pero los hacen emerger más pronto.
- Trabajan con equipos auto-organizados en torno a la entrega de valor, no en torno a la asignación de tareas.
- Emplean sistemas de planificación «pull».
¿En qué se diferencian Kanban y Scrum?
Continuemos con algunas de sus diferencias. Unas diferencias que vienen dadas, en primera instancia por su propósito, y en segunda por sus reglas:
- Scrum es un marco de trabajo, creado por Jeff Sutherland y Ken Swchaber, para maximizar el valor entregado en el desarrollo y el mantenimiento de productos complejos en situaciones de alta incertidumbre.
- Kanban es un sistema, creado por Taiichi Ohno, para optimizar el flujo de trabajo en una cadena de producción.
- Scrum es mucho más prescriptivo que Kanban:
- Scrum prescribe unos roles concretos. En Kanban se pueden definir roles o no.
- Scrum prescribe equipos multifuncionales. En Kanban los equipos pueden ser multifuncionales o especializados.
- Scrum prescribe reuniones concretas de tiempo fijo. En Kanban no existen reuniones prefijadas.
- Scrum prescribe la estimación y la velocidad.
- Scrum prescribe iteraciones de tiempo fijo (Sprint). Kanban no trabaja el concepto de iteración.
- Scrum limita el trabajo en curso por iteración. Kanban limita el WIP por el estado del trabajo en el flujo del proceso.
- Scrum se resiste a cambios de alcance durante la iteración. Kanban admite cambios siempre que haya capacidad disponible para abordarlos.
- Scrum limpia su tablero en cada iteración, usa un tablero diferente en cada iteración. En Kanban no es necesario, su tablero es persistente.
- En Scrum las funcionalidades se dividen en partes que puedan completarse en un sprint. Kanban no tiene limitaciones en el tamaño de las divisiones.
- Scrum, prioriza la pila del producto. En Kanban, la priorización es opcional
- Scrum establece reuniones diarias centradas en las personas.
- Scrum usa diagramas Burndown. Kanban no prescribe diagramas de seguimiento concretos.
- En Scrum, el tablero pertenece a un único equipo. En Kanban, varios equipos o personas pueden compartir el mismo tablero.
Aplicación práctica de Kanban y Scrum
Kanban da buenos resultados a la hora de:
- Detectar y eliminar cuellos de botella en la ejecución de procesos.
- Ejecutar proyectos de mantenimiento, en particular en ANS (Acuerdos de Nivel de Servicio), dónde el tiempo de respuesta en los procesos y las operaciones críticas es vital.
Scrum es altamente eficiente si se quiere:
- Adquirir compromiso del equipo con la entrega de valor constante y continua.
- Ejecutar proyectos de desarrollo que manejen plazos de entrega cortos (entre una semana y un mes), y en los que se puedan hacer planteamientos iterativos e incrementales partiendo de un Mínimo Producto Viable.
Para terminar, simplemente comentar que trabajar con Scrum tiene un impacto grande en la forma de trabajar en la organización, afectando tanto a su cultura, como a sus procesos y a la estructura de la misma. Esto supone mayor resistencia al cambio que aplicar Kanban, pero sin duda, el resultado lo merece.
Quizas tambien te interese leer
10 Comentarios
Hola Cristina, son metodologías muy interesantes. Crees que se pueda aplicar las dos metodologías combinadas?
Gracias!
Saludos.
Si, son dos modelos muy interesantes y por supuesto que se pueden utilizar conjuntamente.
Gracias por el comentario Federico.
Feliz día!!!
Hola Cristina, Enhorabuena por el artículo, me han quedado muy claras las diferencias, gracias a ti podre aplicar estos métodos bien y mejorar mi productividad.!!
Gracias a ti María por tu feedback!
Me alegra saber que te pueda ser de utilidad y que le puedas sacar provecho ;).
Seguimos en contacto.
Feliz día!!!
Hola, me encanto y me sirvió mucho tú articulo y tu website en general! Felicidades!
Me alegro mucho Jorge.
Muchas gracias por tu feedback.
Seguimos en contacto.
Feliz día!!!
Yo creo que Kanban suele adaptarse mejor a trabajos que son o se asemejan a operaciones. Es decir, tareas repetitivas (o pseudo-repetitivas) que van entrando en una cola, se priorizan y se van desarrollando por el equipo (o equipos).
Cuando hablamos de proyecto, de compromiso, de organizar un trabajo a medio-largo plazo, entonces creo que Scrum se adapta mejor.
Creo que en el fondo he dicho lo mismo que has dicho tú… 🙂
Hola Jose Huerta, muchas gracias por tu comentario, sin duda, enriquecedor.
Añade matices y apreciaciones personales que ayudan a entender un poco más la diferencia entre ambos modelos.
Que pases un feliz día Jose :)!
Aplicar a un proyecto de mejora continua SCRUM puede ser contraproducente, ya que la mejora continua parte de un Gemba, de captar lo que pasa en el shopfloor, de cómo y quiénes participan y son los que al final tienen las soluciones/ideas de resolución… En muchos casos, surgen imprevistos, nuevas informaciones, cambios de alcance, que por más previsivo que uno pueda ser como SCRUM Master o miembro del equipo, al final la metodología puede generar choque y resistencia ya que SCRUM no permite aplicar directamente lo nuevo, y esperar a una posterior iteración, genera pérdida en la capacidad de respuesta del equipo. Esto es lo que me ha sucedido en la experiencia en proyectos de la naturaleza mencionada. Ahora, en un torno muy controlado, como puede llegar a serlo el desarrollo de un software/app, creo que SCRUM da la respuesta necesaria.
Algún consejo con el que pueda ayudarme?
Muchas Gracias.
Hola Juan, muchas gracias por compartir tu experiencia.
El uso de una u otra práctica ágil va a depender del objetivo que se persiga.
Por ejemplo: si perseguimos eliminar cuellos de botella, podemos usar Kanban; pero si lo que queremos es reducir el time to market quizás sea más interesante aplicar Scrum.
Tener claro el propósito, el «para qué», además de la idiosincrasia de la organización es clave.
Recibe un cordial saludo.