Mauro Ferrante
Agile vs Scrum vs Kanban: Cuándo Usar Cada Uno
Todos los artículos
Project Management

Agile vs Scrum vs Kanban: Cuándo Usar Cada Uno

1 de agosto de 2025
6 min

Decir 'hacemos Agile' es la frase que más escucho de clientes que en realidad hacen reuniones diarias sin ningún cambio real en su forma de trabajar. Agile es una filosofía, no un método. Scrum y Kanban son métodos concretos que implementan esa filosofía de formas muy distintas. Confundirlos cuesta tiempo, dinero y credibilidad del equipo de proyecto.

1. Agile: el framework mental, no el proceso. Agile es el conjunto de valores y principios del Manifiesto Ágil (2001): las personas sobre los procesos, el software funcionando sobre la documentación exhaustiva, la colaboración con el cliente sobre la negociación contractual, la respuesta al cambio sobre seguir un plan rígido. No dice cómo organizar los sprints, quién hace qué o cómo medir el avance. Por eso hacer Agile sin elegir un método concreto es casi siempre teatro organizacional.

2. Scrum: cuando el trabajo es predecible e iterativo. Scrum funciona cuando puedes planificar bloques de trabajo (sprints de 1-4 semanas) con un objetivo claro y un backlog priorizable. Es el framework correcto para desarrollo de producto, equipos estables con roles definidos (Product Owner, Scrum Master, Equipo de Desarrollo) y contextos donde el cliente puede dar feedback a cadencia regular. Scrum exige disciplina de roles: si el Product Owner no tiene autoridad decisional real, o el Scrum Master también hace de PM tradicional, el framework colapsa rápido.

3. Kanban: cuando el flujo importa más que el plan. Kanban funciona cuando el trabajo llega de forma continua e impredecible: soporte al cliente, operaciones, equipos de mantenimiento o contextos multi-proyecto con prioridades que cambian a menudo. No hay sprints: hay un flujo continuo con límites de work-in-progress (WIP) por columna. La métrica clave no es la velocity sino el lead time (cuánto tarda una tarea desde la entrada hasta la salida).

4. Cómo decidir en 3 preguntas. ¿El trabajo llega en oleadas planificables o de forma continua e impredecible? Oleadas significa Scrum. Continuo significa Kanban. ¿El equipo puede aislarse 1-4 semanas en un objetivo compartido? Sí significa Scrum. No significa Kanban. ¿Se necesita un cambio cultural profundo en los roles o solo visibilidad y control del flujo? Cambio profundo significa Scrum. Visibilidad significa Kanban.

5. El modelo híbrido que funciona en la práctica. Muchos equipos maduros usan Scrumban: estructura de sprints de Scrum para la planificación, tablero Kanban con límites WIP para la gestión diaria del flujo. Es el enfoque que más recomiendo a organizaciones con equipos mixtos (desarrollo + soporte) porque no fuerza a toda la empresa a un único framework rígido.

Preguntas frecuentes. ¿Puedo pasar de Scrum a Kanban a mitad de proyecto? Sí, y es más común de lo que se piensa: la señal es cuando los sprints se interrumpen constantemente por peticiones urgentes externas. ¿Es necesario certificarse (PSM, CSM) para aplicar estos frameworks? La certificación ayuda con el lenguaje común y la credibilidad ante stakeholders, pero no sustituye la experiencia práctica de adaptación al contexto específico.

Si tu equipo dice hacer Agile pero sientes que algo no encaja, hablemos: en una llamada de 30 minutos te ayudo a entender qué framework se adapta realmente a tu contexto — sin venderte una metodología preempaquetada.

¿Quieres comentarlo?