¿Está TDD en el centro de todas las metodologías de desarrollo ágil?

Aquí está mi opinión:
El desarrollo ágil de software es un grupo de métodos de desarrollo de software basados ​​en el desarrollo iterativo e incremental, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos autoorganizados y multifuncionales. (fuente: wikipedia)

Para que Agile tenga éxito, necesita equipos autoorganizados y multifuncionales. Agile no habla sobre cómo escribir código, qué debería ser la calidad del código y qué metodología de prueba debe seguir.
Agile solo dice que el control de calidad, en lugar de esperar 3 meses para comenzar a analizar las pruebas (por ejemplo, cascada), tiene un modo iterativo de desarrollo de software en el que participan todas las partes interesadas de cada fase del desarrollo del producto.

No veo cómo se relaciona esto con TDD. Siento que TDD se reduce al desarrollador individual. Cuando comencé a codificar por primera vez, nunca escuché la palabra ‘ágil’. Pero mi arquitecto practicaba TDD. Solía ​​bromear diciendo que esa es la única forma en que me aseguro de que no rompas mi código.

Si no fuera a seguir TDD (no hay absolutamente ninguna razón para hacerlo), no le impediría seguir metodologías ágiles.

Esta es mi opinión, los líderes de la industria podrían tener una opinión diferente.

Personalmente, creo que no hay NINGUNA práctica en el corazón del desarrollo ágil, fuera de las retrospectivas maaaaaaaybe.

La lista de cosas que la gente arroja (o demanda) como parte de Agile puede ser bastante grande y “ventajosa”, por lo que es bueno pensar en ellas como sugerencias, algunas con más datos que las respaldan que otras.

Por ejemplo,
TDD
BDD
Integración continua
Stand-ups
MIP / planificación de sprint
Programación en pareja
(mucho mas)

Todos estos deben ser considerados y experimentados, y usar sus retrospectivas para verificar cómo van.

TDD ayuda a capturar los requisitos del cliente, le impide hacer más de la ingeniería, incorpora la calidad y elimina la vaguedad causada por la falta de calidad del análisis de la historia.

Entonces, diría que sí, TDD es un buen facilitador para las prácticas ágiles. No está en el corazón de todas las prácticas ágiles, pero es un muy buen facilitador, entonces, ¿por qué no recogerlo?

¿Algo mejor? Prueba BDD.

Las prácticas de ingeniería como TDD, CI, BDD, etc. ayudan a mejorar la calidad y la productividad del software, pero estas no son el corazón de las prácticas ágiles.