Паша в другом чате сидит все еще )

Скрам как фреймворк, как его воспринимают в большинстве мест где я работал со скрамом - это следующие шаги:
* Придумали, что хотим сделать
* Обсудили что хотим сделать
* Дождались следующего спринта (SIC!)
* Положили в бэклог спринта
* Сделали в спринте (или не сделали - тут как карта ляжет)
* Обсудили на ретро что-нибудь
* Задеплоили
* Устроили демо для клиента
* Поправили баги. Нет, не в этом спринте, в следующем, потому что этот уже распланирован.

итого 5-6 спринтов, чтобы докатить один кусок работы.

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

* Придумали что хочется сделать
* Дождались, когда в очереди входящих запросов попустело
* Обсудили, что хочется сделать
* Сделали
* Задеплоили
* Устроили демо для клиента
* Поправили баги.
Все каденции по планированию на основе заполненности горячей очереди задач, деплой по готовности.
В итоге с 1-2 "спринтами" на задачу одновременно приходилось помнить только о паре текущих задач и об одной следующей.

В итоге я прихожу к тому, что чтобы скрам работал нормально, в нем надо растить канбан-систему и не завязываться на скрам.

Да, почему бы и не растить канбан-систему. В конце концов, многие инструменты можно совмещать.
И да многие компании делают демо в конце вместо ревью. Это печально.

зачем совмещать, если можно канбан-систему растить сразу на канбан-методе? :)

Сильно большой текст ты запиил )

Тот же принцип завершать вместо того чтобы начинать. В скраме этот принцип реализуется спринтами.
И тут якобы недостатки вполне проявляются и в канбан-методе:
* Дождались следующего спринта (SIC!)
* Поправили баги. Нет, не в этом спринте, в следующем, потому что этот уже распланирован.

Баги могут не пройти точку взятия обязательств из-за WIP лимита.
ЛПР может продавить новые фичи без доделки старых.

Прошу прощения за консоязычность, переписал )

Тут дело в людях, как обычно ) А не в фреймворке )

скажем так. людей сменить сложнее, чем фреймворк. Но я улавливаю взаимосвязь - "внедряем скрам - получается Х, внедряем канбан - получается У". Может дело не только в людях?

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

Мне показалось, что те проблемы, что ты описал, скорее в людях чем во фреймворке.
Но инструменты без сомнения разные и условия применения разные.
Скрам дает сконцентрироваться на ближайшей цели. Канбан-метод, на сколько я знаю, не вводит такого ограничения как цель. Плюс это или минус - хз. Но развернуться становится проще, конечно.

Скрам более интуитивный. По крайней мере планирование. Канбан-метод основан на статистике.
Скрам проще, на мой взгляд, начать нежели канбан-метод. А дальше хоть канбан-метод, хоть в космос.

скрам интуитивный? вот уж вообще нет

Вот с языка сняли )

Особенно планрование в нем

Я не писал "интуитивно понятный".

а что такое "интуитивный"?

Ну тот же покер планирования. Он не основан на данных, он основан тех не вполне осознаваемых нейронных связях, который просто выталкивают на поверхность 8sp!

Хотя в скраме ничего про покер планирования нет... хм

Ладно, считайте, что я только про покер планирование писал )

Хах, если подумать то в СГ сильно расписали несколько призывов:
1) периодически думай
2) периодически думай с дев тим
3) периодически думай с дев тим почаще
4) периодически думай всей командой
5) периодически думай вместе с клиентами/юзерами.
6) периодически думай, а то ли ты делаешь
ну и т.д. ))) А думать это да, громоздко )