Ну, из того, что написано:
1) Сутки на планирование работ на неделю (даже на две) на команду из 5-10 человек - это очень много. Скорее всего при этом не было ни нормальной проработки входящих задач до планирования, ни подготовки участников, ни всего прочего. Есть несколько разных подходов к созданию плана на команду на короткую итерацию, в среднем это должно занимать от 2х до 10 человекочасов. Если больше - то нужно подбирать другой подход.
2) Ретро и демо на целый день  - это тоже явно кошмар.
Демо по результатам работы спринта вообще сомнительная практика, зачем ждать столько времени если что-то готово? Показ даже сложной фичи обычно - минут 20 и на нем не нужна вся команда.
Ретро проводить каждый спринт обычно нет смысла, скорее по согласованию. В любом случае эффективного ретро дольше полутора часов не бывает (и даже в этом варианте ретро превращается в плохо организованную групповую терапию).
3) code review почти всех плохая практика, лучше использовать более общие подходы к обеспечению качества продукта.
4) если в пятницу нельзя деплоить - значит тестирование и процесс выкладки никуда не годятся и нужно ими заниматься (как раз утилизуешь время разработчиков). Фраза " QA решает хватит ли ручного" тоже говорит об очень низкой культуре обеспечения качества.

Итого - плохие практики, низкая культура разработки, низкий кругозор, загнившая команда.

Такого не наблюдал

++++ (плюс по кажному пункту)

ну и в очередной раз “внедрили скрам, кажется, что норм"

вот бы в других сферах так работать можно было

приходишь к терапевту с головной болью от фейспалмов, он тебя ну просто так на ампутацию и протезирование руки отправил

"кажется, так лучше”

Встречал подход, когда пробуют скрам, что бы проверить подходит ли команде) Попробуйте наоборот... Ну не все процессы менять - но выкинуть какую-то рутину и поработать пару спринтов. Это нормально.

Скрам - хороший подход для
1. Проблем в коммуникациях между бизнесом и разработкой и невозможностью/нежеланием их решить
2. Потока простых и более-менее одинаковых задач
3. Разработчиков низкого качества

Т.е. скрам - это для поддержки умирающих продуктов на аутсорсе.

зачем там фаза анализа и адаптации, в таких проектах?

один черт они ничего там менять не будут же

чтобы просто посидели поныли на ретре и разошлись дальше кодить?

хотя, кажется, и правда хорошо

иллюзия сформируется, что че-то можно поменять

кровати попередвигать

Ну да. Если задачи простые, то planning poker проходит за пару часов.
А ретро - это групповая терапия в худшем виде

ага, понял, логично очень

Не согласен, PDCA и процесс непрерывного улучшения никто не отменял. Поэтому как минимум ретро - точно нужно. Но да, нужно что бы оно было не рутиной, а прям
1. Что было хорошо на прошлом спринте
2. Что не понравилось на прошлом спринте
3. То что пробовали улучшить на прошлом спринте - помогло ли нам? Нужно ли нам? Отказываемся, пробуем изменить или принимаем как есть?
4. Что хотели бы попробовать улучшить на следующем спринте?

спланировали то что планирования почти не требует
а потом поныли друг другу что опять как всегда все просрали

не нужно PDCA приравнивать к ретро

циклы обратной связи можно делать безо всяких ретро

Вот по такому сценарию когда проводилось ретро. без лишней болтовни и ухода в технические реализации задач - я прям видел пользу.

и горизонт “спринт” просто избыточен как сущность

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