П>В понимании agile — не было, а так — вполне себе:
П>анализ требований -> постановка задач -> разработка -> тестирование -> показ промежуточной версии заказчику ->

это и есть релиз. собрали билд, зарелилизи, показали. очень близко к agile, заметно ближе чем к вотерфолу. можно жонглировать терминами, но смысл этих релизов не изменится. они нужны что бы вовремя получить фидбэк, и внести изменения по ходу разработок.

П>Я ж говорю, главная претензия к agile — то, что каждые две недели (в особо извращенных случаях — неделю) за каким-то чертом заставляют непременно релизиться, из-за чего работа моментально превращается в соковыжималку, а проект перманентно пребывает в состоянии "фиг знает, где тут что работает, а что [уже/еще] нет". Если это безумное требование из методологии убрать — по ней можно вполне комфортно и эффективно работать... ...вот только это получается уже не agile.

никто в здравом уме не выполняет все ритуалы agile дословно. релизьте на uat, если уж так хочется. я и такие команды видел. но в моем проекте это была бы такая боль, реже чем в 2 недели релизить, что я бы пожалуй сбежал, чем участвовать в релизах полугодовой работы.

П>В строительстве — никак. В разработке софта — запросто, о том и речь.

в урюпенске может и запросто, на наших широтах такое не встречал. если надо сменить стену, значит будет таск на анализ и очень вероятно отдельный таск прототип.
те кто меняют стену по первой просьбе клиента — им пофигу в рамках какой методологии говнокодить.