При чём тут водопад-то? Товарищ описал понимание "агильной разработки" глазами менеджера. А в водопаде всё лучше. В том смысле, что если к тебе прибегает менеджер и вопит, а давай срочно-срочно переделаем вот так, ты его посылаешь в долгое пешее эротическое путешествие. Переписывать и согласовывать ТЗ :)
Главные проблемы водопада - долгая реакция, соответствующая стоимость изменений, и невозможность прогнозировать если надо делать что-то новое.

У меня было немного не так. Они раньше писали эту систему с другим человеком. Тогда это была не система, а просто одна дестопная прожка. Но они даже не знали, как оно в конечном счёте выглядеть должно - всё придумывалось на ходу. Ну вот тут данные поступают с CAN-шины, и надо их посчитать вот по этим формулам, которые шеф в своей диссертации написал - всё понятно? А всякий ввод данных, вывод, способ организации расчёта, валидация, синхронизация, аппроксимация, мастур... и всё прочее - это по ходу придумаем. План работ и "тех. задание" я вёл в текстовом файле в блокноте. Заполнял задания со слов шефа и по своим соображениям. Вот тут, кстати, датчик поменялся и способ аппроксимации данных теперь не работает - меняем. А вот старый датчик вернулся - возвращаем старый способ и добавляем в меню выбор способа аппроксимации. И так по каждой мелочи много раз. Где-то в середине работы придумали сделать поддержку нескольких языков. Пришлось вкорячивать по всему написанному коду по всем слоям поддержку локализации через Resource Dictionary. Потом логирование ошибок. Потом не только ошибок, но и вообще разных действий. И если в аджайлах спринты длятся по неделям или двум, то у меня это было от пары часов (пока шеф с обеда не придёт и не скажет, что надо по-другому сделать, чем он до обеда сказал) до нескольких месяцев.

И да, я вначале не знал, как пишутся проекты с поддержкой этого всего изначально. Т.е. можно было бы заложить и локализация, и логирование, и прочее, но во-первых, это гораздо сложнее и дольше писать, как если бы это не нужно было. А во-вторых, изначально времени на это не было. Это уже когда прога более-менее оформилась и стали думать, а не предложить ли иностранным заказчикам, встал вопрос о локализации и переводе. Причём перевод должен был быть качественный - нужно было знать понятия на русском и их же на английском. Гугл Транслейт всякую чушь часто выдавал. Переводил я, как самый грамотный в английском (хе-хе!), штудируя Википедию на русском и английском и выискивая там правильные понятий. Не знаю, всё ли правильно выискал, но времени это заняло в разы дольше, чем просто в Гугл Транслейт загнать. Переводчики-люди, кстати, тоже обычные не подходили. Нужен был спец в этой области, знающий терминологию на двух языках, и ему надо было заплатить. А тут я - я вроде почти такой спец, но мне сверху платить не надо...

Вот такая была разработка.