Только причем тут скрам? Это просто вертикальная организация команд.
Команды, кстати, начинают если что горизонтально меняться задачами

Бывает даже что одна команда итерационого водопада как раз и утилизируется как автор описывал про аджайл, а вторая как в класическом итерационном водопаде.

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

Да фиг с ними с менеджерами. Я хочу цепочку понять. Скрам вынуждает к вертикальной организации? Или вертикальная организация порождает скрамоподобнуб схему разработки

Ни то ни другое. У кого то так  у диугих по другому. Мое видение такое.

У меня по жизни сложилось наблюдение что паттерны могут срабатывать или не срабатывать, это зависит от окружения (условий) проекта. А вот антипаттерны срабатывают всегда.

Мы примерно в эту тему вчера с @WatchTh15 после митапа ушли. Очень похоже что наравне с техническим/архитектурным долгом может копиться и организационный долг.
Грубо говоря: я знаю что надо уделить время архитектуре или документированию решений, но "доброе" руководство не выделит требуемый ресурс. А дальше все те же проблемы с поддержкой, сопровождением решения.
Судя по всему еще одна тема для обсуждения лицом к лицу. Попробую завтра сформулировать.

Да, точно

У меня крутятся в голове ассоциации с Голдратом, но не могу пока придать фактуру

Если про прозрачность, то вполне уже ощутимое настоящее. Причём не в "бирюзе", а в полне себе "кровавом энтерпрайзе"

Даже "очень злое" руководство прекрасно оперирует в терминах денег (TCO, value/cost,...), а вот технический долг, архитектура и прочие "стеки" - для него "белый шум".

Мощно плюсую этому наблюдению.

а что у дедушки Элияху было близкое по теме? пытаюсь провести аналогию, но как-то ничего не приходит на ум

Мы на самом деле говорим о TTM (проход) и TCO. Вместо затрат приходит на ум утилизация.

Отсутствие дизайна, документирования, наличие тех. долга и пр., приводит в конечном итоге к снижению TTM и росту TCO.

Фокусируясь на утилизации упускается из виду TTM и TCO. То есть вроде бы все заняты (затраханы до предела), а фичи выводятся всё медленнее и стоят всё дороже.

А самое главное - менеджеры этого не видят и сами не понимают, что делать. Отчасти потому что многие из них "эффективные менеджеры общего назначения" и не понимают в производстве ПО.

интересная мысль. но тогда возникает вопрос, может ли снижать проход разбор тех долга (рефакторинг) и пр. такие вещи? ведь пока чиним старые болячки, фичи не делаются, денюшка не капает, проход падает

А вот тут как раз и нужен баланс. Нужно встраивать дизайн и устранение тех долга в производство фичей.

Да, на начальном этапе фичи могут выводиться медленнее, но в среднесрочной и тем более долгосрочной перспективе, быстрее.

Тактика против стратегии.

Пока сумма возможных доходов больше суммы вероятных потерь - пилим новое. Но это, конечно, очень упрощенно :) Баланс и прогноз нужен

согласен. то есть придерживаемся стратегии, что, например, рефакторим не абы когда, а только для новых фичей или исправления багов, я правильно понимаю?

ох, уметь бы еще всегда находить этот баланс)

На самом деле, пока конвейер не заработал на полную мощность, проблем с проходом нет. Всё быстро.

Нет, на системной основе с самого начала планируем в спринтах задачи по дизайну, рефакторингу и документированию.