Declive y caída del Movimiento Ágil?

Cuando lei el titulo de la nota escrita por Diego primero me sorprendí, después me dio un poco de tristeza... y después trate de entender el por que fallan las metodologías agiles en la mayoría de los grupos de desarrollo.
Investigando un poco (muy poco) sobre las diferentes metodologías que estan documentadas me di cuenta que las únicas que hablan de calidad de código son las agiles, y que las "pesadas" solo hablan de cumplir el objetivo... Entonces ¿que es calidad de código? ¿que es cumplir el objetivo?.
La calidad de código es fácil de definir para los desarrolladores, teóricamente la aplicación tiene que ser robusta, escalable, etc. El cliente esto lo ve reflejado, si la aplicación es robusta no va a tener pantallas con errores que no entienda, si la aplicación es flexible cualquier cambio que pida lo va a ver reflejado en poco tiempo, etc.
La segunda pregunta también es sencilla, para el cliente es tener la aplicación andando el día establecido con todas las mejoras que el pidio... y cual debería ser el objetivo para los desarrolladores? Hacer aplicaciones de buena calidad. Y para los lideres del proyecto? Aca esta el gran problema, lamentablemente para muchos lideres el objetivo es cumplir con el cliente, que la aplicación este funcionando en el día estimado, y un problema aun mayor surge cuando los desarrolladores tomamos el mismo objetivo y no tenemos en cuenta que nuestro objetivo real (hacer aplicaciones de buena calidad). Cuando esto pasa ya no importa que metodología estes usando, siempre va a "fracasar" el proyecto, por que siempre el usuario va a pedir algo que nos va a llevar a pensar que es mas fácil rehacer toda la aplicación.
Es necesario que una metodología nos obligue a hacer testeos? por que no podemos darnos cuenta que el no documentar, con el tiempo, nos va a traer dolores de cabeza?. Creo que es por que muchos de nosotros (desarrolladores) estamos tomando el objetivo equivocado, tenemos que aprender a decir "no, no llego en ese tiempo" y nunca decir, pero nunca decir o pensar en la frase "Si, no hay problema, dejo de hacer test y llego cómodo". También tenemos que aprender que si un lider/jefe se enoja o nos pone mala cara cuando le decimos "necesito mas tiempo" es el que esta equivocado, es el que no esta entendiendo que si hoy cumplo con el tiempo estimado sin hacer test o sin documentar, seguramente mañana vamos a tardar el doble de tiempo haciendo refactors por que ni me acuerdo que hacia el método que desarrollé hace 1 mes. Lo mismo pasa con la relación entre el lider y el usuario final, ahí el usuario va a tener que entender que nosotros necesitamos tener calidad en el código, que eso le va a traer beneficios en el tiempo de todas las mejoras que vaya pidiendo.
Para que una metodología "funcione" tiene que existir un compromiso muy fuerte entre todas las partes implicadas (usuario, analistas, lider, desarrolladores, QA) y antes de empezar con el proyecto, poner sobre la mesa estos objetivos, y decidir que metodología es la correcta utilizar en ese caso. Es muy, pero muy importante tener muy en cuenta que un proyecto fracasa cuando alguno de los objetivos (sin importar cual) no se cumple .