Scrum of Scrums

Scrum of Scrums понадобится, как только над одним продуктом работает больше одной Scrum-команды и между ними есть зависимости. Пока команд две-три, координация часто держится на личных договорённостях и общем чате. Когда их два десятка, этого уже не хватает. В 2012 году Мария Паасиваара, Каспер Лассениус и Вилле Хейккиля изучили два крупных географически распределённых проекта. В каждом работало не меньше двадцати Scrum-команд. Исследователи провели 58 полуструктурированных интервью с менеджерами, архитекторами, владельцами продукта, разработчиками и тестировщиками. Вывод неудобен для популярных руководств: общая встреча Scrum of Scrums с представителями всех команд работала с большим трудом. Аудитория оказалась слишком широкой, и удержать интерес всех участников не удавалось.

Сама идея простая. Scrum of Scrums (SoS) — это регулярная встреча представителей нескольких Scrum-команд, которые делают общий продукт. Команды синхронизируют работу, находят межкомандные зависимости и снимают препятствия, с которыми одна команда сама не справится. В литературе эта встреча фигурирует как стандартный механизм межкомандной координации в крупном Scrum. При этом, как подчёркивают те же авторы, в литературе не объясняется, как проводить её в проекте с десятками команд.

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

Происхождение и исследовательская база Scrum of Scrums

Линия 1: практика авторов Scrum (1996–2001)

Впервые технику применили в 1996 году Джефф Сазерленд (Jeff Sutherland) и Кен Швабер (Ken Schwaber), авторы фреймворка Scrum. Это подтверждают глоссарии Atlassian и Scrum Alliance. Scrum Alliance определяет метод как способ координировать несколько Scrum-команд, работающих на одни продуктовые цели. Публично Scrum of Scrums впервые описан в 2001 году в статье Сазерленда «Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies». По данным глоссария Agile Alliance, статья обобщает опыт компании IDX. Других подробностей о первом применении (число подразделений, должности авторов, дальнейшая судьба компании) в проверенных материалах нет, поэтому мы их не приводим.

Scrum of Scrums родился как практика, а не как теория: сначала появилась работающая встреча, и только через пять лет её описали.

Линия 2: развитие у Сазерленда — ежедневный SoS и MetaScrum

В 2006 году Сазерленд опубликовал статью «Future of scrum: parallel pipelining of sprints in complex projects». В ней он заново собирает «продвинутый Scrum» для сложных проектов. Туда входят перекрывающиеся спринты внутри одной команды, спринты переменной длины, заблаговременная подготовка бэклога продукта и автоматизированная связка бэклога продукта и бэклога спринта с отчётностью в реальном времени. В этот же набор входят ежедневные встречи Scrum of Scrums. Отдельно от них существует MetaScrum (метаскрам) — форум планирования релизов. По словам Сазерленда, административные накладные расходы на десятки корпоративных релизов в год занимают меньше 60 секунд в день. Для нашей темы важно разделение уровней: у автора метода SoS отвечает за ежедневную операционную синхронизацию, а релизы и приоритеты решаются на отдельном уровне MetaScrum.

Линия 3: своды знаний и официальное определение Scrum

Свод знаний SBOK от SCRUMstudy (VMEdu) оформляет технику как процесс «Созвать Scrum of Scrums» (Convene Scrum of Scrums). Выдержка из 3-го издания SBOK, приведённая в испанском учебном пособии, описывает формат так. Представитель каждой команды встречается с представителями других команд, потенциально ежедневно, но обычно два-три раза в неделю. Он рассказывает, какая работа завершена, какая будет следующей, какие препятствия есть сейчас и какие могут возникнуть и заблокировать другие команды. Цель — скоординировать работу и убрать препятствия, чтобы повысить эффективность всех команд. Для крупных проектов предусмотрен Scrum of Scrum of Scrums: тот же шаблон, только на встречу следующего уровня приходит представитель от каждого SoS.

Внутри SBOK видно расхождение. Испанская выдержка из 3-го издания говорит о командах из трёх-девяти человек. Глава 1 SBOK в другом PDF называет шесть-десять участников и советует создавать несколько команд, если численность превышает десять. Там же сказано, что жёстких правил о частоте встреч нет. Частоту определяют объём межкомандных зависимостей, размер проекта и другие факторы (на этом выдержка обрывается).

