Прежде всего спасибо за поддержку и за ответы.

К сожалению, ситуация не такая простая как может показаться.

Для текущей работы работы Скрам никаким местом не пойдет, может быть только что полезное выдрать.

А вот что будет когда то, еще неизвестно. Да и интересен анализ прошлых проектов. Но в целом, хотелось бы иметь набор неких правил, когда использование скрама эффективно, а также его достоинства/недостатки с точки зрения убеждения руководства.

Сложено объяснить зачем он остальным нужен.

именно в этом и проблема

А откуда вы взяли про каждый день?

не имею понятия, откуда то пришло, что именно "большая скорость показа" дает преимущество.

перевод его требований к качеству кода/документации

Это тоже никак не доходит - как методика может изменить качество кода или добавить документации.

Если разработчик "мыслит" плохим кодом, то изменить это непросто.

Я не знаю что вы имеете в виду под "голым теоретическим скрамом"

Это то о чём можно прочитать, типа этого

https://habr.com/post/247319/

https://4brain.ru/blog/scrum/

https://te-st.ru/2017/07/04/12-terms-of-scrum/

Расскажите, как выглядит ваш типичный проект?

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

В одной группе проекты от 1 чел./мес. до 4..6

В другой группе "постоянные" проекты, которые только могут дорабатываться под конкретные требования, до 1 ч/м иногда там что то и меняется.

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

А как может быть по другому? Ресурсы всегда в недостатке.

За пределы команды ругань не выходит

Это мое замечание было вообще не в контексте скрама. просто случай который запомнился.

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

вот именно правила, "когда не нужен/нужен" и хочется как то формализовать.