Agile: el problema de un simple nombre

Hay una concepción bastante errónea sobre el significado de 'agile', un error que, desconocimiento aparte, viene facilitado por ese nombre: 'agile'.
La palabra, 'agile, agilidad ¿qué nos sugiere? Velocidad, ¿verdad?
Pues, en lenguaje común, esa deducción es bastante correcta, pero no es cierta cuando hablamos de dirección de proyectos, no cuando hablamos de agile como frameworks para la gestión de proyectos.
De hecho, el nombre inicialmente previsto por sus fundadores para este tipo de frameworks era 'adaptativo', no 'ágil'. ¿Por qué? Pues porque el problema fundamental que querían resolver los autores del manifiesto ágil era que los requisitos del software no eran estables, sino que cambiaban a lo largo del desarrollo y, por tanto, no tenía sentido el modelo en cascada dominante en ese momento y en el que se suponía que los requisitos quedaban 'grabados en piedra' en la fase inicial del proyecto y no se modificaban posteriormente.
Los frameworks 'agile' promueven, para salvar ese problema,  ciclos iterativos breves en que se van acometiendo requisitos (historias de usuario) en bloques pequeños, se obtiene feedback sobre lo construido y se 'adapta' el desarrollo a los nuevos requisitos, la nueva realidad.
Es decir, adaptabilidad, no velocidad, era el principal objetivo.
Sin embargo, por diversos motivos, no se eligió el nombre de adaptables para estos frameworks de gestión de proyectos sino 'agiles'. Y poco a poco, con frecuencia, se ha olvidado la verdadera filosofía de agile para confundirla con un método que acelera el desarrollo.
A eso se refiere Jeff Gothelf en su breve libro 'Lean vs Agile vs Design Thinking' cuando dice:

This productization has changed the intended goal of the Agile work philosophy. Instead of focusing on the responsiveness of the software engineering teams, -i.e., how quickly a team could react in the face of uncertain market conditions, software complexity, evolving customer behavior, et al.,- Agile is being "hired" today to drive velocity.

Lo cierto es que ese malentendido sobre lo que significa agile puede ser causa de una mala aplicación del mismo y de que se pierdan algunos de los beneficios de 'agile'. ¿Cómo pensar en cambios de requisitos cuando lo que se quiere es ir rápido? ¿Cómo pensar en retrospectivas?
Es decir, que agile corre mucho riesgo de ser malentendido y, lo que es peor, mal aplicado.
Y todo por culpa de un simple nombre...