Есть и терминологическое расхождение. SBOK называет Scrum of Scrums также «мета-Scrum» (meta Scrum). У Сазерленда в статье 2006 года MetaScrum и ежедневный SoS — две разные встречи с разными задачами. Если в компании говорят «метаскрам», уточните, что имеется в виду: операционная синхронизация команд или планирование релизов.

В официальном определении Scrum отдельного события SoS нет. Scrum Guide, который разработали и поддерживают Швабер и Сазерленд, в редакции 2011 года описывает Scrum как фреймворк, внутри которого применяют разные процессы и техники. Пересказ гайда на scrum.academy перечисляет пять событий: спринт, планирование спринта, ежедневный Scrum, обзор и ретроспективу. Значит, Scrum of Scrums — дополнительная техника поверх фреймворка, а не его обязательная часть. К нескольким командам на одном продукте Scrum Guide 2020 предъявляет одно требование: совместно определить единое «Определение готовности» (Definition of Done) и соблюдать его.

Линия 4: эмпирические исследования

Распределённый проект на 40 человек (2008). Паасиваара, Сандра Дурасевич и Лассениус описали организацию разработки из 40 человек, распределённую между Норвегией и Малайзией. Исследование построено на семи интервью. Scrum там прижился: ежедневные встречи шли по телеконференции с веб-камерами, команды работали синхронизированными четырёхнедельными спринтами, раз в неделю проходил Scrum of Scrums, бэклог вели в Jira. При таком масштабе еженедельного ритма SoS хватало.

Двадцать и более команд (2012). Паасиваара, Лассениус и Хейккиля провели множественное кейс-исследование двух проектов, где работало минимум по двадцать Scrum-команд (58 интервью). SoS с представителями всех команд работал плохо: круг участников был слишком широк, чтобы встреча была интересна каждому. Это главный эмпирический аргумент против масштабирования SoS простым добавлением людей.

Enterprise Scrum (2010). Дэниел Грининг описал компанию, где 25 инженерных команд на шести продуктах управлялись единым Enterprise Scrum сверху вниз. Уровень руководства работал квартальными спринтами, оценивал трудоёмкость в командо-месяцах, назначал на проекты целые команды и проводил еженедельные стендапы. Внутри проектов оставались спринты от одной до четырёх недель и классический Scrum, а SoS использовался лишь в некоторых случаях. Ограничения общих ресурсов подтолкнули автора к методам Канбан. Вывод: SoS — один из нескольких уровней координации, причём не обязательно главный.

Возврат к Scrum и масштабирование меньше чем за год (2011). Рафаэль Маранцато, Марден Нойберт и Паула Эркулану описали команду, которая однажды уже провалила внедрение Scrum. Авторы разобрались в причинах неудачи, внедрили Scrum заново, а затем через Scrum of Scrums масштабировали работу на несколько команд, организованных по функциональности продукта. Всё это заняло меньше года.

Практический взгляд на размер команды (2013). Ашиш Мундра, Санджай Мисра и Читра Анил Давале на опыте нескольких проектов делают вывод: Scrum лучше всего подходит командам из трёх-девяти человек. Для более крупных продуктов предусмотрен Scrum of Scrums. Работа распределяется между командами, а для контроля качества и скорости каждой проводятся регулярные встречи представителей.

Линия 5: предложения по доработке модели

Две работы с участием М. Ризвана Джамиля Куреши предлагают усовершенствования модели. Саджа Аль Кураши и Куреши (2014) советуют делить большую команду на команды правильного размера и выстраивать их иерархически. Цели решения: оптимизировать коммуникацию между командами, обеспечить работу системы после интеграции частей, сократить зависимости между частями и не допустить их дублирования. Абир Аль-Мутаири и Куреши (2015) разбирают роли в SoS для распределённых проектов. Они предлагают выделенного владельца продукта для каждой команды и подчинённые бэклоги (sub-backlog), чтобы повысить сплочённость команд и убрать дублирование работы. Обе работы проверяют предложения опросами, поэтому это обоснованные гипотезы, а не доказанные эффекты.

Линия 6: практические руководства и SAFe

