Kanban vs. Scrum, ¿tendremos un ganador?  

A día de hoy no cabe duda que Scrum se presenta como claro favorito, si atendemos únicamente a los números. Que Scrum es el método preferido en nuestro país, donde de facto se ha convertido en un falso sinónimo de Agile, nadie lo puede discutir. Que Kanban se conoce más como un tablero lleno de post-its de colores, que como una implementación de Agile completa, es otro hecho destacable, al menos en la capa de gestión de las compañías.

Otra forma de pensamiento habitual es enfrentar Scrum con Kanban, como si uno fuera una alternativa excluyente a la otra, y no sólo no lo son, si no que ambos articulan dos formas distintas de alcanzar un mismo objetivo.

• Kanban se basa en el desarrollo y entrega continuos, abordando un pequeño número de tareas de forma fluida y simultánea. Los equipos Kanban utilizan una herramienta de planificación visual, el tablero Kanban ( ese que hablábamos con los post-its ), que muestra cada proyecto (historia del usuario) en una tarjeta y mueve esas tarjetas a través de columnas que representan etapas progresivas de finalización. Si tu equipo tiene un flujo continuo de solicitudes de trabajo, el Kanban puede ser el adecuado para gestionarlo. Por ejemplo, muchos equipos de soporte y mantenimiento usan Kanban en vez de Scrum, ya que con este último la tarea de gestión de su trabajo se hace casi imposible.
• Scrum también divide tareas complejas en historias de usuarios y las visualiza en un flujo de trabajo ( muchas veces en un tablero Kanban ). Los equipos de Scrum se comprometen a generar software al final de los intervalos establecidos, Sprints. Si tu necesidad es entregar valor a los clientes de forma regular, scrum parece mejor camino.

¿Es el Scrum el adecuado para ti? La primera pregunta a responder es esta: ¿Todo su equipo de desarrollo está comprometido con este equipo y su trabajo, o con otros equipos y otros trabajos también?

Con el Scrum, su equipo promete enviar un valioso incremento del producto al final de cada sprint. Si usted tiene desarrolladores que no pueden hacer ese compromiso, o que son arrastrados rutinariamente a otras corrientes de trabajo no relacionadas, entonces es mejor que no haga esos compromisos en absoluto. Puede que Scrum no sea para tu equipo.

Si respondió "No" a Scrum, probablemente pueda decir "Sí" al Kanban. Primero, considere el control de su equipo sobre el que usted trabaja. Kanban es ideal para equipos que tienen muchas solicitudes entrantes que varían en prioridad y alcance. Mientras que los procesos de Scrum requieren un alto control sobre lo que está en el alcance, Kanban le permite seguir el flujo.

Típicamente los proyectos de mantenimiento y soporte se comportan bien bajo Kanban y muy mal sobre Scrum u otras metodologías. Proyectos de desarrollo más tradicionales en los que la entrega de valor al cliente ha de ser rápida y mantener un ritmo controlado de evolución, son proyectos que se comportan muy bien bajo Scrum y no lo hacen tanto bajo Kanban.

Pero, ¿qué pasa con aquellos proyectos que están en un terreno gris y no nos resulta claro el aplicar una u otra forma de trabajo?

¿Has oído hablar del Scrumban ? El nombre lo dice todo, aúna lo mejor de Scrum y Kanban para comportarse adecuadamente en entornos intermedios. 

¿Quieres saber más?  Lee nuestro próximo artículo de metodologías ágiles y lo descubrirás.