Вот я может токсичный и может меня кикнут за мои

слова, но тут в обуждении почти у каждого второго написано или СМ или аж целый Аджайл-коуч. У всех за плечами не один год реальной практики.

Но то ли я неправильно как-то читаю, то ли реально именно эти люди почему-то пытаются подменять мягкое тёплым.

И нет ответа на вопрос "чтобы что?"

Открываем Скрам-гайд - с первых листов там написано "фреймворк для разработки в условиях НЕОПРЕДЕЛЁННОСТИ"
Потому что после каждого Спринта у вас возможны изменения аж на уровне в стратегии. Вы можете зарелизить фичу, получить новый фидбэк и вообще пивотнуться.

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

Но тем не менее, есть те, кто упорно по заветам Красной книги Сазерленда пытается доказать, что "Скрам везде отлично подходит".

Сожалею, если разрушу ваш мир, господа, но границы эффективной применимости Скрама все же есть.
Он полезен далеко не везде

А если серьёзно - все-таки не готов согласиться. Серебряной пули нет. И Скрам - тоже не она. Сначала надо понять ситуацию. Может реально так быть, что никакое управление кроме проектного в каком-то случае не сможет подойти лучше. Это нормально

Проверяю на практике, пока вывод такой: да, скрам создает избыточные затраты порой, можно было бы обойтись более простыми вещами, но зато в случае скрама эта избыточность обеспечивает запас прочности, большую живучесть Поэтому ищу альтернативы лишь в более сложных подходах, а не в более простых

А что значит неработающий?

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

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

Кстати, о птичках. А как сравнивать поставку до внедрения Скрама и после? Ведь требования, продукты, инкременты были разные.

Минутка рекламы

Нет, просто маркирую свои сообщения чтобы потом найти, где я говорил про Метод. Если Вас не многопроектная среда, не нужно выполнять все обязательства компании вовремя и в полном объеме и нет ограничений по ресурсам (можно нанять кого надо с рынка за 2 недели) - то Вам он не нужен.

Я не задавал вопрос, если что

Так я с этим не спорю. Но у вас и лидтаймы могут расти и сокращаться вне зависимости от наличия Скрама🤷🏻‍♂ О чем мне тогда должны сказать ваши примеры?

Для лидтаймов можно зафиксировать другие переменные - не менять стек, не менят команду и тп. Продукт штука живая, с кучей seasonal effects

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

Нельзя, да. Но лишь говорит о том, что мы поменяли несколько вещей отдновременно и cause-effect связь установить нельзя. Хотя тут конечно depends. Может ли скрам-комманда сама меня своих членов? Типа уволить негодяя. Тогда это переменная становится управляемая скрамом и справедливо было бы сказать - вот смотрите, скрам команда сама нашла проблему, сама устранила. Тоже самое и со стеком. Если комманда достаточно автономна его выбирать - никаких поправок делать на надо. То есть я бы фиксировал только внешние относительно комманды переменные. Ну или бы не использовал данную метрику, если такое невозможно.

А роль Продакта не Скрамом управляется?

В скраме не написано может ли комманда уволить и нанять нового PO. В теории может. Но это нас не спасет от внеших изменений на рынке.