Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.
чем?

Тем что в конце разработки продукт будет ближе к хотелкам клиента, которые он в начале не может даже представить, не то что озвучить. А потому с таким клиентом любой нецикличный метод разработки обречен на провал.

Как поможет скрам? 1. Цикличностью и постоянным общением с заказчиком (как минимум на ревью). и 2. тем что скрам это "модно".

Подробнее:

1. Спринты короткие, по результатам спринта, которые демонстрируются клиенту можно уточнить предыдущие хотелки и получить новые. И внезапно из "и всё сиреневое!" получается "когда пользователь нажимает кнопку 'Отправить данные', появляется диалоговое окно, запрашивающее подтверждение, а вся рабочая область приложения становится неактивной. Гравичеки это отображается в "затемнении" рабочей области, наложении "сиреневой дымки".

Такое уже попроще обсуждать и реализовывать, да? Но клиент в состоянии выродить такое (в беседе с ПО) тольео когда уже видит перед собой окошко программки с кнопкой "Отправить данные". До этого он уверен что всё и так понятно.

Т.е. наша задача упрощается - из клиента надо выбить достаточно информации чтобы создать "ходячий скелет" (walking skeleton) приложения. А потом ему демонстрируется результат разработки, и он может внести свои "сверхважные" замечания (вроде "перенести кнопочку налево", "сделать заголовок больше", "а тут не красный а оранжевый") и чувствовать себя влияющим и командующим всем и все. И это делает его счастливым до одури :) А пока он счастливый, расслабившийся и тепленький, его пытает ПО на тему "а теперь давайте уточним что вы имели в виду под "вздыщь!". И сразу на бумажку. (Ну, или в тикет в джире). Через две (3,4) недели всё повторяется но уже с новыми фичами. Снова собираем сверхценные замечания, меняем оранжевый обратно на красный, кнопочку пхаем посередине, и выясняем а что должно происходить когда пользователь нажмёт на эту кнопочку. Причес через пару спринтов клиент может и передумать что же будет происходить при нажатии, потому что увидит что он по-другому себе всё представлял.

По умному "fast feedback loops". Мы получаем новую информацию от клиента как реакцию на нашу проделанную работу намного раньше (в каждом спринте).

В водопаде у такого клиента, после того как он напишет даже самой подробное ТЗ, остаётся слишком много времени чтобы у него в голове всё переделалось на новый лад. А ТЗ он сам читать никогда не будет, не барское это дело. Чукча писатель а не читатель. В результате, через год разработки ему показывают что-то, пусть даже на 100% соответствующее ТЗ, а клиент жутко обижен и недоволен - это совсем не то что он имел в виду (потому что то, что он имел в виду за этот год в его голове поменялось раза 3). Всё, проект прошел плохо, клиент недоволен, деньги платить не хочет, потому как уверен что его непрвильно поняли ("что вы мне тычете этим ТЗ, всем понятно что под `удаление аккаунта` я имел в виду что он пропадает из таблички с результатом поиска") и те де и те пе.

2. Модность помогает продать скрам. Убедить клиента что ему НАДО найти время на то, чтобы участвовать в ревью после каждого спринта и на то что ему НАДО обсуждать истории с ПО. "Вы же знаете насколько лучше становится результат разработки, если применяется скрам, а в нём предписано что вы обязательно должны участвовать, чтобы контролировать соответствие разработки вашим представлениям и пожеланиям".

ради чего? Не думаю, что есть много фирм, согласных на какие то крупные изменения ради "призрачной мечты"

Вы не поняли. Изменение организационной структуры это не требование. Это "маркер эффективности". Можно и без него. Но в большинстве случаев это повысит эффективность скрама. Если разработчики из разных отделов, и у руководителей отделов есть другие проекты - у скрам мастера прибавляется седых волос. Он каждый день будет отбиваться от "но Вася нам срочно нужен в другом проекте, у нас критическая ошибка. Да, мы помним что мы обещали что следующие 2 недели он работает в скрам-команде, но это форс-мажор, мы не могли его предвидеть!". И такое будет каждый день. Без преувеличений (почти :)) А выдергивание разработчика рушит план на спринт. Что не добавляет радости ни ПО ни клиенту ни команде. Потому что прибежит ПО или ещё какой проект-менеджер и будет полчаса есть мозг на тему "ну вы же понимаете, мы же взяв истории в спринт пообещали клиенту что мы их реализуем, и ему они все очень важны, ну поднапрягитесь, мы понимаем что то что Васю выдернули из проекта это очень плохо, и то что вы недовольны этим, но вы же отличная команда, вы справитесь!". И это бесит. А когда такое происходит постоянно, настроение в команде падает ниже плинтуса. Качество, скорость - всё падает в разы.

Относительно обсуждений, тоже как когда. ПМ был в большом удивлении когда в первый раз услышал наше обсуждение - мол руготня одна.

А на самом деле было полезно и нам нравилось, потому как потом обдумываешь и приходит более лучшее решение.

Скрам говорит что команда должна самоорганизовываться. В какой-то книжке был пример что в одной команде, если они не могли придти к общему решению, то делились на 2 команды "за" и "против" и играли в пейнтбол. Не важно как вы будете проводить обсуждения. Главное чтобы для команды это было удобно и принятые решения никто не оспаривал (ну и законы не нарушать :))

Вот это скорее отрицательно чем положительно, достаточно непросто найти адекватного человека.

Если бы всё было так просто, и вокруг были только адекватные люди, мы бы при коммунизме жили. Чудесного решения "как из кучи моральных уродов сделать команду разработчиков" скрам не предлагает.

А при чём здесь скрам? Задать и так всё можно. Только сроки всегда были важнее всего остального

Вооот! Вот именно этому скрам и противодействует. 1. Какие фичи в каком релизе выйдут не прописваетя. 2. Тикеты с невыполненым DoD нельзя включать в релиз. И команда может послать ПО, когда он начнёт что-то требовать, вроде "не пишите тесты, и так всё понятно". И нормальный мастер их поддержит.

Но это работает только если, как я раньше писал, менеджеры и руководство понимает что скрам даёт, и от чего при сраме надо отказаться. Иначе ПО идёт жаловаться к руководству и руководство "разрешает" команде "не выполнять DoD для истории X". Но потом то же руководство не хочет понимать - а чо это у нас ошибки попёрли. А потому что ПО понравилось такое классное решение. И теперь в каждой задерживающейся задаче "разрешает" не выполнять DoD. И команда уже не спорит, потому что знает что спор ничего не даст. Простейшее противодействие со стороны команды - тупо начать оценивать "стоимость" историй выше. Чтобы в спринт вошло меньше историй и реже "разрешали" не выполнять DoD.

Как то очень сомневаюсь.

Дело ваше. Есть люди, которые в том что земля круглая сомневаются. Бывает. Конечно, кто-то больше любит в графике ковыряться, кто-то БД. Но внедрённые ими в проекте решения будет понимать вся команда.

Пока так и не увидел ни единого преимущества Скрама для себя

Ну так он вам,может, и не нужен. Это нормально.