Масштабирование agile в растущих компаниях. Когда одной Scrum-команды уже мало

IT-сектор у нас вырос в 18 раз с 2019 года, и экспорт IT-услуг достиг $1 млрд в 2025 году. За этими цифрами стоят компании, которые масштабируются быстро. Kolesa Group управляет несколькими продуктами (Kolesa, Krysha, Market) с десятками команд. Halyk Bank с 7.7 млн активных пользователей Superra постоянно наращивает продуктовые команды. В Astana Hub зарегистрировано более 1 500 компаний, и многие из них проходят этап, когда одной Scrum-команды становится мало.

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

Как обычно выглядит рост

Пока в компании одна команда, всё просто. Product Owner знает беклог, команда знает друг друга, решения принимаются быстро. Scrum работает как часы.

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

При пяти командах неформальная координация начинает давать сбои. Две команды одновременно меняют один сервис и ломают друг другу сборку. Беклоги пересекаются, но PO об этом узнают постфактум. Появляются «незаметные» зависимости, которые вскрываются в момент интеграции. Знакомая ситуация для многих растущих компаний у нас.

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

Три подхода к масштабированию

SAFe (Scaled Agile Framework) предлагает комплексную структуру с готовыми ролями, церемониями и метриками. Agile Release Train объединяет 5-12 команд, PI Planning проводится раз в квартал, Release Train Engineer координирует работу. SAFe хорошо подходит крупным организациям с 10+ командами и сложными зависимостями между продуктами. Gartner называет его «фреймворком номер один по уровню внедрения среди крупных организаций».

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

LeSS (Large-Scale Scrum) идёт от противоположного. Вместо добавления новых слоёв LeSS убирает лишние. Команды взаимодействуют с бизнесом напрямую, координация происходит через общий беклог и совместное планирование. LeSS хорошо работает для 2-8 команд над одним продуктом, когда команды достаточно зрелые для самоорганизации.

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

Flight Levels, предложенный Клаусом Леопольдом, это скорее модель мышления. Координация работы визуализируется на трёх уровнях: операционный (одна команда), координационный (несколько команд), стратегический (вся организация). На каждом уровне выстраивается поток и WIP limits. Привлекательность Flight Levels в том, что он не требует перестройки организационной структуры и позволяет начать с малого.

Кастомный подход: почему он часто лучше готового фреймворка

На практике многие компании, поработав с SAFe или LeSS, собирают свою систему координации из элементов разных подходов. PI Planning из SAFe, общий беклог из LeSS, визуализация потока из Flight Levels, собственные ритуалы. Это требует более глубокого понимания принципов каждого фреймворка, но результат обычно гибче и легче.

Для наших компаний, которые растут быстро и часто меняют структуру, кастомный подход особенно актуален. Жёсткий фреймворк, внедрённый в компании из 5 команд, через год может оказаться тесным для 12 команд или, наоборот, избыточным, если компания перестроила архитектуру продукта и зависимостей стало меньше.

Как понять, что пора масштабировать

Несколько сигналов, на которые стоит обратить внимание.

Зависимости вскрываются на этапе интеграции. Если команды регулярно обнаруживают конфликты при мерже или деплое, координация недостаточна.

PO не знают, что делают другие команды. Если product owner одной команды узнаёт о планах другой из Slack-канала общих новостей, координация строится на удаче.

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

При этом базовый Scrum работает. Масштабировать имеет смысл то, что работает. Если отдельные команды ещё не освоили базовые agile-практики, масштабирование рискует превратиться в масштабирование хаоса.

Где разобраться глубже

Тренинг Масштабирование Agile: SAFe, LeSS и Flight Levels разбирает все три подхода на практике. 12 модулей: от организации кросс-функциональных команд и выбора фреймворка до метрик, управления зависимостями и системы постоянных улучшений. Тренинг помогает выбрать подход, который подходит именно вашей организации, с учётом контекста и зрелости команд.

Для менеджеров проектов и delivery-менеджеров полезна программа Agile Project Management. Метрики потока, прогнозирование и прозрачность для бизнеса на уровне нескольких команд.