На тренингах по Agile и Scrum у меня иногда спрашивают: так какой подход придет на смену Scrum?

Отвечаю на этот вопрос - один из возможных подходов, который придет на смену традиционному Scrum - Scrum в духе Toyota

Это не новый фреймворк, а способ «прошить» Scrum инструментами TPS так, чтобы команда реально стала машиной непрерывного обучения и улучшения.

1. Чем Scrum в духе Toyota отличается от «обычного» Scrum? Классический Scrum дает ритм и PDCA‑цикл на уровне спринта, но почти не регламентирует, как именно команда строит поток работы и решает проблемы внутри этого цикла. Scrum в духе Toyota (Scrum + TPS) добавляет поверх Scrum полноценную «лесенку» TPS: визуальное управление, вытягивающий поток (Just‑in‑Time, Takt), Jidoka и строгий PDCA как систему развития людей, а не только поставки фич.

Ключевые отличия STW от «ванильного» Scrum:

• Фокус не только на инкременте, но и на "выращивании людей" и навыков как основной цели системы.
• Жесткая визуализация всего процесса (4 стены: клиент, производительность, производство, проблем‑солвинг), а не только доска «To Do / In Progress / Done».
• Встроенный вытягивающий поток с расчетом Takt и ежедневными количественными целями по user stories.
• Системное выявление и обработка проблем качества и потока (red bins, Jidoka, научный PDCA).

2. Роли в Scrum в духе Toyota В подходе нет новых формальных ролей, остаются роли Product Owner, Scrum Master и Developers. Но фактически появляются усиленные акценты ролей в логике TPS:

• Scrum Master (часто в роли Team Leader) становится «sensei по потоку»: строит визуальное управление, организует pull‑flow, внедряет red bins, ведет PDCA и коучит команду в проблем‑солвинге. -Команда разработчиков отвечает не только за фичи, но и за улучшение самого процесса: ведет доски, анализирует красные корзины, участвует в A3/PDCA, выстраивает кросс‑функциональное взаимодействие.
• Product Owner сильнее вовлекается в анализ «стены клиента»: инциденты, удовлетворенность, скорость ценности, а не только backlog.

То есть роли остаются Scrum‑овскими, но поведение — «тойотовское»: каждый участник участвует в системе постоянного улучшения, а не только «исполнитель задач».

3. Новые события в Scrum в духе Toyota Формально Scrum‑ивенты (Sprint, Planning, Daily, Review, Retrospective) сохраняются. Но поверх них появляются регулярные TPS‑ритуалы, фактически новые события внутри спринта:

1. Ежедневное планирование по Takt

• В начале дня команда «вытягивает» stories с конца потока, выбирая столько, сколько соответствует рассчитанному Takt (например, 2 истории в день при 20 stories на 10‑дневный спринт).
• Это превращает Daily в план‑факт по потоку и качеству, а не только в «что делаем сегодня».

2. Регулярные сессии разбора red bins (проблем качества).

• Отдельные короткие встречи, где команда разбирает накопленные дефекты / сбои, ищет корневые причины, запускает PDCA‑эксперименты.

3. Системный PDCA / проблем‑солвинг‑сессии Отдельные циклы «план — эксперимент — проверка — стандартизация» по улучшению конкретных узких мест потока. Фактически внутри спринта возникает дополнительные микроритмы: ежедневный тактовый цикл, разбор проблем с качеством и регулярный научный PDCA.