Как PM полностью с вами согласен. Здесь работает принцип "заставь дурака богу молиться - он лоб расшибет".

Чтобы какой-нибудь скрам эффективно заработал в команде, надо очень много допущений иметь.

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

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

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

Без нормальной документации новые разработчики будут тыкаться наугад. Решать задачи в 3-5 раз дольше, чем могли бы, сроки погружения в проект вырастут кратно и т.д.

В общем, нельзя сказать что гибкие методологии это плохо. Отдельные методики и ритуалы очень полезны. И они не новы! Дейли - это те же летучки на советском производстве с утра, ретроспектива - это собрание по наболевшим вопросам и т.д. В СССР в свое время тоже свой аджайл придумывали, типа НОД - научная организация труда.
Поэтому, я считаю, что все это лишь новояз. Который нельзя слепо копировать. Нельзя в это фанатично верить. И применять стоит очень осторожно. Только то, что действительно помогает. Есть академические теории управления, которые куда богаче и глубже описывают многие важные вещи. У тех же японцев можно многому научится (tps, кайдзен), голдрата почитать. В профессиональном мире скрам выглядит как игрушка

На самом деле вы и правы, и неправы одновременно. В ваших примерах много боли от неграмотного управления. Я вас понимаю.

Менять надо всё: и подход к управлению, и мышление инженера и его отношение к ограничениям.

"Постоянные скачки. Сегодня бежим туда завтра сюда. Ведь только менеджеры и коучи понимабт смысл работы" — пример нездоровой работы. Менять приоритеты каждый день — это не эджайл. Это противоречит нормальному процессу создания качественного продукта. Так и подрывающиеся жопы членов команды — это проблема. Люди важнее процессов. Людям должно быть комфортно, и они должны понимать одинаково, что выбранные приоритеты и приципы принятий решений и их пересмотра не мешают создавать качественный продукт, а наоборот способствует этому.

Суть "гибкости" эджайла не в смене приоритетов хоть каждый час, а в умении подстраиваться под изменения (рынка, понимания ЦА и её требований, бюджетных ограничений) и делать хороший продукт. Это "ловкость" и "проворность". Но никак не "сумбурность" и "хаотичность". Эджайл — это про здравый смысл, а не дикость.

"Посадим аккаунт менеджера, который будет вместо решений проблем тянуть кота за что-то.. и при каждом конфликтном случае ссылаться на пункт договора". Это как раз и противоречит идее "взаимодействие важнее согласования условий контракта". Если менеджер не способен заблаговременно выявить потребности клиента или в процессе понять, что он ошибся на старте, и перестроиться в том числе по условиям работы, это не лучший менеджер, и ему нужно развиваться как управленцу.

Суть идей эджайла в том, что не отрицается важность того, что справа. Речь про более высокий приоритет того, что слева. Например идея "работающий продукт важнее исчерпывающей документации". Документация не "не важна". Важнее появление работающего продукта.

В вашем примере "сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации", кажется, продукт не рабочий. Какой смысл в документации, если половина методов не работает? Документация должна соответствовать тому, что есть и работает. Нужно в целом делать "хорошо и качественно". Это в двух словах не объяснить. Вы бы апеллировали к некачественной или отсутствующей документации, если бы сервис, который вы приняли в работу, работает как часы, спроектирован интуитивно, понятно, код его чистый и сам себя документирует?

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