Kanban o Scrum: un marco para decidir, no una guerra de religiones
Pocos temas en la gestión de ingeniería generan tanta pasión y tan poco avance como el debate entre Kanban y Scrum. He estado en reuniones donde gente perfectamente racional discutía la duración de los sprints con el fervor de juristas debatiendo una reforma constitucional. Y he visto equipos fracasar con Scrum y concluir que «lo ágil no funciona», cuando el problema real era que estaban apretando un tornillo a martillazos.
Esto es lo que he aprendido tras años dirigiendo y asesorando equipos de ingeniería: la metodología importa mucho menos que su encaje con tu tipo de trabajo, la madurez del equipo y la fase del producto. Scrum no es mejor que Kanban. Kanban no es mejor que Scrum. La adecuada es la que ayuda a tu equipo concreto a entregar valor con la mínima fricción.
Construyamos un marco para tomar esa decisión en lugar de elegir bando.
La diferencia de fondo: bloques de tiempo frente a flujo continuo
Antes de decidir, seamos precisos sobre lo que hace cada enfoque.
Scrum es un framework construido sobre iteraciones de duración fija (los sprints). El equipo se compromete con un alcance al inicio de cada sprint, trabaja en él durante 1-4 semanas y entrega al final un incremento potencialmente publicable. Trae roles prescritos (Product Owner, Scrum Master, equipo de desarrollo) y ceremonias (planificación del sprint, daily, revisión del sprint, retrospectiva).
Kanban es un método construido sobre el flujo continuo. No hay iteraciones. Los elementos de trabajo entran en un tablero, avanzan por etapas (pendiente, en curso, en revisión, hecho) y salen al completarse. El mecanismo central son los límites de WIP: topes al número de elementos que pueden estar en cada etapa a la vez. Cuando se libera un hueco, se incorpora trabajo nuevo.
La diferencia fundamental: Scrum agrupa el trabajo en bloques de tiempo. Kanban lo trata como un flujo continuo. Todo lo demás —las ceremonias, los roles, las métricas— se deriva de esa distinción.
Cuándo encaja Scrum
Scrum funciona mejor cuando tu equipo necesita ritmo, previsibilidad y ciclos de planificación estructurados. En concreto:
Desarrollo de producto con hitos claros. Si estás construyendo funcionalidades de cara a un lanzamiento, una demo para inversores o un roadmap trimestral, los sprints te dan puntos de control naturales. «¿Qué entregaremos en las próximas dos semanas?» es una pregunta que Scrum responde bien.
Equipos que necesitan rendir cuentas hacia fuera. Startups con inversores pidiendo avances, agencias con entregables de cliente, equipos que reportan a stakeholders que exigen plazos predecibles. Los compromisos de sprint crean una cadencia de entregables que un interlocutor no técnico puede entender.
Equipos nuevos o en formación. La estructura de Scrum hace de barandilla. Las ceremonias prescritas obligan a comunicarse. Las dailies sacan los bloqueos a la luz. Las retros fuerzan la reflexión. Para un equipo que todavía está aprendiendo a trabajar junto, ese andamiaje vale oro.
Trabajo transversal con dependencias. Cuando frontend tiene que coordinarse con backend, que a su vez tiene que coordinarse con diseño, la planificación del sprint es el momento de alinearse. «Los dos trabajamos en el flujo de pago este sprint» es la forma de evitar que dos equipos construyan piezas que no encajan.
Cuándo encaja Kanban
Kanban funciona mejor cuando el trabajo es continuo, de tamaño variable y guiado por interrupciones. En concreto:
Mantenimiento y operaciones. Corrección de bugs, incidencias reportadas por clientes, incidentes de producción, tareas de infraestructura. Este trabajo no se deja empaquetar en sprints de dos semanas: llega sin avisar, varía muchísimo de tamaño y necesita atravesar el sistema lo más rápido posible.
Equipos de soporte y SRE. Si el trabajo principal de tu equipo es responder a peticiones entrantes y no construir funcionalidades planificadas, forzarlo dentro de sprints es antinatural. Kanban te permite priorizar y procesar el trabajo según llega.
Equipos con alta tasa de interrupciones. Si más del 30% del trabajo de tu equipo no está planificado (incidentes, bugs urgentes, peticiones ad hoc de stakeholders), el compromiso de sprint se convierte en ficción. Nunca cumplirás los objetivos del sprint, y el equipo sentirá que falla constantemente incluso cuando está haciendo buen trabajo.
Equipos maduros y autoorganizados. Ingenieros con experiencia que no necesitan ceremonias para comunicarse, que tiran del trabajo por sí mismos, que entienden las prioridades sin una sesión de planificación. Kanban les da autonomía sin sobrecarga.
El marco de decisión
Así es como evalúo qué enfoque encaja en cada equipo. Puntúa cada factor y mira hacia dónde se inclina la balanza.
Elige Scrum cuando:
- El trabajo es mayoritariamente planificado (el 70% o más de la capacidad va a funcionalidades previstas)
- El equipo es nuevo o se ha reorganizado hace poco
- Los stakeholders necesitan cadencias de entrega predecibles
- El producto está en desarrollo activo con un roadmap
- El equipo tiene entre 3 y 7 personas
- Necesitas forzar la reflexión (retros) porque el equipo no la hace por sí solo
Elige Kanban cuando:
- El trabajo es mayoritariamente reactivo (el 50% o más no está planificado o viene de interrupciones)
- El equipo gestiona varios tipos de trabajo a la vez (funcionalidades + bugs + operaciones)
- El cycle time importa más que la previsibilidad
- El equipo es maduro y autoorganizado
- Necesitas el máximo throughput con trabajo de tamaño variable
- Reducir el lead time es el objetivo principal
Considera Scrumban (híbrido) cuando:
- Tienes una mezcla de trabajo planificado y no planificado
- Quieres el ritmo de los sprints pero el flujo de Kanban
- Tu equipo está en transición de un enfoque al otro
- Necesitas planificación de sprint para el roadmap pero flujo Kanban para el mantenimiento
Scrumban: el punto medio práctico
En la práctica, la mayoría de los equipos con los que trabajo acaban ejecutando alguna versión de Scrumban, aunque no lo llamen así. Se traduce en esto:
- Cadencia de sprint para planificar y hacer retros. Mantienes los ciclos de dos semanas para planificación, revisión y retrospectiva. Eso conserva el ritmo y la rendición de cuentas hacia fuera.
- Tablero Kanban con límites de WIP para la ejecución diaria. En lugar de un backlog de sprint rígido, el trabajo fluye por el tablero. Si llega un bug urgente a mitad de sprint, entra en el tablero sin «romper el sprint».
- Sin compromiso de sprint; un objetivo de sprint en su lugar. El equipo tiene un objetivo («publicar la integración de pagos»), pero no una lista cerrada de historias comprometidas. Eso reduce la ficción de los compromisos de sprint que nunca sobreviven al contacto con la realidad.
- Métricas de los dos mundos. Mide la velocidad para planificar capacidad (Scrum) y el cycle time para la eficiencia del flujo (Kanban).
Este híbrido funciona especialmente bien en equipos de 4-8 ingenieros que desarrollan producto con un 20-40% de la capacidad reservada para bugs y deuda técnica.
La variable real: la madurez del equipo
Esto es lo que he observado en docenas de equipos: el debate sobre metodología suele ser un síntoma de un problema de madurez del equipo.
A los equipos inmaduros (no en habilidades, sino en su forma de trabajar juntos) Kanban se les atraganta porque exige autodisciplina. Sin límites de WIP, todo está «en curso». Sin ceremonias, nadie se comunica. Sin compromisos de sprint, nada se termina. Estos equipos necesitan la estructura de Scrum no porque Scrum sea mejor, sino porque necesitan barandillas.
A los equipos maduros Scrum se les hace cuesta arriba porque la sobrecarga huele a burocracia. La planificación del sprint es un trámite: ya saben en qué van a trabajar. Las dailies son partes de estado que nadie necesita. El compromiso de sprint o es trivial de cumplir o lo rompe el primer incidente de producción. Estos equipos necesitan la flexibilidad de Kanban no porque Kanban sea mejor, sino porque el andamiaje se les ha quedado pequeño.
La progresión que más veo: empezar con Scrum, evolucionar hacia Kanban a medida que el equipo madura, y asentarse en un híbrido Scrumban que conserva las ceremonias útiles y descarta el resto.
Errores comunes
Hacer Scrum sin retrospectivas. Las retros son el mecanismo de mejora continua. Si te las saltas, solo estás haciendo waterfall en trozos de dos semanas.
Hacer Kanban sin límites de WIP. Un tablero Kanban sin límites de WIP es solo una lista de tareas. Todo el sentido está en limitar el trabajo en curso para mejorar el flujo y hacer visibles los cuellos de botella.
Cambiar de metodología en plena crisis. «Esto no funciona, pasemos a Kanban» es casi siempre un error. Arregla primero el problema de fondo. Ninguna metodología arregla una comunicación rota, unas prioridades difusas o unas expectativas irreales.
Medir lo que no toca. Los story points completados por sprint no miden la calidad del equipo. El cycle time por sí solo no captura el valor para el cliente. Usa las métricas para mejorar el proceso, no para juzgar a las personas.
Adherirse al framework con rigidez. Si las ceremonias de Scrum consumen el 20% del tiempo del equipo, lo estás haciendo mal. Si tu tablero Kanban tiene 12 columnas, lo estás haciendo mal. Ambos frameworks están pensados para adaptarse, no para seguirse como textos sagrados.
Cómo evaluar y cambiar
Si dudas de tu enfoque actual, prueba esto:
- Mide tu tasa de interrupciones. Durante dos semanas, registra qué porcentaje del trabajo fue planificado y cuál no. Si lo no planificado supera el 40%, los compromisos de Scrum fallarán de forma sistemática.
- Pregunta al equipo. En serio. «¿Nuestro proceso actual os ayuda o os estorba?» Obtendrás respuestas honestas.
- Haz un experimento de 6 semanas. Cambia al enfoque alternativo durante tres sprints (o seis semanas). Mide cycle time, throughput y satisfacción del equipo antes y después.
- No cantes victoria ni derrota demasiado pronto. Cualquier cambio de metodología resulta incómodo las dos primeras semanas. Dale tiempo a asentarse.
En Conectia, cuando integramos ingenieros senior en equipos de clientes, casamos su experiencia con la metodología del equipo, sea Scrum estricto, Kanban puro o un híbrido. Nuestros ingenieros han trabajado con las tres, porque la realidad de la consultoría senior es que te adaptas a lo que le funciona al equipo, y no al revés.
El mejor proceso es el que tu equipo sigue de verdad y le ayuda a entregar. Todo lo demás es ideología.
¿Necesitas ingenieros senior que se adapten a tu proceso en lugar de pelearse con él? Habla con un CTO — nuestros ingenieros de LATAM se integran en tu flujo de trabajo, tanto si usas Scrum como Kanban o algo intermedio.
