Scrum o Kanban: cómo elegir el método correcto, con lecciones de la banca

Respuesta corta: usa Scrum cuando tu equipo construye un producto nuevo, el alcance se descubre en el camino y necesitas un ritmo fijo de entregas y revisiones con el negocio. Usa Kanban cuando el trabajo llega de forma continua e impredecible (soporte, mantenimiento, operaciones, solicitudes internas) y lo que necesitas es fluidez y visibilidad. No es una decisión para toda la empresa: es una decisión por equipo y por tipo de trabajo. Y ninguno funciona si solo se copian las ceremonias sin cambiar la cultura.

En muchas organizaciones de la región, “ser ágil” se volvió sinónimo de “hacer Scrum”. Se capacita a todos, se nombran Scrum Masters, se instalan sprints de dos semanas y, meses después, los proyectos siguen igual de lentos. El problema no suele ser Scrum. El problema es aplicarlo a todo, sin preguntarse si encaja.

En TechyWe acompañamos procesos de adopción ágil en banca, seguros y tecnología. Estas son las lecciones que más se repiten.

Scrum en pocas palabras

Scrum organiza el trabajo en iteraciones de duración fija, llamadas sprints. Al inicio de cada una el equipo se compromete con un objetivo; al final muestra un incremento funcional y reflexiona sobre cómo mejorar. Tiene tres responsabilidades claras: el Product Owner, que prioriza; el Scrum Master, que facilita y remueve obstáculos; y el equipo de desarrollo, que construye.

Scrum brilla cuando:

• El producto es nuevo o está cambiando mucho.
• El negocio necesita ver avances con frecuencia para decidir el siguiente paso.
• El equipo es estable y está dedicado al mismo producto.
• Hay alguien con autoridad real para decir qué va primero.

Kanban en pocas palabras

Kanban visualiza el trabajo en un tablero con columnas que representan las etapas del proceso. Su regla central es limitar el trabajo en curso: un equipo no empieza algo nuevo hasta terminar lo que tiene. No hay iteraciones obligatorias; el trabajo fluye y se mide cuánto tarda cada elemento en pasar de “por hacer” a “terminado”.

Kanban brilla cuando:

• El trabajo llega de forma continua y con prioridades cambiantes.
• Hay mucha variedad en el tamaño de las tareas.
• El equipo atiende soporte, mantenimiento o solicitudes de otras áreas.
• Necesitas mejorar un proceso existente sin reorganizar roles.

Cómo elegir: cinco preguntas

1. ¿El trabajo es planificable en bloques de dos a cuatro semanas?

Si puedes comprometer un objetivo para las próximas semanas sin que lo interrumpan a diario, Scrum funciona. Si cada día llegan urgencias que no pueden esperar, Kanban se adapta mejor.

2. ¿Estás construyendo algo nuevo o manteniendo algo existente?

Producto nuevo con mucha incertidumbre: Scrum. Operación y mejora continua: Kanban.

3. ¿Tienes un Product Owner con autoridad?

Scrum sin un responsable de producto empoderado se convierte en una lista de pendientes que nadie prioriza. Si ese rol no existe todavía, empezar con Kanban y visibilizar el trabajo puede ser el primer paso.

4. ¿Qué tan estable es el equipo?

Scrum supone un equipo dedicado. Si las personas se reparten entre varios proyectos, el flujo de Kanban suele ser más realista.

5. ¿Qué problema quieres resolver?

Si el problema es falta de foco y entregas que nunca llegan, el ritmo de Scrum ayuda. Si el problema es que el trabajo se atasca y nadie sabe dónde, la visibilidad de Kanban ayuda.

Lecciones de la banca y los seguros

Banco G&T Continental: Scrum no siempre es la respuesta

En Banco G&T Continental identificamos una ralentización en el desarrollo de proyectos internos que afectaba la propuesta de valor de la empresa. Al revisar cada proyecto encontramos dónde se perdía el tiempo, y para varios de ellos la mejor opción no era Scrum sino Kanban: un método más ligero para trabajo que necesitaba fluir.