Отраслевые гайды (Atlassian, Wrike, SixSigma.us, PremierAgile) разбирают повестку, участников, частоту и масштабирование. Atlassian, обсуждая размер команды, ссылается на исследование Хакмана и Видмара: идеальный размер команды теоретически составляет 4,6 человека. SixSigma.us утверждает, что за пределами 10–12 команд базовую модель приходится дополнять уровнем, где встречаются представители каждого SoS. Там же сказано, что SAFe встраивает Scrum of Scrums как ключевой элемент, а координацию нескольких SoS берёт на себя инженер релизного поезда (Release Train Engineer, RTE). Порог в 10–12 команд — оценка практиков, а не результат исследования. Данные Паасиваары показывают трудности на двадцати командах, но точного порога не устанавливают.

Ключевые идеи и принципы Scrum of Scrums

1. Принцип: встреча координирует команды, а не управляет ими

   Scrum of Scrums не заменяет ежедневный Scrum и не становится «Scrum для начальников». Каждая команда по-прежнему сама планирует спринт и проводит свою ежедневную встречу. SoS добавляет поверх этого тонкий слой, где обсуждается только то, что пересекает границы команд: общие компоненты, точки интеграции, блокирующие зависимости, общие ресурсы.

   Отличие от ежедневного Scrum (Daily Scrum vs Scrum of Scrums) сводится к трём вещам. Первое — участники: на дейли приходят разработчики одной команды, на SoS — по одному представителю от каждой. Второе — предмет: на дейли обсуждают бэклог и цель спринта, на SoS — стыки между командами. Третье — частота: дейли проходит каждый рабочий день, а ритм SoS подбирают под степень связанности команд.

   Хороший Scrum of Scrums короче и скучнее ежедневного Scrum: на нём звучит только то, что касается хотя бы двух команд.

2. Принцип: от каждой команды — один представитель

   Классическая схема — один представитель от команды. Его выбирают под текущие стыки: того, кто лучше всех понимает межкомандные вопросы и может их прокомментировать. Это может быть Scrum-мастер, технический лидер или разработчик, отвечающий за интеграционный участок. Практические руководства допускают одного-двух представителей от команды. Это отступление от принципа «один представитель», и платить за него приходится размером встречи. Поэтому фрейм следит не только за числом команд, но и за числом людей: две команды по три человека дают такую же толпу, как шесть команд по одному. Порог в 9 человек — рабочая настройка фрейма. Представитель может меняться в зависимости от того, какие зависимости сейчас горят. Его обязанности работают в обе стороны: принести на встречу то, что команда не может решить сама, и вернуть в команду договорённости и чужие риски, которые её затрагивают. Чтобы поиск ответственных за общие компоненты не превращался в угадывание, полезна матрица ответственности RACI.

3. Принцип: повестка из четырёх вопросов

   Популярные пересказы сводят повестку к трём вопросам ежедневного Scrum. В SBOK их четыре, и четвёртый — самый ценный:

   • Что завершено с прошлой встречи из того, что влияет на другие команды.

   • Что команда делает дальше и что из этого заденет соседей.

   • Какие препятствия есть сейчас, особенно те, что требуют помощи другой команды.

   • Какие препятствия могут возникнуть и заблокировать другие команды. Это ранний сигнал о будущих интеграционных конфликтах.

   После круга вопросов встреча переходит к разбору препятствий: назначают владельцев и сроки, договариваются, кто с кем встречается отдельно, если вопрос касается только двух команд.

4. Принцип: частота определяется взаимозависимостью

   В SBOK прямо сказано, что фиксированного правила нет. Частоту задают объём межкомандных зависимостей и размер проекта. Типичный ритм — два-три раза в неделю, при сильной связанности — ежедневно. У Сазерленда в 2006 году SoS ежедневный, а в норвежско-малайзийском проекте на 40 человек встреча шла раз в неделю. Команды с общим кодом и общей инфраструктурой синхронизируются чаще, относительно независимые — реже. Частоту стоит пересматривать, когда меняются архитектура или состав команд.

5. Принцип: у каждого препятствия есть владелец и срок

   Названное, но никому не назначенное препятствие всплывает на следующей встрече в той же формулировке. Поэтому результат встречи — короткий журнал: препятствие, затронутые команды, владелец, срок, статус. Следующая встреча начинается с проверки этого журнала.

   Ценность Scrum of Scrums измеряется не числом встреч, а числом межкомандных препятствий, которые закрылись к следующему разу.

