>Но эта же неконтролируемость в равной степени возможна и там,

и там.
Нет не в равной. В случае продуктовых метрик - 100%. В случае разработческих - it depends.

>Сворачиваем Скрам потому что он не эффективен?
Сворачиваем (при условии того, что мы убедились в валидности lead time)

От чего prostite it depends? То есть, вы не допускаете, что в течение года работы по Скраму команда разработки сформирует сильные DoR и DoD, которые увеличат лидтаймы? Что возможно до Скрама поставляли часто, но иногда без ценности пользователю, а теперь стали реже, но всегда ценное? Денис, у вас есть реальный опыт запуска Скрама? Пусть в одной команде, но на уровне компании? Потому что вкупе с замерами Team Happiness меня ваша логика очень смущает. Я не могу представить как можно придти к топам и сказать: Мы запустили Скрам и это круто потому что мы теперь очень быстро поставляем и команда счастлива! А метрики продукта (и деньги от него) не растут потому что мы на них не влияем же, это все там - на внешке.

Имею, конечно. Теперь по пунктам. Более “сильный” DoR и так далее скорее всего приведут к большему количеству hand-offs, менее «интегральному» дизайну решения, медленной обратной связи и как результат меньшей полезности для пользователя в долгой переспективе (хотя опять же это нельзя использовать как метрику). Если вам кажется, что это не так, то советую почёркать свои баесы к скраму. Вы видимо любитель Ватерфола и пытаетесь метрики подобрать так, что бы оказаться правым. Насчёт того, как идти к топам и что говорить у меня как раз есть отличное представление. За эффективность разработки отвечает как правило VP of Engineering. Его задача - улучшить свои метрики. Если так вышло, что разработка работает как часы, а вот продуктовые метрики не растут, то тут вопрос к продуктовой организации. Это скорее всего косяк CPO, что при отлаженных процессах поставки поставляется мусор. Скорее всего есть проблемы с позиционированием продукта, стратегией или работы команды аналитики. Может компания просто не имеет нужных инсайтов? Тут никакой Скрам или другой процесс не поможет. У Алексея Пименова есть любимая история про то, как Nokia в своё время лидировали в гибкости и организованности своих процессов, явно были лидерами индустрии в этом аспекте. Что не помешало допустить стратегической ошибки с Стмбианом и потопить весь свой бизнес. Были ли он хреновыми инженерами? Нет. Были ли у них плохие процессы? Тоже нет. Но это не спасло их.

Начну с того, что я вас услышал, продолжать холивар не хочу, поэтому напишу свое финальное слово, вы, возможно, потом напишите свое и сойдёмся на том, что не приведи нас с вами судьба работать одновременно в одной компании. Итак, что я от вас услышал из того, с чем в корне не согласен и почему я этим не согласен. 1. ДоД не может увеличить лидтайм. На горизонте первого года - легко. Куча примеров инженерных практик, которые могут его растягивать. Команда может решить покрывать функционал автотестами, применять ТДД, использовать парное программирование и много чего ещё. Все эти практики у вас за день не вредятся. Все они, как минимум, на этапе запуска, а некоторые и почти навсегда увеличат ваш ЛТ. 2. Скрам не может влиять на успешность продукта, влияют только "внешние" факторы. Нет, потому что в Скраме придуманы и описаны, как минимум роль РО (СРО - это тоже РО, кстати) и Обзор Спринта. Они будут влиять на продукт, а значит, и Скрам на продукт влияет. "Поставка мусора", проблемы позиционирования, косяки в стратегии продукта и тп - ответсвенность РО/СРО, а эти роли принадлежат Скраму и LeSS'у (который, кстати, тоже Скрам). 3. Пример с Нокией вообще не понимаю, при чем тут. Сами говорите там не было Скрама, "но вот если бы даже был - все равно не помог бы!". Не знаю, где вы взяли магический шар, который вам это сказал, но я предпочитаю таких сослагательных предположений не делать и не считать это свершившимся фактом. 4. А, ну и фраза о том, что я придумываю метрики о вас звучит очень странно. Это ведь не я говорю, что "я не умею измерять влияние Скрама на Продукт, поэтому буду измерять только разработку" 🤷🏻‍♂

1. Любое повышения требований к качеству растягивает время выполнения процессов