Los resultados registrados en el caso: desarrollo diez veces más rápido en proyectos internos y un 30% de ahorro en tiempo y gastos operativos para el desarrollo de proyectos, además de una cultura ágil que se convirtió en valor para los clientes del banco.

La lección: elegir el método por tipo de proyecto, no por moda.

Banco Cuscatlán: dejar de hacer agilismo para ser ágiles

Banco Cuscatlán ya conocía la teoría de Scrum, pero la organización todavía no percibía un modelo ágil e innovador en sus nuevos productos. Había ceremonias, pero no los resultados que deberían traer.

El trabajo consistió en reorientar ese conocimiento hacia la cultura y los valores ágiles, y en acompañar a equipos de tecnología y de negocio para descubrir dónde aplicar Scrum, dónde Kanban y dónde DevOps. Hoy el banco cuenta con una fábrica digital interna enfocada en construir productos de forma ágil.

La lección: la teoría es necesaria, pero la agilidad se demuestra en los productos que salen al mercado.

SISA Seguros: de la teoría a la práctica

SISA Seguros necesitaba modernizar sus métodos de trabajo para crear productos digitales desde su fábrica digital. Se adoptó una cultura orientada al agilismo con Scrum y Kanban, junto con prácticas como el Customer Journey Mapping para diseñar productos alrededor de la experiencia del cliente. Seguimos siendo parte activa de sus equipos mediante acompañamiento continuo.

La lección: combinar métodos de ejecución con prácticas centradas en el cliente evita construir rápido algo que nadie necesita.

Paso a paso para adoptar el método correcto

1. Mapea los tipos de trabajo. Separa construcción de productos nuevos, mantenimiento, soporte y solicitudes internas.
2. Asigna un método por tipo. Scrum para lo que se puede planificar por iteraciones, Kanban para lo que fluye.
3. Define roles reales. Asegúrate de que exista un responsable de producto con autoridad y tiempo.
4. Empieza con un equipo piloto. Elige un equipo con un reto visible y voluntad de probar.
5. Mide desde el inicio. En Scrum, qué se entrega en cada sprint y si se usa; en Kanban, cuánto tarda cada elemento en completarse y dónde se acumula.
6. Acompaña, no solo capacites. Un coach que participa en las ceremonias y en el día a día acelera la adopción más que un taller aislado.
7. Escala con lo aprendido. Lleva a otros equipos lo que funcionó, adaptado a su realidad.

Errores comunes

Imponer un solo método a toda la organización

Cada equipo tiene un tipo de trabajo distinto. Uniformar el método por comodidad administrativa suele frenar a quienes no encajan.

Hacer Scrum sin Product Owner

Sin alguien que decida prioridades, los sprints se llenan de pedidos de todas partes y no hay objetivo.

Kanban sin límites de trabajo en curso

Un tablero con cuarenta tarjetas en “en proceso” no es Kanban, es una lista de pendientes con colores.

Confundir ceremonias con agilidad

Hacer dailies no te hace ágil. Entregar valor con frecuencia, aprender y ajustar sí.

Dejar fuera al negocio

Si solo tecnología adopta el método, el resto de la organización sigue funcionando con la lógica anterior y los cuellos de botella se mueven de lugar.

Preguntas para tu coach o consultor ágil

• ¿Cómo deciden qué método aplicar a cada equipo?
• ¿Su acompañamiento incluye trabajar con los equipos en el día a día o solo capacitaciones?
• ¿Cómo involucran a las áreas de negocio?
• ¿Qué métricas usan para saber si la adopción funciona?
• ¿Qué certificaciones y experiencia práctica tiene su equipo?
• ¿Cómo dejan capacidades instaladas para que no dependamos de ustedes?

Más allá de Scrum y Kanban