6. Принцип: уровни вместо одной большой встречи

   Масштабируется метод по рекурсивной схеме (scaled structure), которую обычно рисуют пирамидой. Внизу — команды. Над ними — группы SoS, каждая объединяет несколько связанных команд. Выше — Scrum of Scrum of Scrums, куда приходит по одному представителю от каждого SoS. Именно так лечится проблема, найденная Паасиваарой: встреча, куда приходят все, перестаёт быть интересной всем. Группы SoS лучше собирать по реальным зависимостям, а не по оргструктуре.

7. Принцип: единое определение готовности

   Scrum Guide 2020 требует, чтобы несколько команд, работающих над одним продуктом, совместно определили единое Definition of Done и соблюдали его. Для SoS это общий язык: «готово» у всех означает одно и то же, и интеграционные сюрпризы обсуждаются как нарушение общего стандарта, а не как спор о словах.

8. Принцип: сокращать зависимости, а не только обслуживать их

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

9. Принцип: SoS — элемент, а не фреймворк масштабирования

   Scrum of Scrums — одна встреча и связанная с ней дисциплина. Полноценные фреймворки масштабирования — SAFe, LeSS, Nexus — задают собственные роли, события и артефакты для нескольких команд. По данным SixSigma.us, SAFe включает SoS в свою конструкцию и добавляет роль RTE. Выбор подхода зависит от масштаба. Нескольким командам с понятными стыками часто хватает SoS. При десятках команд, общих приоритетах бэклога и сложной архитектуре одной встречи мало, нужен фреймворк.

Ограничения, слепые зоны и критика Scrum of Scrums

Типовые ошибки при внедрении Scrum of Scrums

1. Ошибка 1: встреча превращается в пересказ статуса.

   Представители по очереди пересказывают ежедневный Scrum своей команды: кто что делал, сколько задач закрыто. Время уходит на детали, которые касаются только одной команды. Межкомандные препятствия звучат в последние две минуты или не звучат вовсе. Через месяц на встречу начинают присылать «кого не жалко».

   Как избежать

   проверяйте каждую реплику вопросом «это затрагивает хотя бы одну другую команду?». Если нет, тема уходит во внутренний дейли. Держите повестку из четырёх вопросов SBOK и начинайте с журнала открытых препятствий, а не с круга статусов.

2. Ошибка 2: одна общая встреча для всех команд.

   С ростом числа команд за стол сажают всех представителей сразу. Это та самая ситуация, которую Паасиваара с коллегами описали для проектов с двадцатью и более командами: аудитория слишком широкая, большая часть услышанного каждому неинтересна, встреча затягивается и теряет смысл.

   Как избежать

   группируйте команды в SoS по реальным зависимостям и добавляйте уровень Scrum of Scrum of Scrums, когда групп становится несколько. Если команд десятки, оцените переход к полноценному фреймворку масштабирования.

3. Ошибка 3: фиксированная частота без учёта связанности.

   Ритм выбирают один раз («по вторникам и четвергам») и больше не меняют. Слабо связанные команды тратят время впустую, а сильно связанные узнают об интеграционном конфликте слишком поздно, когда исправлять его дорого.

   Как избежать

   выводите частоту из карты зависимостей. Методика задаёт только диапазон: обычно два-три раза в неделю, при сильной связанности — ежедневно. Соответствие «сильная — ежедневно, средняя — два-три раза в неделю, слабая — раз в неделю» — рабочая настройка фрейма. Пересматривайте ритм при изменении архитектуры или состава команд.

4. Ошибка 4: препятствия без владельцев и сроков.

   Проблему озвучили, все кивнули, никто не записал. На следующей встрече она звучит снова, и так несколько недель подряд. Участники убеждаются, что встреча ничего не решает, и настоящая координация уходит в личные переписки.

   Как избежать

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

5. Ошибка 5: представитель «по должности» и без обратной связи.

   От команды всегда ходит Scrum-мастер, даже когда обсуждается техническая интеграция, в которой он не разбирается. Или представитель ходит на встречу, но не возвращает договорённости в команду, и та узнаёт о чужих рисках, когда они уже стали её проблемой.

   Как избежать

   выбирайте представителя под текущие стыки и допускайте ротацию. Закрепите правило: договорённости SoS озвучиваются на ближайшем ежедневном Scrum команды.

