Scrum of Scrums — техника масштабирования Scrum на несколько взаимозависимых команд, работающих над общим продуктом: представители каждой отдельной Scrum-команды регулярно встречаются на общей координационной встрече для синхронизации прогресса, выявления межкомандных зависимостей и совместного устранения препятствий, которые невозможно решить внутри одной отдельной команды (см. отдельную статью про базовый фреймворк Agile/Scrum).
Происхождение и исследовательская база
Scrum of Scrums впервые применён в 1996 году Джеффом Сазерлендом и Кеном Швабером — авторами Scrum-фреймворка — в контексте координации восьми бизнес-подразделений с несколькими продуктовыми линейками в каждом, в компании, впоследствии ставшей частью GE Healthcare (Сазерленд занимал позицию старшего вице-президента по инженерии в IDX Systems, Швабер консультировал тот же проект). Публично техника впервые описана Сазерлендом в статье 2001 года «Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies».
Формат координационной встречи Scrum of Scrums: представители (обычно Scrum-мастера или технические представители) от каждой команды регулярно встречаются — как правило, несколько раз в неделю или ежедневно при высокой степени зависимости команд — и обсуждают три ключевых вопроса, аналогичных структуре ежедневного Scrum-митинга отдельной команды, но на межкомандном уровне: что сделала моя команда со времени последней встречи, что планирует сделать до следующей встречи, и какие препятствия или зависимости от других команд мешают прогрессу.
Ключевое отличие от простого масштабирования числа команд: Scrum of Scrums не заменяет координацию внутри каждой отдельной команды, а добавляет отдельный, минимально необходимый слой межкомандной синхронизации — техника явно сфокусирована на устранении именно межкомандных препятствий и зависимостей, а не на дублировании внутрикомандных процессов на более высоком уровне.
Ключевые идеи и принципы
Принцип: встреча фокусируется на межкомандных зависимостях, а не на статусе внутри каждой отдельной команды.
Представители команд на Scrum of Scrums не пересказывают полный статус своей команды — это уже обсуждено на внутрикомандном ежедневном Scrum-митинге — а фокусируются именно на том, что затрагивает другие команды: общие компоненты, интеграционные точки, блокирующие зависимости.
Принцип: частота встреч должна соответствовать реальной степени взаимозависимости команд.
Команды с высокой степенью технической взаимозависимости (общий код, общая инфраструктура) требуют более частых встреч Scrum of Scrums, тогда как относительно независимые команды могут координироваться реже — частота не должна быть фиксированной догмой, а определяется реальной потребностью в синхронизации.
Принцип: препятствия, выявленные на встрече, требуют явных владельцев и сроков решения.
Простое озвучивание межкомандного препятствия без назначения ответственного за его устранение снижает ценность встречи до формального ритуала — эффективная практика Scrum of Scrums фиксирует конкретные действия и владельцев по каждому выявленному блокеру.
Ограничения, слепые зоны и критика
Простое масштабирование числа участников встречи Scrum of Scrums при росте количества команд быстро делает встречу неуправляемой — при большом числе взаимозависимых команд может потребоваться иерархическая структура из нескольких уровней координационных встреч (Scrum of Scrums of Scrums), что усложняет процесс и требует дополнительной управленческой дисциплины.
Техника решает проблему координации между уже сформированными Scrum-командами, но не устраняет более фундаментальные проблемы масштабирования — организационную архитектуру продукта, распределение владения компонентами между командами, конфликты приоритетов бэклога — для этого существуют более комплексные фреймворки масштабирования (SAFe, LeSS, Nexus, см. отдельную статью).
Без явной культуры открытого обсуждения проблем встреча Scrum of Scrums рискует превратиться в формальный статус-репорт без реального выявления и решения межкомандных препятствий — эффективность техники сильно зависит от общей культуры прозрачности в организации.
Типовые ошибки
Ошибка 1: превращают встречу в пересказ полного статуса каждой команды вместо фокуса на межкомандных зависимостях.
Представители команд дублируют содержание внутрикомандного ежедневного Scrum-митинга, тратя время встречи на детали, не затрагивающие другие команды, вместо фокуса на реальных межкомандных препятствиях.
Как избежать: явно ограничивать обсуждение на встрече темами, затрагивающими несколько команд, оставляя внутрикомандный статус для отдельного ежедневного Scrum-митинга каждой команды.
Ошибка 2: фиксируют частоту встреч без учёта реальной степени взаимозависимости команд.
Команды с низкой взаимозависимостью встречаются так же часто, как сильно связанные команды, тратя время впустую, либо наоборот — сильно зависимые команды координируются слишком редко, что приводит к позднему обнаружению интеграционных конфликтов.
Как избежать: подбирать частоту встреч Scrum of Scrums под реальную степень технической и продуктовой взаимозависимости конкретных команд.
Ошибка 3: не назначают владельцев и сроки для выявленных на встрече межкомандных препятствий.
Проблема озвучивается на встрече, но никто не берёт на себя явную ответственность за её решение, и она повторно всплывает на следующих встречах без прогресса.
Как избежать: явно фиксировать владельца и срок решения для каждого выявленного межкомандного препятствия, отслеживая прогресс на последующих встречах.
Главное, что нужно знать
Scrum of Scrums (Сазерленд/Швабер, 1996) — техника масштабирования Scrum на несколько взаимозависимых команд через регулярную координационную встречу представителей.
Фокус встречи — межкомандные зависимости и препятствия, а не пересказ статуса каждой команды.
Частота встреч должна соответствовать реальной степени взаимозависимости команд, а не быть фиксированной.
Выявленные препятствия требуют явных владельцев и сроков решения, иначе встреча превращается в формальный ритуал.
При большом числе команд может потребоваться иерархия из нескольких уровней (Scrum of Scrums of Scrums) или переход к более комплексным фреймворкам масштабирования.
План внедрения
Неделя 1: определить состав команд и их реальные взаимозависимости
Составить карту технических и продуктовых зависимостей между командами, работающими над общим продуктом.
Неделя 2: назначить представителей команд для координационной встречи
Определить, кто от каждой команды будет участвовать в Scrum of Scrums — обычно Scrum-мастер или технический представитель.
Неделя 3: установить частоту встреч под реальную степень взаимозависимости
Настроить регулярный ритм встреч, соответствующий фактической потребности команд в синхронизации.
Неделя 4: внедрить механизм фиксации владельцев и сроков для выявленных препятствий
Обеспечить, чтобы каждое озвученное на встрече межкомандное препятствие получало ответственного и срок решения.
Далее: оценка потребности в дополнительном уровне координации — при значительном росте числа команд рассмотреть иерархическую структуру встреч или переход к более комплексным фреймворкам масштабирования Agile.
Как реализовать этот план с помощью фрейма «Scrum of Scrums» в OrgDevTools
Фрейм состоит из четырёх карточек на вкладке «Карточки», каждая соответствует одной неделе плана внедрения выше.
Неделя 1 — карточка «Карта межкомандных зависимостей». Сюда вносятся технические и продуктовые зависимости между командами, работающими над общим продуктом.
Неделя 2 — карточка «Фокус на межкомандных препятствиях, не статусе». После назначения представителей команд сюда вносится, как обсуждение ограничено тем, что затрагивает другие команды — превращение встречи в пересказ полного статуса прямо повторяет ошибку 1.
Неделя 3 — карточка «Частота встреч под реальную взаимозависимость». Сюда вносится, как сильно связанные команды встречаются чаще, а независимые реже — фиксированная частота без учёта взаимозависимости прямо повторяет ошибку 2.
Неделя 4 — карточка «Явные владельцы и сроки для препятствий». Сюда вносится назначенная ответственность за каждое выявленное препятствие — её отсутствие прямо повторяет ошибку 3.
Вкладка «Итоги» явно предупреждает, если обсуждение смещается на внутрикомандный статус или препятствия остаются без владельцев. Кнопка создания задачи формирует задачу «Настроить частоту встреч под реальную зависимость команд и назначить владельцев препятствий».