Если пообщаться со старыми инженерами (например по радиолокации или ракетам), то оказывается что итеративные методы использвоались еще в пятидесятые, по ним сделаны наши космические и военные технологии.
Ситуация в ИТ скорее есть следствие подходов бизнеса к работе, с годовым планированием, согласованием фиксированных бюджетов, и т.д. Чтобы не пролететь со сроками-бюджатеами, нужен серьезный up-front design.
Я всегда говорил, что лучше всего понимать суть вещей от первоисточника. Наибольшее влияние на Agile оказал Кент Бек. Именно от него нахватался этих идей Роберт Мартин, который в 2001 году организовал встречу группы из числа 17 человек, которые приняли Agile Manifesto.
Кент приводит два графика стоимости изменения кода, по которым может протекать разработка.
Первый график:
https://emacsway.github.io/_images/exponential-cost-of-change.pngПри таком графике момент принятия решения играет важную роль, так как от этого зависит стоимость его реализации, причем, эта стоимость может возрасти на порядки. Это вынуждает принимать решение в момент наименьшей стоимости реализации, т.е. заблаговременно, т.е. BDUF. Это та самая причина, по которой итеративная разработка до конца 90-х, конечно же, была, но она была экономически нецелесообразной, и поэтому не нашла массовости.
Кое-что произошло в конце 90-х. Много писать не буду, скажу только, что это привело к другому графику, который приводит Кент Бек:
https://emacsway.github.io/_images/asymptotic-cost-of-change.pngПри втором графике стоимость реализации уже не так сильно зависит от момента принятия решения. Это позволяет принимать и изменять решения когда программа уже реализована, опираясь на фидбэк от практической эксплуатации решений, реализованных в предыдущих итерациях. С этого момента итеративные разработки начинают становиться массовыми, но, надо заметить, что до сих пор этот вопрос протекает проблемно, и здесь масло в огонь подлило одно судьбоносное решение Кена Швабера в Скраме. Но это уже детали.