Hace diez años, decir que eras “ágil” era suficiente para que te tomaran en serio en cualquier conversación sobre gestión de proyectos. Hoy, en muchas organizaciones, la palabra genera escepticismo — y en algunos casos, abierto rechazo.
¿Qué pasó?
El problema no es la idea. Es cómo se aplicó.
El Manifiesto Ágil, publicado en 2001, surgió como respuesta a un problema real: los proyectos de software se gestionaban con metodologías diseñadas para construir puentes, y los resultados eran predeciblemente malos.
La idea central era sana: entregar valor en ciclos cortos, involucrar al cliente, adaptarse al cambio. Nadie discute eso.
El problema llegó después, cuando “ágil” dejó de ser una forma de pensar y se convirtió en una industria. Certificaciones, frameworks, consultores, herramientas. Scrum se volvió un ritual de reuniones. SAFe se convirtió en burocracia con otro nombre. Y muchas organizaciones implementaron “agilidad” sin cambiar nada sustancial en cómo tomaban decisiones o gestionaban el trabajo.
El resultado: equipos haciendo ceremonias ágiles en organizaciones que seguían siendo profundamente jerárquicas y rígidas. La forma sin el fondo.
Lo que los datos empiezan a mostrar
En los últimos años aparecieron señales concretas de agotamiento:
El Standish Group CHAOS Report mostró que los proyectos ágiles no tienen la tasa de éxito que se les atribuía históricamente. La brecha entre lo prometido y lo entregado es menor que en proyectos predictivos clásicos, pero sigue siendo significativa.
Empresas como Basecamp, Amazon y Apple — conocidas por entregar productos de alta calidad — nunca adoptaron Scrum de forma dogmática. Su forma de trabajar tiene poco que ver con el agilismo de certificaciones.
El Spotify Model, durante años presentado como el ejemplo a seguir de organización ágil a escala, fue públicamente desacreditado por sus propios creadores: nunca fue un modelo diseñado para ser replicado.
Por qué falló la implementación a escala
Ágil funciona bien en equipos pequeños, con autonomía real, en contextos donde el cliente puede participar activamente y el costo del cambio es bajo.
El problema es que esas condiciones no se dan en la mayoría de las organizaciones medianas y grandes.
Cuando se intenta escalar agilidad sin cambiar la estructura de poder, el resultado es ceremonial: hay sprints, hay retrospectivas, hay product owners — pero las decisiones siguen tomándose en las mismas reuniones de siempre, con las mismas personas, con los mismos criterios.
El agilismo a escala requiere un nivel de delegación real que la mayoría de las organizaciones no está dispuesta a dar.
Qué dice el PMBOK 8 sobre esto
El PMBOK® Guide Eighth Edition, publicado en 2025, es sintomático del momento que vivimos.
Después de que la Séptima Edición prácticamente abandonara los procesos en favor de principios y dominios de desempeño — en un movimiento que muchos interpretaron como una capitulación al pensamiento ágil —, la Octava Edición da marcha atrás parcialmente.
Recupera 40 procesos documentados. Vuelve a hablar de entradas, herramientas y salidas. Reintroduce los Grupos de Procesos como Áreas de Enfoque. Y mantiene los tres enfoques — predictivo, ágil e híbrido — sin jerarquizar ninguno.
El mensaje implícito del PMI es claro: no existe un enfoque universalmente superior. La pregunta correcta no es “¿ágil o predictivo?” sino “¿qué necesita este proyecto en este contexto?”.
Lo que sigue siendo válido
El agotamiento del agilismo dogmático no significa que haya que volver al waterfall puro. Lo que sigue siendo válido — y seguirá siéndolo — es el núcleo de lo que el Manifiesto Ágil propuso:
- Entregar valor de forma incremental en lugar de esperar al big bang final
- Involucrar al cliente durante el proceso, no solo al inicio y al final
- Adaptar el plan cuando el contexto cambia, en lugar de defender el plan original a cualquier costo
- Priorizar las conversaciones reales sobre la documentación exhaustiva
Esos principios son sólidos. Lo que falló fue la ritualización, la certificación como fin en sí mismo y la idea de que cualquier problema organizacional se resuelve con el framework correcto.
Hacia dónde va la gestión de proyectos
Lo que está emergiendo no tiene un nombre definitivo todavía. Algunos lo llaman gestión adaptativa, otros enfoque híbrido pragmático. En esencia es esto: usar lo que funciona para cada proyecto, sin dogmatismo.
En la práctica, eso significa:
- Planificación predictiva para las fases que lo requieren — cuando el alcance es claro y el costo del cambio es alto
- Iteraciones y entregas incrementales donde el valor se puede validar rápido
- Gobernanza formal donde el contexto lo exige, sin burocracia donde no la exige
- IA como herramienta de apoyo para análisis, documentación y toma de decisiones — no como sustituto del criterio del PM
El PMBOK 8 apunta en esa dirección. El nuevo examen PMP también — si querés entender cómo cambió, tengo un artículo sobre qué cambia con el PMBOK 8 y el nuevo examen PMP.
La pregunta que vale la pena hacerse
Antes de adoptar cualquier metodología — ágil, predictiva o híbrida — la pregunta correcta es:
¿Qué problema estamos tratando de resolver?
Las metodologías son herramientas. Una herramienta no es buena o mala en abstracto — es adecuada o inadecuada para el problema que tenés enfrente.
Un PM que entiende eso — y que sabe elegir el enfoque correcto según el contexto — es más valioso que uno que domina un framework a la perfección pero no sabe cuándo no usarlo.
Si querés profundizar en cómo elegir el enfoque correcto para cada tipo de proyecto, tengo un artículo sobre predictivo, ágil o híbrido: cómo decidir.
Valeria Yashan es PMP® #1613335, MBA e Ingeniera Industrial. Consultora, docente y autora de cuatro libros sobre gestión de proyectos e IA aplicada. Trabajó con equipos en Argentina, LATAM y España. Conocé más sobre Valeria.
Para entender qué reemplaza al agilismo puro, leé Predictivo, ágil o híbrido: cómo elegir el enfoque correcto. Y para ver cómo el examen PMP refleja este cambio, PMBOK® 8 y el nuevo examen PMP 2026.