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

Потому что мы его обсуждаем. Можно взять другой метод. Можете придумать свой метод, это не сложно. Сложено объяснить зачем он остальным нужен.

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

Зря. Я пояснял в чём тут преимущество. Предупреждаю - для ультра-модных пацанов скрам уже не вариант. Agile is dead и всё такое.

ну так это и так можно сделать.

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

Каждый день по малому кусочку?

А откуда вы взяли про каждый день? Обычно после завершения спринта, на ревью (1 раз в 2-6 недель). Если у клиента подгорает что-то срочное, можно и сразу после завершения тикета показать.

которые соответствуют нашим выдуманным ДОД ему нафиг не нужны.

Это вы так думаете. DoD по-хорошему отражает требования клиента. Чем дороже ошибки и чем долгоживущее проект - тем строже DoD. Но клиента DoD не интересует. Это наш "внутренний" перевод его требований к качеству кода/документации/<подставить нужное>.

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

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

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

Вы, наверное, не поняли. Критическая ошибка в другом проекте. Человек из команды A (организационно, у него тимляйтер Херр Мюллер) откомандирован в скрам-команду проекта B. Спринт планируется исходя из 2-х недельного присутствия этого человека. В середине спринта прибегает его шеф (Мюллер) и с криками "всё пропало, все болеют, рожают и по командировкам" загружает нашего откомандированного. Итого: косяк в планировании Херра Мюллера приводит к проблемам в скрам-проекте B. А так как такое случается всегда, команду проекта B это бесит.

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

Руководство решило внедрять скрам или где? Решило - пусть сидит и не отсвечивает. Это внутреннее дело команды. Что руководство вообще делает на обсуждении? Скрам предписывает что на рефайнменте присутствуют только ПО, члены команды и скрам мастер. Можно (но не обязательно) приглашать технических экспертов. Лучше без них. И обсуждение лучше уже без эксперта (его время дорого да и не надо уме наши внутренние споры слушать). Претензии предъявлять имеет право только команда и скрам-мастер. За пределы команды ругань не выходит - у нас фильтр в виде ПО. А на ревью мастер любую ругань прервёт, потому как обсуждение проблем не формат этого митинга. О как.

Ну так тогда он будет на фирме просто запрещен.

Так и не внедряйте. Кто же вас заставляет? Если у вас и так проблем нет и все проекты выполняются в полном объёме и в срок, то зачем что-то менять? У нас в одном проекте руководство признало, что если бы мы его делали как раньше, по нашему водоподо-подобному процессу, он бы до завершения не дожил бы. Потому как за 2 года 4 раза поменялись приоритеты. И то то в 2016 считалось самым важным, в 2017 оказалось вообще не нужным.

Может, проще описать какие у вас проблемы в проектах? А мы (кто скрамом пользовался) прикинем поможет ли он тут.

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

И из-за них тоже. Но в основном из-за принципа разработки. Истории разбиваются на задачи (стараемся чтобы длина не превышала один день) и если так получилось, что в истории три задачи, связанные с БД, никто не будет ждать 3 дня, пока гуру БД их выполнит. Их будут делать параллельно, долбая его вопросами. В результате когда такое случится в первый раз все 3 задачи займут больше времени, на 3-4-5 раз, все будут сделаны за 1 день. Задача скрам-мастера донести до команды понимание того, что нельзя специализироваться только на своём и игнорировать всё другое. Иначе будут пробки. А если наш гуру БД заболеет на две недели? Что, вообще ни одной истории не сделаем? Почти все вводят или pair programming или code review. Тоже способствует распространению знаний (и заставляет скрежетать зубами недалёких ПО :)). У нас было выбито 1 час в спринте на "обмен знаниями". Если кто-то в процессе разработки своей задачи начинал делать что-то новое (новый фреймворк, ранее неиспользуемый дизайн пэттерн, еще что) то на дэйли он об этом говорил, и до конца спринта проводили короткий ликбез.

Или просто проекты были какие то особенные?

Как уже говоил выше - расскажите про ваш типичный проект. Может и особенные.

На моей предыдущей работе скрам был ну... в 80% проектах не нужен.