Наверное в каждой dev-команде применяющей Agile найдутся люди недовольные постоянными изменениями.

Я хотел бы дать свои комментарии по Agile манифесту.

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

Работающий продукт важнее исчерпывающей документации
Большую инструкцию или пояснения по коду следует писать в свободное время. Минимальные блоки документации, описывающие формат данных и краткое описание функций или сложных моментов должны писаться вместе с кодом. И должны быть частью кода.

Сотрудничество с заказчиком важнее согласования условий контракта
С заказчиками программного обеспечения такая беда: они обычно имеют общее представление о том, чего они ждут от системы и какие-то субъективные желания. Зачастую заказчик системы даже не обладает всеми знаниями о системе, которая ему требуется, а этой компетенцией обладает какая-то группа лиц. Команда должна быть осведомлена о целях и задачах заказчика, постоянно уточнять их по мере развития проекта, и стремиться максимально помочь ему в достижении этих целей. Не только программный продукт, но и сама команда должны стать средством достижения целей заказчика. Так-то!

Готовность к изменениям важнее следования первоначальному плану
Это очень хорошо демонстрирует сущность договора на создание ПО звучит как «сначала вы делаете, потом мы платим». Вообще, это означает, что заказчик и команда должны быть готовы к тому, что могут поменяться требования к проекту в любой момент его реализации, например если:

• в середине процесса создания ПО появилась идея
• изменился/появился какой-то закон
• конкуренты выпустили новую версию своего продукта с фичей которой нет у нас
• сменилось ответственное лицо заказчика
• заказчик вспомнил важную, упущенную во время обсуждений, деталь
• мы нашли еще кого-то кто мог бы купить у нас этот же продукт, но новому заказчику нужна фича
• задача была составлена не верно/команда не верно интерпретировала задачу
• Обнаружилось, что во время сбора требований забыли про какой-то бизнес-процесс :-)
• что-то ещё

А 12 принципов Agile по-моему, настолько очевидны, что комментировать их не имеет смысла.

Про постоянные измения в одних и тех же частях системы, доработки функционала ПО.

Хотел бы привести в пример, как метафору метод прогрессивного JPEG.
В любую секунду проект готов на 100%, хотя проработанность может быть и на 4%.

Получается, что время тратится только на нужную степень прожарки, а общий вид стейка всегда ясен.

Иллюстрация выше — типичный пример методолгии Водопада (слева) и Agile (справа). Собственно, каждая итерация в Agile процессе может прибавлять 5-20% к детализации целой картины продукта. Как показывает практика, обычно продукты шипятся (сдаются в продажу или в использование) не тогда, когда они на 100% завершены, а тогда, когда подошел срок :-)

Методология Водопада — это «сначала много думаем, потом делаем, никому ничего не показываем, потом ноем о том, что этого не было в ТЗ, если стало вдруг нужно прикрутить фишечку, нужно переделывать половину системы, т. к. никто и предположить не мог что что-то придется менять когда-нибудь. Срываем сроки, называм заказчиков тупыми ублюдками, убиваемся об стену, материм манагера.»

В этом случае, на 95% готовая по методологии Agile система будет содержать в себе абсолютно все запланированные фичи работать и удовлетворять почти всем требованиям заказчика, ну и содержать какие-то небольшие недоработки.
В системе готовой на 95%, разрабатываемой по методологии водопада, скорее всего будет просто полностью отсутствовать часть требуемого функционала, а возможно некоторые части системы просто не смогут работать без тех отсутствующих 5%.

Кроме того, изготавливаемый по методолгии водопада продукт, скорее всего будет выпущен морально устаревшим, т. к. мир стремительно меняется, появляются новые технологии и конкурирующие продукты.
Методология водопада хороша там, где требования к продуту не меняются, надежность и качество ценятся вне зависимости от времени разработки и количества денег. Например, в космических программах (NASA до сих пор использует 386 процессоры). Может быть еше в ракетах и в танках.

А в остальных сферах — только Agile и постоянные изменения.