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

Евгений, а вы вот пишите, но похоже что не знаете о чем пишите. А зачем?

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

Мы скорость поставки в разы повысили за последние 5 месяцев. Раньше релизилить могли неделями, теперь каждую сторю в бой в тот же день.

1 человек работает как 1, 10 — как 8, 50 — как 40..?

Автотесты, процесс выкатки, devops-ы (я манагер, ничего в этом не понимаю)

Не совсем понял, но кажется вы про производительность. После 3 человек она начинает падать. 4,5,6 и тд — уже сильно ниже производительность

В мае у нас было 2 команды гигантские, мы их порезали на мелкие (кажется 5 или 6 в итоге)

Работаем в разы эффективнее

А хотите ещё больше эффективности?

Работаем в разы эффективнее

Конечно

Мы конечно всегда думаем об ускорении и увеличении value в единицу времени

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

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

а те, кто фичи приоритезируют тоже думают? (это не троллинг, иногда это не так))

Дим, конечно. Я как product owner постоянно тестирую разные фреймворки по приоритезации; внедряю сейчас юзабилити тесты регулярные чтобы находить интерфейсные ошибки ещё до того как написали код; постоянно бьет продукты на куски и запускаем пилоты на выборку аудитории

by the way команды (вот те 5-6) над одним продуктом работают?

ммм и что болит?

1) какие решения принимаются? (и как формулируются?) 2) как валидируются результаты?

Ректроспективы для технических команд пробовали проводить по спринтам на нескольких проектах, по факту быстро сворачивали, так как было в основном два крайних варианта: либо все упорно говорили, что все хорошо/ничего не помню/ничего не знаю, либо адский неконструктивный срач. Проблемой вижу инициативу сверху (исторически сложилось или кто-то где-то вычитал обрывками), а не желание лидов команды, то есть непонимание и отторжение еще одной встречи. Все эти проекты велись маленькими командами (4-5 программиста, всего 10-15 человек в команде проекта). Первый успешный опыт получился на проекте, где команда на 80 человек, из них программистов около 20. Под успешным опытом я понимаю наличие улучшений в процессе разработки после ретроспективы. Пришло понимание, что нужно совместно обсуждать результаты и искать пути улучшения. Теперь устраиваем ретроспективы после релиза крупных фичей (не только на тех команду, на всех причастных к фиче, ведет ретроспективу ПМ) и ретроспективы спринтов (программисты онли, ретроспективу ведет тех лид). Результаты ведем в конфлюенс, по принятым решениям назначаем отвественных и сроки, как правило реализация ключевых поинтов происходит быстро и первый фидбэк по изменения получаем до следующей ретроспективы.

Никто не поделится насколько болезненным/классным для команды было внедрение ретроспектив? Насколько активная вовлечённость? Где и как храните результаты? Как ставите задачи по ним?

По-моему даже можно позвать коуча провести ретро, за $

Навязать ретроспективы и вести их сверху нельзя?

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

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