Scrum в духе Toyota

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

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

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

Содержание:

1. Чем Scrum в духе Toyota отличается от «обычного»?
2. Роли в Scrum в духе Toyota
3. Новые события в Scrum в духе Toyota
4. Какие документы использует команда в Scrum в духе Toyota
5. Какие результаты уже дал Scrum в духе Toyota
6. Когда командам имеет смысл изучать и пробовать Scrum в духе Toyota

Agile-трансформация — это внедрение гибкой методологии управления не только в работу команды, но и на все уровни компании. Agile-трансформация целых компаний стала логичным продолжением опыта внедрения Agile в отдельных командах. И сегодня, по оценкам многих экспертов, именно она является одной из мейнстримовых тем в блоке управления изменениями компаний.

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

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

В этом подходе нет новых формальных ролей, остаются роли Product Owner, Scrum Master и Developers.

Но фактически появляются усиленные акценты ролей в логике TPS:

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

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

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

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

Это превращает Daily в план‑факт по потоку и качеству, а не только вместо обсуждения «что делаем сегодня».

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

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

К стандартным артефактам Scrum добавляется «набор TPS‑документов»: 

Формализованные карточки проблем: проблема → текущая ситуация → корневая причина → контрмеры → проверка → стандартизация.

Все это — не замена Scrum‑артефактов, а «вложенный TPS‑слой», который делает проблемы видимыми, а обучение - осознанным. 

Автор приводит цифры по 20 командам, внедрившим связку Scrum + TPS:

• Среднее снижение запаса необработанных инцидентов на 59%.
• Снижение потока новых инцидентов на 37%.
• Рост удовлетворенности клиентов примерно на 25%.
• Среднее сокращение lead time в 6,5 раз.
• Рост объема произведенной ценности (инциденты, изменения, новые stories) примерно в 3 раза.
• В юните 40 человек 5 сотрудников занимались инцидентами; после применения TPS за 6 месяцев инциденты сведены с 80 «висящих» и 3 в день до нуля в стоке и 2 в месяц.
• Годовая стоимость обработки инцидентов упала с 720 000 € до фактически 0, освобожденный бюджет и ресурсы пошли в развитие продукта.

По сути, это ответ на вопрос: «Когда одного Scrum уже недостаточно?».

STW особенно уместен, если:

• Команда уперлась в потолок производительности: «делаем Scrum, но быстрее уже не получается».
• Постоянно тонете в инцидентах и переделках, качество «проседает», а проблемы тянутся из спринта в спринт.
• Есть ощущение, что Scrum‑церемонии проходят, но системного обучения нет. 
• Нужно улучшать поток end‑to‑end, а не только работу внутри одной команды (много зависимостей, внешних очередей, задержек). 

В таких контекстах стоит:

• Начать с честного визуального управления (4 стены) и расчета Takt внутри спринта.
• Ввести red bins и регулярный PDCA по качеству и потоку.
• Перепозиционировать Scrum Master как лидера TPS‑системы, а не модератора митингов. 

Тогда Scrum в духе Toyota становится не модным словом, а способом превратить вашу команду в «обучающуюся производственную систему», которая сама видит проблемы, решает их и растет в мощности от спринта к спринту.