6. Ошибка 6: встречами лечат архитектурные зависимости.

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

   Как избежать

   раз в несколько спринтов анализируйте журнал. Повторяющиеся зависимости — кандидаты на организационное решение: перераспределить компоненты, сформировать команды по функциональности продукта, ввести общий бэклог с подбэклогами, как предлагают Аль-Мутаири и Куреши.

План внедрения Scrum of Scrums

1. Неделя 1: карта зависимостей. Перечислите команды, работающие над общим продуктом. Для каждой пары отметьте технические зависимости (общий код, компоненты, инфраструктура, интеграционные точки) и продуктовые (общие фичи, общий релиз, общий бэклог). Оцените силу связи: сильная, средняя, слабая. Проверьте, есть ли единое Definition of Done; если нет, запланируйте его согласование. Результат недели — карта, по которой видно, какие команды должны синхронизироваться и насколько плотно.

2. Неделя 2: состав и уровни. По карте решите, нужна одна встреча или несколько групп SoS. Если команд много и они распадаются на кластеры, сразу заложите уровень Scrum of Scrum of Scrums. Каждая команда выбирает представителя под свои текущие стыки и договаривается, как он будет возвращать информацию в команду.

3. Неделя 3: частота, повестка, первые встречи. Задайте ритм каждой группы по силе зависимостей. Утвердите повестку из четырёх вопросов и правило «только то, что касается другой команды». Проведите первые встречи с жёстким таймбоксом. Для распределённых команд выберите окно пересечения рабочих часов и средства связи.

4. Неделя 4: журнал препятствий. Заведите журнал: препятствие, затронутые команды, владелец, срок, статус. Каждая встреча начинается с просроченных пунктов. В конце недели посчитайте, сколько препятствий закрыто, сколько висит дольше одной встречи и сколько времени ушло на статус, а не на стыки.

5. Неделя 5–6: ретроспектива формата. Спросите участников, что на встрече лишнее, чего не хватает и какая частота им кажется адекватной. Скорректируйте ритм, состав групп и представителей. Вынесите повторяющиеся зависимости в отдельный список кандидатов на организационное решение.

   Далее: поддержание и обновление. Раз в квартал или при изменении числа команд обновляйте карту зависимостей и пересматривайте частоту. Следите за признаками перегрузки: встреча не укладывается в таймбокс, участники молчат, препятствия не закрываются. При росте до десятков команд оцените переход к SAFe, LeSS или Nexus и решите, какое место SoS займёт в новой конструкции.

   Признак работающего Scrum of Scrums: команды узнают о чужих рисках до того, как те становятся их проблемами, а журнал препятствий не растёт от встречи к встрече.

Как реализовать этот план с помощью фрейма «Scrum of Scrums» в OrgDevTools

Фрейм «Scrum of Scrums» — бесплатный тренажёр. Он проводит вас по плану внедрения на ваших данных: команды и представители, матрица зависимостей с силой связи, журнал межкомандных препятствий, сверка частоты встреч. Рекомендуемую частоту, просрочки и размер встречи фрейм считает сам. Данных по умолчанию нет, фрейм открывается пустым. Отдельного Инструмента OrgDevTools с этим фреймом сейчас нет, работа идёт в тренажёре.

Вкладки идут не в порядке недель плана. Начните с вкладки 1: матрице нужен список команд, так что это начало недели 1. Затем заполните матрицу на вкладке 2 (неделя 1) и выберите представителей на вкладке 1 (неделя 2). После этого сверьте частоту на вкладке 4 (неделя 3) и ведите журнал на вкладке 3 (неделя 4).

Книги по теме Scrum of Scrums

• Кен Швабер, Джефф Сазерленд — «The Scrum Guide» (2011). Официальное определение Scrum как фреймворка, внутри которого применяются дополнительные техники; SoS относится именно к ним, а не к обязательным событиям.

• Кен Швабер, Джефф Сазерленд — «The Scrum Guide» (2020). Требование к нескольким командам на одном продукте совместно определить и соблюдать единое Definition of Done — общий стандарт для разговора на SoS.

• SCRUMstudy (VMEdu) — «Руководство к своду знаний по Scrum (SBOK Guide)», 3-е издание. Процесс Convene Scrum of Scrums, повестка из четырёх вопросов, типичная частота два-три раза в неделю, уровень Scrum of Scrum of Scrums и факторы выбора частоты.

• Джефф Сазерленд — «Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies» (2001, статья). Первое публичное описание Scrum of Scrums по опыту IDX.