Waterfall, как средство управления IT разработкой или средство дистанцирования от IT разработки?

Ни для кого не секрет, что во многих IT компаниях сегодня, водопадная модель вполне успешно существует и применяется на практике IT менеджментом.    Я бы выделил несколько категорий «менеджмента», использующих в своей работе Waterfall:    1) Руководители/менеджеры старой закалки, консервативного взгляда, которым нужна понятная модель разработки, да еще и проверенная временем.    2) Руководители/менеджеры, которые уже имели опыт использования гибких методологий и обожглись с ними. Не получилось эффективно выстроить процессы разработки по гибкой методологии или не смогли разобраться.    3) Руководители/менеджеры, делегировавшие решение IT задач на подрядные организации.    Кто-то из менеджмента находит водопадную модель, как единственно понятную и удобную модель управления IT ресурсами, и процессами разработки. Не соглашусь, но выбор каждого, и он тоже по-своему оправдан. В конце концов, лучше хоть как-то систематизировать работу IT специалистов, чем вообще никак.    А кто-то из менеджмента, находит данную модель, как удобное средство дистанцирования от команды разработки. Не углубляясь в процессы и нюансы IT разработки, с момента передачи требований команде. Ведь зачастую, именно так трактуют для себя менеджеры суть использования водопадной модели. Ограничивая своё участие в IT разработке первым этапом водопадной модели – подготовкой требований. 

И ладно бы речь шла о работе с подрядчиком, но такое повсеместно встречается и в работе менеджмента, в чьем непосредственном подчинении находятся целые IT команды и отделы.    На сколько эффективен данный подход к управлению IT ресурсами в компаниях, остается только гадать. Не скрою того факта, что данный «стиль» менеджмента и в гибких командах встречается сегодня, но реже как мне кажется.    А что думаете вы?