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

А почему это должен быть именно скрам?

На модность абсолютно плевать.

А потом ему демонстрируется результат разработки

ну так это и так можно сделать. Это был вроде главный аргумент у Ralf Westphal-а, когда он пытался мне доказать необходимость Скрама.

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

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

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

В водопаде у такого клиента, после того как он напишет даже самой подробное ТЗ

В принципе мне по барабану водопад, скрам или еще что.

Главная цель - как сделать процесс разработки более эффективным в каком-то конкретном случае.

Пока что приходится для каждого конкретного случая использовать что "то специализированное".

И "голый теоретический Скрам" еще никогда не понадобился, поэтому и непонятки - неужто у всех остальных такие отличия в проектах, что все в восторге.

у скрам мастера прибавляется седых волос. Он каждый день будет отбиваться

так это вообще бессмысленно. Если есть критическая ошибка ее нужно исправить как можно быстрее. Значит клиент не может работать дальше с нашим продуктом. А это гораздо хуже чем если не будет выполнен какой то спринт.

И это бесит. А когда такое происходит постоянно, настроение в команде падает ниже плинтуса

безусловно - это реалии. Только как Скрам в этом помогает так и не доходит.

Не важно как вы будете проводить обсуждения

Тут проблема в том с какой стороны посмотреть - со стороны разработчиков да, а вот со стороны руководства нет. Они то не понимают технические детали, а видят лишь накал страстей.

Вооот! Вот именно этому скрам и противодействует

Ну так тогда он будет на фирме просто запрещен. Ведь главная задача сдать продукт в срок. (Возникающие при этом проблемы пока касаться не будем.)

понимает что скрам даёт, и от чего при сраме надо отказаться

Вот как раз именно с этим я и пытаюсь разобраться. Что с какой стороны ложить на чашу весов

Но внедрённые ими в проекте решения будет понимать вся команда.

отчего - из-за постоянных обсуждений?

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

Вот именно это и непонятно, отчего он мне ни разу не понадобился. Что именно я не понимаю? Или просто проекты были какие то особенные?