Kanban vs. Scrum: un Marco de Decisión, no una Guerra Religiosa
Pocos temas en la gestión de ingeniería generan tanto calor y tan poca luz como el debate entre Kanban y Scrum. He estado en reuniones donde personas por lo demás racionales discutían sobre la duración de los sprints con la pasión de constitucionalistas debatiendo enmiendas. He visto equipos fracasar con Scrum y concluir "el agile no funciona", cuando el verdadero problema era que estaban usando un martillo en un tornillo.
Esto es lo que he aprendido después de dirigir y asesorar equipos de ingeniería durante años: la metodología importa mucho menos que si encaja con tu tipo de trabajo, la madurez del equipo y la etapa del producto. Scrum no es mejor que Kanban. Kanban no es mejor que Scrum. El correcto es el que ayuda a tu equipo específico a entregar valor con la menor fricción.
Construyamos un marco para tomar esa decisión en lugar de elegir bandos.
Entendiendo la Diferencia Central
Scrum es un framework construido alrededor de iteraciones de duración fija (sprints). El equipo se compromete a un alcance de trabajo al inicio de cada sprint, trabaja en él durante 1-4 semanas y entrega un incremento potencialmente publicable al final. Viene con roles prescritos (Product Owner, Scrum Master, Equipo de Desarrollo) y ceremonias (planificación del sprint, standup diario, revisión del sprint, retrospectiva).
Kanban es un método construido alrededor del flujo continuo. No hay iteraciones. Los elementos de trabajo entran en un tablero, se mueven a través de etapas (Por Hacer, En Progreso, En Revisión, Hecho) y salen cuando se completan. El mecanismo central son los límites de WIP — topes en cuántos elementos pueden estar en cualquier etapa simultáneamente.
La diferencia fundamental: Scrum agrupa el trabajo en cajas de tiempo. Kanban trata el trabajo como un flujo continuo.
Cuándo Encaja Scrum
Scrum funciona mejor cuando tu equipo necesita ritmo, previsibilidad y ciclos de planificación estructurados. Específicamente:
Desarrollo de producto con hitos claros. Si estás construyendo funcionalidades hacia un lanzamiento, una demo de fundraising o un roadmap trimestral, los sprints ofrecen puntos de control naturales.
Equipos que necesitan responsabilidad externa. Startups con inversores preguntando por el progreso, agencias con entregables para clientes, equipos que reportan a stakeholders que quieren plazos predecibles.
Equipos nuevos o en formación. La estructura de Scrum proporciona raíles. Las ceremonias prescritas fuerzan la comunicación. Los standups diarios hacen salir los bloqueos. Las retros fuerzan la reflexión.
Trabajo multifuncional con dependencias. Cuando frontend necesita coordinarse con backend y con diseño, la planificación del sprint es el momento para alinearse.
Cuándo Encaja Kanban
Kanban funciona mejor cuando tu trabajo es continuo, variable en tamaño e impulsado por interrupciones. Específicamente:
Mantenimiento y operaciones. Correcciones de bugs, problemas reportados por clientes, incidentes de producción, tareas de infraestructura. Este trabajo no encaja ordenadamente en sprints de dos semanas.
Equipos de soporte y SRE. Si el trabajo principal de tu equipo es responder a solicitudes entrantes en lugar de construir funcionalidades planificadas, forzar ese trabajo en sprints es antinatural.
Equipos con altas tasas de interrupción. Si más del 30% del trabajo de tu equipo no está planificado, el compromiso del sprint de Scrum se convierte en ficción.
Equipos maduros y auto-organizados. Ingenieros experimentados que no necesitan ceremonias para comunicarse, que naturalmente toman el trabajo, que entienden las prioridades sin una sesión de planificación del sprint.
El Marco de Decisión
Elige Scrum cuando:
- El trabajo es principalmente planificado (más del 70% de la capacidad va a funcionalidades planificadas)
- El equipo es nuevo o recientemente reorganizado
- Los stakeholders necesitan cadencias de entrega predecibles
- El producto está en desarrollo activo con un roadmap
- El equipo tiene entre 3-7 personas
Elige Kanban cuando:
- El trabajo es principalmente reactivo (más del 50% es no planificado o impulsado por interrupciones)
- El equipo maneja múltiples tipos de trabajo (funcionalidades + bugs + ops)
- El cycle time importa más que la previsibilidad
- El equipo es maduro y auto-organizado
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á transitando de un enfoque al otro
Scrumban: el Terreno Intermedio Práctico
En la práctica, la mayoría de los equipos con los que trabajo terminan ejecutando alguna versión de Scrumban. Así es como se ve:
- Cadencia de sprint para planificación y retros. Aún tienes ciclos de dos semanas para planificación, revisión y retrospectiva.
- Tablero Kanban con límites de WIP para la ejecución diaria. En lugar de un backlog de sprint rígido, el trabajo fluye a través del tablero.
- Sin compromiso de sprint — un objetivo de sprint en su lugar. El equipo tiene un objetivo pero no una lista rígida de historias comprometidas.
- Métricas de ambos mundos. Rastrear velocidad para la planificación de capacidad (Scrum) y cycle time para la eficiencia del flujo (Kanban).
La Variable Real: Madurez del Equipo
Los equipos inmaduros luchan con Kanban porque requiere autodisciplina. Los equipos maduros luchan con Scrum porque el overhead parece burocracia.
La progresión que veo con más frecuencia: empezar con Scrum, evolucionar hacia Kanban a medida que el equipo madura, asentarse en un híbrido Scrumban que mantiene las ceremonias útiles y descarta el resto.
Errores Comunes
Hacer Scrum sin retrospectivas. Las retros son el mecanismo de mejora continua.
Hacer Kanban sin límites de WIP. Un tablero Kanban sin límites de WIP es solo una lista de tareas.
Cambiar de metodología durante una crisis. Soluciona el problema subyacente primero.
Medir las cosas equivocadas. Los story points completados por sprint no son una medida de calidad del equipo.
Adherencia rígida al framework. Ambos frameworks están pensados para ser adaptados, no seguidos como textos religiosos.
En Conectia, cuando integramos ingenieros senior en equipos de clientes, adaptamos su experiencia a la metodología del equipo. Nuestros ingenieros han trabajado con las tres metodologías, porque la realidad del trabajo de consultoría senior es que te adaptas a lo que funciona para el equipo, no al revés.
¿Necesitas ingenieros senior que se adapten a tu proceso en lugar de combatirlo? Habla con un CTO — nuestros ingenieros de LATAM se integran en tu flujo de trabajo, ya sea que uses Scrum, Kanban o algo intermedio.