Scrum y Kanban son los marcos más conocidos, pero no los únicos. Algunas prácticas complementan cualquiera de los dos:

• DevOps: integra desarrollo y operaciones para que el software llegue a producción de forma frecuente y confiable, con automatización de pruebas y despliegues. En Banco Cuscatlán fue parte del acompañamiento junto con Scrum y Kanban.
• Lean: pone el foco en eliminar desperdicio y en entregar valor al cliente con el menor esfuerzo posible.
• Customer Journey Mapping: dibuja el recorrido del cliente para descubrir dónde están los dolores y las oportunidades antes de construir. En SISA Seguros se usó para diseñar productos alrededor de la experiencia del cliente.

La combinación correcta depende del equipo y del producto. Lo importante es que cada práctica responda a un problema real y no se adopte por inercia.

Cómo saber si la adopción está funcionando

Más allá de las métricas de cada método, hay señales cualitativas que conviene observar después de algunos meses:

• El negocio participa en las revisiones y toma decisiones con lo que ve.
• Los equipos saben qué es lo más importante esta semana y por qué.
• Los problemas se discuten abiertamente en las retrospectivas y se convierten en acciones.
• El trabajo terminado llega a manos de usuarios, no se queda esperando.
• Las personas proponen mejoras al método, en lugar de seguirlo por obligación.

Si estas señales no aparecen, revisa si el método encaja con el tipo de trabajo y si existe acompañamiento suficiente. A veces el cambio necesario es pequeño: pasar un equipo de soporte de Scrum a Kanban, o asignar un responsable de producto con tiempo real para el rol.

Cómo te ayuda TechyWe

Nuestro servicio de agilismo combina capacitación práctica con acompañamiento: implementamos Scrum, Kanban y otros marcos donde aportan valor, con un equipo que cuenta con certificaciones como Scrum Master y Scrum Product Owner. Cuando el reto es más amplio que la forma de trabajar, lo integramos con transformación digital.

Si estás armando equipos nuevos, te puede interesar cómo decidir entre células de desarrollo y equipo interno, y si estás dando los primeros pasos, por dónde empezar la transformación digital.

¿Tus equipos tienen las ceremonias pero no los resultados? Agenda una reunión y revisemos juntos qué método le conviene a cada uno.

Preguntas frecuentes

¿Cuál es la diferencia principal entre Scrum y Kanban?

Scrum organiza el trabajo en iteraciones de duración fija con roles y eventos definidos. Kanban organiza el trabajo como un flujo continuo, visualizado en un tablero, con límites al trabajo en curso. Scrum da ritmo; Kanban da flujo.

¿Puedo usar Scrum y Kanban en la misma empresa?

Sí. Es habitual que los equipos que construyen productos nuevos usen Scrum y que los equipos de soporte, mantenimiento u operaciones usen Kanban. Lo importante es que cada equipo use el método que encaja con su tipo de trabajo.

¿Kanban es menos ágil que Scrum?

No. Ambos se basan en valores ágiles como la transparencia, la mejora continua y la entrega de valor. Kanban es más ligero en estructura, pero exige disciplina para limitar el trabajo en curso y medir el flujo.

¿Por qué fallan muchas implementaciones de Scrum?

Porque se adoptan las ceremonias sin cambiar la cultura: hay dailies y sprints, pero las prioridades cambian a diario, nadie tiene autoridad de producto y no se entrega nada utilizable al final de cada ciclo.

¿Cuánto tiempo toma adoptar un método ágil?

La capacitación puede ser corta, pero la adopción real lleva más tiempo porque implica cambiar hábitos. Por eso recomendamos acompañamiento práctico con los equipos y no solo talleres teóricos.

¿El agilismo sirve fuera del área de tecnología?

Sí. Equipos de negocio, producto y operaciones también se benefician de visualizar su trabajo, priorizar mejor y entregar en ciclos cortos.