Más allá de Scrum: por qué los CIOs deben repensar Agile
Durante más de dos décadas, los CIOs y líderes de TI han enfrentado una realidad frustrante: a pesar de los avances tecnológicos, los proyectos de software siguen sin cumplir expectativas. Solo el 31% de los proyectos TI tienen éxito, según el informe CHAOS 2020 del Standish Group. Esto no es un problema tecnológico, es un problema de ejecución.
La promesa de Agile y su paradoja
Scrum ha dominado la entrega de software durante 30 años, y por buenas razones. Fue un gran avance que introdujo adaptabilidad, colaboración multifuncional e iteración rápida frente a la rigidez de Waterfall. Sin embargo, como todo sistema que se institucionaliza, sus fallos se han vuelto más evidentes.
Desde la experiencia práctica, varios puntos débiles persisten:
- Las Sprint Planning a veces se convierten en juegos de póker donde se estima esfuerzo para tareas que simplemente se trasladan al siguiente Sprint
- Los story points y burndown charts no se traducen de forma significativa en progreso financiero o hitos reales
- Las daily standups no garantizan que los equipos estén construyendo lo correcto, contribuyendo al aumento de la deuda técnica
- Las mejoras continuas se postergan a las retrospectivas en lugar de abordarse en tiempo real
Los datos respaldan esta insatisfacción. El informe CHAOS 2020 del Standish Group reveló que, de los proyectos analizados, un 19% fracasaron completamente y un 50% fueron cuestionables (excedieron presupuesto, plazo o no cumplieron requisitos). Esto significa que un 69% de los proyectos no entregaron el valor esperado. Proyectos que superaban el millón de dólares tenían solo un 10% de tasa de éxito. La magnitud del problema es tal que, según un estudio de McKinsey de 2024, las empresas pierden aproximadamente 1.3 billones de dólares anuales en proyectos de TI fallidos a nivel global.
| Problema común en Scrum | Impacto real en el negocio |
|---|---|
| Planificación como juego de estimación | Tareas que se arrastran entre sprints sin valor entregado |
| Story points abstractos | Sin correlación con ROI o valor de negocio |
| Daily sin foco en calidad | Aumento de deuda técnica que ralentiza releases futuros |
| Retrospectivas diferidas | Aprendizaje lento, adaptación tardía a cambios del mercado |
| Sprints rígidos para todo tipo de trabajo | Trabajo operativo y estratégico mal dimensionado |
| Equipos aislados en sus silos | Duplicación de esfuerzos y falta de alineación estratégica |
El cambio de mentalidad: de proyectos a flujo
El Standish Group recomienda que las organizaciones dejen de tratar la entrega de software como una secuencia de proyectos finitos con plazos y presupuestos rígidos. En su lugar, el desarrollo debe verse como un flujo continuo y adaptativo de valor, refinado constantemente según las necesidades cambiantes del negocio. Las herramientas tradicionales de gestión de proyectos, por sofisticadas que sean, a menudo fallan en este punto. Dashboards demasiado complejos, informes redundantes y ciclos rígidos pueden ralentizar a los equipos.
El caso de ING: un ejemplo real de evolución
Un ejemplo que ilustra esta transformación es ING, el banco holandés. En 2015, ING reorganizó por completo su área de TI, eliminando la estructura tradicional de proyectos y adoptando un modelo de "tribus y squads" inspirado en Spotify. Pero ING fue más allá: reemplazó los story points con métricas de valor de negocio, midiendo cada iniciativa por su impacto en la satisfacción del cliente y la eficiencia operativa. Redujeron el tiempo de comercialización de nuevas funcionalidades de meses a semanas. ¿El resultado? ING pasó de ser un banco tradicional a ser reconocido como uno de los más innovadores del sector, con un coste de TI por unidad de ingresos un 30% inferior al de sus competidores.
Otro caso relevante es el de Adobe. Cuando la compañía migró su modelo de negocio de licencias perpetuas a suscripción SaaS, también transformó su enfoque de desarrollo. Adoptaron flujos de entrega continua basados en OKRs (Objectives and Key Results) en lugar de plazos de proyectos. Cada equipo mide su éxito por la adopción de funcionalidades y la retención de usuarios, no por la cantidad de story points completados. Este cambio les permitió pasar de grandes releases semestrales a entregas diarias incrementales.
Señales de que tu equipo necesita evolucionar
¿Cómo saber si tu organización está atrapada en un Scrum que ya no funciona? Estas son algunas señales:
- Las ceremonias se sienten como rituales vacíos — el Daily Scrum es un reporte de estado, no una coordinación real
- La velocidad se mide, pero el valor no — completar story points no significa entregar valor de negocio
- La deuda técnica crece sprint tras sprint — la presión por entregar sacrifica la calidad
- Los stakeholders están desconectados — no entienden el progreso en términos de negocio
- Las retrospectivas no generan cambios reales — se habla de mejorar pero todo sigue igual
- Los plazos se extienden sistemáticamente — los Sprints no terminan con un Incremento "Done" según la DoD
Marco de evaluación de madurez Agile para CIOs
Propongo un marco simple de cuatro niveles para que los CIOs evalúen dónde está su organización:
Nivel 1 — Inicial: Los equipos hacen Scrum porque "se les dijo". Las ceremonias existen pero no generan valor. Los story points son el único indicador. Hay dependencias no gestionadas entre equipos. Los stakeholders ven el proceso como una caja negra.
Nivel 2 — Funcional: Los equipos ejecutan Scrum correctamente según la guía. Hay Definition of Done, los Sprints se completan y hay retrospectivas que generan acciones. Sin embargo, la conexión con el negocio sigue siendo débil. La velocidad se mide, pero no el valor entregado.
Nivel 3 — Orientado al valor: Los equipos vinculan su trabajo a métricas de negocio. Las prioridades se establecen por valor, no por esfuerzo. Hay visibilidad del portafolio completo. Los stakeholders participan activamente en las revisiones. La entrega es continua, no por Sprints.
Nivel 4 — Adaptativo: La organización responde en tiempo real a cambios del mercado. Los equipos tienen autonomía para elegir sus métodos. Las métricas de negocio guían cada decisión. La IA y la automatización están integradas en el flujo de trabajo. La entrega de valor es continua, medible y predecible.
Para avanzar de un nivel al siguiente, los CIOs deben hacer tres preguntas clave: ¿Estamos midiendo lo correcto?, ¿Nuestros equipos tienen la autonomía necesaria para decidir cómo trabajar? y ¿Nuestros stakeholders ven el valor que entregamos en términos que entienden?
Comparación: métricas tradicionales vs. métricas de valor
| Métrica tradicional (Scrum vanilla) | Métrica de valor (evolución ágil) |
|---|---|
| Story points completados por Sprint | Impacto en ingresos o reducción de costes |
| Burndown chart | Tiempo de entrega (lead time) de principio a fin |
| Velocidad del equipo | Net Promoter Score del stakeholder interno |
| % de tareas completadas | Frecuencia de despliegue (deployments/semana) |
| Cobertura de tests | Tasa de adopción de funcionalidades por usuarios |
| Horas invertidas | Cambio en métricas de negocio (conversión, retención) |
Un CIO que sigue reportando story points al comité directivo está usando un lenguaje que nadie fuera de TI entiende. Cuando el equipo reporta "completamos 120 story points este trimestre", el negocio no sabe si eso es bueno o malo. Cuando reporta "reducimos el tiempo de procesamiento de solicitudes en un 40%, lo que se traduce en 2 millones de ahorro anual", el lenguaje es universal.
Hacia la entrega inteligente en la era de la IA
Hemos entrado en una era donde la IA, la automatización y los ecosistemas digitales exigen marcos de entrega más responsivos. Los CIOs están bajo presión para entregar valor continuo, no solo proyectos completados. Los stakeholders ya no miden el éxito solo por los plazos, sino por cómo las iniciativas tecnológicas generan resultados de negocio tangibles.
Esto no es un rechazo a Agile. Es su evolución natural. Agile nos enseñó a aceptar el cambio. Scrum nos enseñó a organizarnos para la entrega. Ahora necesitamos marcos que nos permitan entregar valor de forma rápida e inteligente.
El movimiento "Beyond Scrum" no propone abandonar el marco, sino complementarlo. Frameworks como Kanban, LeSS, SAFe o incluso enfoques híbridos permiten a las organizaciones elegir la cadencia y las prácticas que mejor se adaptan a su contexto. Un equipo de mantenimiento de sistemas legacy probablemente se beneficiará más de Kanban que de Sprints de dos semanas. Un equipo de producto que desarrolla nuevas funcionalidades para un mercado competitivo puede combinar Sprints cortos con entregas continuas basadas en trunk-based development.
Claves para la evolución
- De story points a métricas de negocio — vincula cada entregable a un resultado medible como ingresos, retención o eficiencia
- De sprints rígidos a flujo continuo — adapta la cadencia al tipo de trabajo; no todo el trabajo necesita Sprints
- De ceremonias ritualizadas a eventos con propósito — cada evento debe generar un ajuste tangible en el plan de trabajo
- De equipos aislados a portafolios visibles — los líderes necesitan visibilidad unificada de todos los proyectos y su contribución a los objetivos estratégicos
Lo que nadie te dice sobre evolucionar Agile
Lo que pocos consultores mencionan es que evolucionar desde un Scrum mal implementado hacia un marco más adaptativo requiere invertir en cultura organizacional, no solo en procesos. Los CIOs que han tenido éxito en esta transición —como los de ING, Adobe o Spotify— comparten un patrón común: invirtieron entre 12 y 18 meses en cambiar la forma en que los equipos piensan sobre el valor, antes de cambiar las herramientas o los marcos de trabajo.
La resistencia más común no viene de los equipos de desarrollo, sino de la alta dirección. Cuando los líderes ejecutivos están acostumbrados a recibir informes de hitos y fechas, migrar a métricas de flujo y valor les resulta incómodo. Mi recomendación: comienza con un piloto de tres meses con un solo equipo, mide el antes y el después en términos de velocidad de entrega y satisfacción del negocio, y usa esos datos para escalar la transformación.
Conclusión
Para los CIOs cansados de extender plazos y defender hitos incumplidos, ha llegado el momento de pilotar una forma más inteligente de trabajar —una construida sobre velocidad, adaptabilidad y transparencia.
La vieja guardia de la gestión de proyectos cumplió su propósito. La siguiente frontera pertenece a aquellos listos para evolucionar. No se trata de abandonar Scrum, sino de ir más allá: adoptar un enfoque donde la entrega de valor sea continua, medible y alineada con los resultados de negocio que realmente importan. El CIO que domine esta transición no solo mejorará la ejecución de TI, sino que se convertirá en un socio estratégico del negocio.