Metodologías de Desarrollo Ya

Kanban y Scrum son dos de los métodos ágiles más populares, pero abordan la gestión del trabajo de maneras fundamentalmente diferentes. Entender sus diferencias y similitudes es clave para elegir el enfoque adecuado para cada contexto.

10.1. Diferencias en estructura, roles y planificación

Aspecto	Scrum	Kanban
Estructura y Ritmo	Iterativo y prescriptivo. El trabajo se organiza en Sprints de duración fija (ej. 2 semanas).	Basado en flujo continuo. No hay iteraciones; el trabajo fluye de una etapa a otra a medida que hay capacidad.
Roles	Prescribe 3 roles formales: Product Owner, Scrum Master y Equipo de Desarrollo.	No prescribe roles. Se empieza con la estructura y roles existentes.
Planificación	El equipo se compromete con un conjunto de trabajo (Sprint Backlog) al inicio de cada Sprint.	La planificación es continua. Las tareas se "tiran" (pull) del backlog hacia el flujo cuando el equipo tiene capacidad.
Métricas Clave	La Velocidad (puntos de historia por Sprint) es la métrica principal para la planificación.	El Lead Time, Cycle Time y Throughput son las métricas clave para medir y predecir el flujo.
Gestión de Cambios	El Sprint Backlog debe permanecer estable durante el Sprint para proteger el Sprint Goal.	Los cambios de prioridad son bienvenidos en cualquier momento, siempre que no se violen los límites WIP.
Reuniones (Cadencias)	Prescribe eventos formales: Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.	Sugiere cadencias como la Daily Kanban, Service Delivery Review y Operations Review, pero son adaptables.

10.2. Similitudes y puntos de convergencia

A pesar de sus diferencias, ambos métodos comparten principios ágiles fundamentales:

Ambos utilizan la transparencia a través de tableros visuales.
Ambos son sistemas "pull" (Scrum tira del Product Backlog al Sprint Backlog; Kanban tira del backlog al flujo).
Ambos buscan entregar valor de forma incremental y se centran en la calidad del producto final ("Definition of Done").
Ambos promueven la autoorganización del equipo y la mejora continua.

10.3. Cuándo elegir Kanban, cuándo Scrum

Elige Scrum cuando:

Tu organización está empezando con Agile y necesita un marco prescriptivo que le guíe.
El trabajo se puede planificar y agrupar en bloques de tiempo fijos (Sprints).
Necesitas un compromiso de entrega para un conjunto de funcionalidades en una fecha determinada (el final del Sprint).
El proyecto es de desarrollo de un nuevo producto con hitos claros.

Elige Kanban cuando:

El flujo de trabajo es continuo y las prioridades cambian con frecuencia (ej: equipos de soporte, mantenimiento, operaciones).
Quieres empezar a mejorar tu proceso actual sin hacer cambios drásticos en la estructura o los roles.
El objetivo principal es optimizar el flujo de entrega, reducir el tiempo de ciclo y aumentar la previsibilidad.
Tu equipo ya tiene madurez ágil y quiere evolucionar de un modelo de iteraciones a uno de flujo continuo.

10.4. Modelos híbridos: Scrumban

No es necesario elegir uno u otro. Muchos equipos de alto rendimiento adoptan un modelo híbrido conocido como Scrumban, que combina lo mejor de ambos mundos.

Un equipo que usa Scrumban podría:

Mantener la estructura de Sprints, los roles y las reuniones de Scrum.
Añadir los principios de Kanban dentro del Sprint: visualizar el flujo en un tablero con columnas detalladas, establecer límites WIP para cada columna y medir el Cycle Time y el Throughput.

El beneficio es que el equipo mantiene la estructura predecible de Scrum mientras utiliza las herramientas de Kanban para mejorar su flujo, gestionar cuellos de botella y ser más eficiente y flexible durante el Sprint. Es un paso evolutivo natural para muchos equipos Scrum.