Durante los últimos años se ha vuelto habitual escuchar la misma acusación, repetida con distintos matices pero con una convicción cada vez mayor: Agile es el problema. Agile arruinó el delivery. Agile destruyó la disciplina. Agile prometió más de lo que pudo cumplir.

La narrativa es comprensible. Después de años de transformaciones incompletas, de organizaciones cansadas y de equipos permanentemente ocupados pero sin impacto claro, buscar un culpable visible resulta tentador. En ese contexto, un post reciente de Israel Bovolini puso palabras a algo que muchos hemos visto de cerca: Agile rara vez es la causa raíz del fracaso. Lo que hace, más bien, es acortar los ciclos de feedback y dejar al descubierto problemas que ya estaban ahí.

Esa mirada es valiosa. Y necesaria. Pero no es suficiente.Porque si nos quedamos solo con esa explicación, corremos el riesgo de contarnos una historia cómoda: las organizaciones no estaban listas, el liderazgo no cambió, los incentivos siguieron mal alineados. Todo eso es cierto. Pero no es toda la verdad.

Agile no falló. Lo que falló fue la creencia de que podía funcionar sin cambiar cómo operan realmente el poder, las decisiones y el liderazgo. Y cuando esa tensión apareció —porque era inevitable que apareciera— muchos elegimos no mirarla de frente. Más tarde, ayudamos a desplazar la culpa.

Cuando quienes hacen el trabajo dejan de creer

Hay una señal que hoy resulta imposible de ignorar. Ya no son solo ejecutivos o managers quienes cuestionan Agile. Cada vez más desarrolladores lo rechazan abiertamente. No con escepticismo moderado, sino con una mezcla de cansancio y desconfianza. Y, contra lo que suele asumirse, no se trata principalmente de reuniones, ceremonias o rituales.

Se trata de resultados. Desde su experiencia, Agile prometió foco y entregó ruido. Prometió empoderamiento y entregó visibilidad sin autoridad. Prometió sostenibilidad y entregó una cinta caminadora más rápida. Aumentaron la transparencia y la rendición de cuentas. Aumentó la presión. Pero el poder real de decisión se mantuvo intacto.

Cuando las personas más cerca del trabajo dejan de creer, el problema deja de ser metodológico o cultural. Se convierte en un problema de credibilidad. Y descartar esa reacción como “resistencia al cambio” o “falta de mindset ágil” no hace más que profundizar la fractura.

Ese rechazo no es inmadurez. Es juicio empírico.

Un acuerdo necesario: Agile rara vez es la causa raíz

Conviene ser explícitos respecto a lo que este texto no es. No es un alegato contra Agile. Agile sigue importando. Muchas de sus prácticas siguen siendo potentes, y la evidencia muestra correlaciones claras entre formas de trabajo ágiles y mejores ciclos de feedback, mayor adaptabilidad y mayor cercanía con el cliente, cuando el sistema que las rodea las sostiene.

Cuando las transformaciones fracasan, las causas se repiten con una regularidad casi incómoda: comportamiento del liderazgo, derechos de decisión poco claros, incentivos mal diseñados, gobernanza rígida, baja seguridad psicológica. Agile no crea estos problemas. Los hace visibles antes y de forma más pública.

En ese sentido, Agile funciona como un espejo. Y los espejos, por sí solos, raramente son el problema.

El límite del espejo: exponer no es intervenir

Aquí es donde la conversación necesita avanzar. Poner un espejo dentro de un sistema humano complejo no es un acto neutral. Redistribuye atención, presión y responsabilidad. Saca a la superficie tensiones que antes estaban amortiguadas por planes, documentos y jerarquía. Y lo hace a la vista de todos.

Podíamos haberlo anticipado. Sin embargo, cuando las organizaciones reaccionaron de forma defensiva, muchos preferimos interpretar la situación como “el sistema resistiéndose al cambio”. Algo de eso había. Pero no era toda la historia. Introducir Agile sin tocar derechos de decisión, incentivos ni comportamiento directivo iba a generar fricción inevitablemente. No porque Agile estuviera equivocado, sino porque el sistema no estaba diseñado para absorber lo que la agilidad realmente exige.

Exposición sin hacerse cargo no es transformación. Es provocación.

Agile y agilidad: una confusión que nos pasó la cuenta

En este punto, una distinción se vuelve inevitable, aunque no siempre sea evidente.

Agile refiere a prácticas, marcos y a un movimiento que surgió como respuesta a problemas muy reales. La agilidad, en cambio, es una capacidad: la habilidad de una organización para percibir cambios, decidir en contextos de incertidumbre y adaptarse de forma coherente.

Confundir ambos conceptos ayudó a que Agile se difundiera rápidamente. Pero también limitó la profundidad del cambio que las organizaciones creyeron necesario. Las prácticas viajaron más rápido que el criterio. El lenguaje, más rápido que la comprensión. Y muchas organizaciones adoptaron rituales ágiles sin modificar estructuras de poder, incentivos ni modelos de liderazgo.

Agile sigue siendo relevante. Pero nunca fue suficiente por sí solo.

La deuda evolutiva que evitamos nombrar

Todo movimiento exitoso acumula deuda. Agile no es la excepción. Con el tiempo, se generó una deuda evolutiva. Las prácticas escalaron más rápido que la capacidad colectiva de hacer autocrítica. El éxito postergó las conversaciones más incómodas. Y cuando los resultados no coincidieron con la promesa, resultó más fácil defender Agile que revisar cómo lo habíamos posicionado e introducido.

No se trata de buscar culpables. Se trata de asumir responsabilidad. La agilidad evolucionó más rápido en la práctica que en el juicio. Y cuando esa brecha se volvió evidente, muchos optamos por mirar hacia otro lado —o por ubicar el problema exclusivamente en “la organización”.

Intervenir sistemas humanos no es gratis

La agilidad real tiene costos. No financieros, sino estructurales y políticos. Exige cambiar cómo se toman decisiones, cómo se distribuye la autoridad y cómo los líderes se comportan frente a la incertidumbre. Introducir Agile sin prepararse para esos costos no es ingenuidad. Es irresponsabilidad.

La agilidad no se instala. Se absorbe. Y cada organización tiene una capacidad —y un ritmo— distinto para hacerlo. Ignorar esa realidad no acelera el cambio. Provoca que el sistema se defienda con más fuerza.

Aquí el liderazgo importa, pero no como patrocinio simbólico. Importa como comportamiento cotidiano.

Lo que aprendimos y por qué trabajamos así en itera

Estas conclusiones no vienen de la teoría. Vienen de la práctica.

Desde el inicio, nuestro trabajo nunca giró en torno a frameworks primero. Giró en torno a comportamiento directivo, derechos de decisión y al ritmo real al que una organización puede evolucionar sin romperse. Nunca tratamos Agile como la transformación, sino como una herramienta dentro de una intervención humana mucho más amplia.

No fue purismo. Fue supervivencia.

El espejo sigue siendo necesario

Agile sigue importando. El espejo sigue siendo valioso. Pero hoy sabemos algo que ya no podemos des-saber: poner ese espejo sin hacerse cargo de lo que refleja es el verdadero error. No Agile. No los equipos. Ni siquiera la resistencia.

La agilidad no falla en silencio. Falla de forma ruidosa, temprana y pública. Y eso nunca fue un defecto.

Fue una advertencia que tardamos demasiado en escuchar.