Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка.

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

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

Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.

---

Часть 1. Откуда взялся миф о серебряной пуле

Начнём с неудобного факта: Scrum сам про себя не утверждает того, что ему приписывают. Откроем Scrum Guide 2020 — первоисточник от Кена Швабера и Джеффа Сазерленда. Первая же строка определения:

«Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.»

Здесь два слова, мимо которых все пробегают. Первое — framework (рамка), не «методология». Второе — complex problems (сложные задачи). И тут же авторы добавляют, что Scrum «purposefully incomplete» — намеренно неполный, он определяет только минимум, а внутри вы сами подбираете практики, техники и инженерные подходы.

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

Почему после двухдневного курса кажется, что всё понятно

Сертификаты вроде PSM (Professional Scrum Master) — это двухдневный курс без предварительных требований, с открытым несложным экзаменом. Это нормальная точка входа. Ненормально — считать её точкой экспертизы.

Здесь работает классический эффект Даннинга-Крюгера (Крюгер и Даннинг, 1999): меньше всего свою некомпетентность осознают именно новички — им не хватает той же самой компетенции, чтобы увидеть пробел. Два дня теории дают ровно тот уровень уверенности, на котором человек искренне не понимает, чего он не знает. А не знает он самого сложного — как адаптировать рамку под конкретный контекст. Именно это, а не заучивание церемоний, и есть работа.

Сам сертификат, кстати, ни в чём не виноват — это нормальная точка входа в профессию, я и сам через это проходил. Беда начинается там, где точку входа принимают за точку прибытия.

Zombie, Dark, Flaccid: у провала есть имена

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

• ScrumBut (Scrum.org) — «мы используем Scrum, но…». Классическая формула, которая сохраняет проблему, маскируя её: команда меняет Scrum так, чтобы дисфункция перестала колоть глаза, вместо того чтобы её решить.

• Dark Scrum (Рон Джеффрис, один из авторов Agile-манифеста, 2016) — Scrum, который угнетает разработчиков: давление спринтом без инженерной культуры и безопасности.

• Zombie Scrum (The Liberators / Scrum.org) — все церемонии проводятся, но продукт не выходит, обратной связи нет, команда изолирована от стейкхолдеров. «Scrum in name only».

• Flaccid Scrum (Мартин Фаулер, 2009) — Scrum без инженерных практик: скорость есть, а качество копит техдолг, пока разработка не встаёт. Фаулер там же вводит термин semantic diffusion — размывание смысла по мере роста хайпа. Со Scrum это произошло в полной мере.

Есть и цифры, пусть их и надо читать осторожно. 17-й State of Agile Report от Digital.ai (январь 2024) зафиксировал падение удовлетворённости Agile-внедрениями: с 71% до 59% за год. А громкое (и спорное) исследование Engprax (июнь 2024) заявило о 268% более высокой вероятности провала проектов «на Agile-требованиях». К последней цифре отношусь скептически — исследование вендорское и методологически критикуемое, — но даже как провокация она про одно: проблема не в Agile-идее, а в её карго-культовом применении.

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

---

Часть 2. Где именно всё ломается: несколько команд — один продукт

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

Мне этот контекст знаком не по книгам. В одной из организаций, которыми я руководил, над единым продуктом одновременно работало до восьми команд. А в департаменте, который я вёл последним, над одним продуктом параллельно шли четыре продуктовые команды, две команды техподдержки и две сервисные — DevOps и платформа; именно там я разворачивал масштабированный Scrum и перестраивал структуру (подробно — во второй половине статьи). Это ровно та среда, где «просто раскатите Scrum на всех» — худший из возможных советов.

Что происходит, когда каждой команде выдают «свой Scrum»

«Голый» Scrum описывает одну команду: один Product Owner, один бэклог, один инкремент. Как только команд становится несколько, а продукт один, начинаются структурные проблемы, которых в Scrum Guide просто нет ответов (там про масштаб — буквально пара предложений про общий Product Goal и общий Definition of Done).

1. Компонентные команды вместо продуктовых. Каждая команда владеет своим куском (фронт, бэк, платёжи, «ядро»). Любая мало-мальски ценная фича задевает несколько кусков — и превращается в цепочку передач между командами. Появляются зависимости, которые невозможно уместить в один спринт.

2. Локальная оптимизация. У каждой команды свой бэклог и свои цели. Все закрывают свои спринты «на зелёно» — а продукт в целом не двигается. Классика: восемь успешных команд и один буксующий релиз.

3. Scrum-of-Scrums как пластырь. Стандартный ответ — Scrum-of-Scrums, «синк синков». Он неплохо живёт до ~5–6 команд, а дальше тонет: число каналов коммуникации растёт нелинейно, а интеграция и разрешение зависимостей превращаются в отдельную работу, которой никто не владеет.

4. Интеграционный ад. Пока команды спринтят по своим веткам, никто не собирает целое. «Готово» у восьми команд не означает «готов продукт» — впереди недели интеграции, о которых в оценках забыли.

Как это выглядит вживую? Простая, казалось бы, фича — «добавить новый способ оплаты» — едет через фронт, бэк, платёжное ядро и аналитику. Каждая команда закрывает свой кусок «в срок», с чистой совестью уходит в следующий спринт. А потом наступает та самая неделя, когда всё это надо соединить, — и выясняется, что контракт API три команды поняли по-своему, а тестового окружения на всех не хватает. Фича, которую «сделали» месяц назад, реально выходит ещё через три недели. И — что особенно обидно — виноватых нет: у каждой команды каждый спринт был зелёным.

Почему это не лечится «ещё одним синком»

Тут стоит вспомнить законы Крейга Лармана. Пятый из них: «культура следует за структурой» (culture follows structure). Если оргструктура построена вокруг компонентов и функциональных колодцев, никакие церемонии этого не перекроют — люди будут оптимизировать свой участок, а не продукт. А ещё Ларман язвительно замечает: любое изменение организация переваривает так, чтобы оно стало «примерно тем же, что и статус-кво», объявив, что «нам нужна адаптация под локальную специфику». Знакомо? Это и есть механизм, которым «внедрение Scrum» превращается в «то же самое, только с новыми словами».

Здесь и зарыта собака: беда не в том, что команды плохо делают Scrum. Беда в том, что проблема координации нескольких команд вокруг одного продукта — это проблема структуры и потока, а не проблема церемоний внутри команды. Scrum её просто не решает, потому что не про это.

---

Часть 3. Что действительно работает: LeSS для «много команд — один продукт»

Если «голый» Scrum на несколько команд — это антипаттерн, то что паттерн? Для случая «несколько команд, один продукт» есть фреймворк, созданный ровно под него — LeSS (Large-Scale Scrum) Крейга Лармана и Баса Водде.

Я подходил к масштабированию с этой стороны на практике: именно на том департаменте — четыре продуктовые команды, две команды техподдержки и две сервисные (DevOps и платформа) вокруг одного продукта — я в первую очередь и обкатывал, и разворачивал LeSS. Поэтому дальше — не пересказ сайта, а то, почему это работает.

Механика LeSS в одном абзаце

LeSS берёт Scrum и не размножает его по командам, а наоборот — держит продукт единым. По less.works (Ларман и Водде):

• один Product Owner на продукт — независимо от того, три у вас команды или тридцать три;

• один общий Product Backlog — единый источник приоритетов, а не восемь локальных;

• один общий спринт для всех команд с единым Definition of Done;

• feature-команды вместо компонентных: команда берёт клиентскую фичу целиком и доводит до «готово», работая по всему коду, а не в своём углу;

• общий Sprint Review (в формате «базар») и Overall Retrospective поверх командных — чтобы ловить системные, межкомандные проблемы.

Сравните с болями из части 2 — и вы увидите, что LeSS адресует их по пунктам. Feature-команды убивают цепочки передач и зависимостей. Единый бэклог и один PO убирают локальную оптимизацию — приоритет один на продукт. Общий спринт и единый DoD убирают интеграционный ад: «готово» означает «интегрировано и готово к поставке».

Главный принцип: не «scaling», а «descaling»

Самое важное в LeSS — философия. Она называется «More with LeSS»: больше ответственности через меньше ролей, больше клиентоориентированности через меньше артефактов, больше владения через меньше процесса. LeSS масштабируется, убирая координационные слои, прослойки и роли-посредники, а не добавляя их. Для 8+ команд есть LeSS Huge: продукт делится на клиентские Requirement Areas со своими Area Product Owner — но общий PO и единый бэклог сохраняются.

Честно про ограничения

LeSS — не бесплатный обед, и я обязан это сказать. Он требует редизайна оргструктуры (переход к feature-командам — это больно и политически, и технически), сильной инженерной культуры (CI, автотесты, работа в общем коде) и зрелого продуктового владения (один PO, который реально держит продукт). Внедрения на уровне всей компании нередко растягиваются на годы. В моём случае на разворот и стабилизацию LeSS в этом департаменте из восьми команд ушло около 7–8 месяцев — быстро, но лишь потому, что параллельно я менял и структуру команд (об этом ниже), а не одни церемонии. Если в компании крепкая функциональная иерархия и слабая инженерная база, минимализм LeSS будет ощущаться не как элегантность, а как «нам не дали поддержки». Это ровно тот случай, когда фреймворк выбирают под контекст, а не наоборот.

Из громких внедрений LeSS публично известны кейсы BMW (автономное вождение, LeSS Huge, 2016–2019) и John Deere. Оговорюсь честно: часто гуляющую цифру «+165% output у John Deere» приписывают LeSS ошибочно — это кейс Scrum@Scale, не путайте.

---

Часть 4. «А как же SAFe и Scrum@Scale?»

Как только речь заходит о масштабе, в чате всплывает SAFe. Скажу коротко и честно, потому что тема холиварная.

SAFe (Scaled Agile Framework) — самый популярный фреймворк масштабирования в энтерпрайзе, и не случайно: он даёт большим организациям привычную структуру — уровни, роли, PI-планирование, синхронизацию сотен людей вокруг стратегии. Там, где важны предсказуемость на масштабе, регуляторка и согласование с топ-менеджментом, он закрывает реальную боль. У Agilemania есть разбор, почему SAFe так популярен.

Обратная сторона — вес и прескриптивность. Критику лучше всего сформулировал сам Кен Швабер (соавтор Scrum) в заметке «unSAFe at any speed» (2013): по его мнению, SAFe продаёт «простой универсальный подход», возвращая тяжёлую процессную культуру, от которой Agile когда-то уходил. Многие практики повторяют: SAFe легко превращается в «водопад, порезанный на спринты».

Есть и третий путь — Scrum@Scale Джеффа Сазерленда, который позиционирует себя как «minimum viable bureaucracy»: масштабировать сеть Scrum-команд, добавляя минимум структуры.

Что это значит на практике: descaling (LeSS) против scaling (SAFe) — это не «кто прав», а выбор под контекст и зрелость. Продуктовая компания со зрелой инженерией и одним продуктом — territория LeSS/Team Topologies. Крупный зарегулированный энтерпрайз с сотнями людей и портфелем — чаще SAFe, со всеми его издержками. Тот, кто говорит «всегда X», продаёт вам серебряную пулю.

Кстати, к этому же выводу приходит и Naveen Kumar Singh из Agilemania в разборе «SAFe vs LeSS vs Spotify vs Nexus»: не тянитесь за скейлинг-фреймворком раньше времени, начинайте с простого и выбирайте по контексту.

---

Часть 5. AI-эра: почему адаптивность выходит на первый план

Теперь — то, что делает тему острой именно сейчас. Скорость изменений выросла, а с приходом AI-инструментов — кратно. По отчёту DORA 2025 (Google), AI-ассистенты используют уже около 90% разработчиков. Но вывод отчёта важнее процента: AI усиливает и сильные, и слабые стороны вашего потока. Он поднимает пропускную способность — и одновременно бьёт по стабильности доставки, если у команды нет быстрой обратной связи и здорового потока. Тяжёлый прескриптивный процесс в этих условиях становится якорем.

Отсюда закономерный крен в сторону лёгких, потоковых, адаптивных подходов. Здесь я бы выделил три вещи — и одну из них применяю прямо сейчас.

1. Disciplined Agile (DA) — как мета-рамка «выбирай под контекст». DA (входит в PMI) честнее всех признаёт, что серебряной пули нет. Это не ещё один жёсткий фреймворк, а, по формулировке Agilemania, «process decision toolkit… который позволяет команде выбрать наилучший способ работы (Way of Working) под её уникальный контекст». По сути DA институционализирует главную мысль этой статьи: не «внедри фреймворк», а «осознанно собери свой процесс из практик под свою ситуацию». Цена — DA поначалу ошеломляет обилием опций.

2. Team Topologies — org-дизайн под быстрый поток (мой основной кейс). Это подход, который я применял на практике: перестраивал по принципам Team Topologies (Скелтон и Пайс) не церемонии, а саму структуру департамента и потоки разработки. Идея — проектировать организацию под быстрый поток ценности и управлять когнитивной нагрузкой команд (четыре типа команд: stream-aligned, platform, enabling, complicated-subsystem; три режима взаимодействия). Это ровно тот слой, которого не хватает Scrum: он про то, как нарезать команды и потоки, а не про ритуалы внутри команды.

Что было «до». Разрозненные команды разработки — отдельно, техподдержка — отдельно. Ответственность разрезана: одни «сдают функционал», другие потом поддерживают его в проде. Результат предсказуем: проседало качество разработки и доставки, медленно реагировали на запросы клиентов и на баги прода, а сверху — плотные зависимости на экспертизу соседних команд и на code owner’ов для кросс-ревью. У самой техподдержки проседала и техническая, и продуктовая экспертиза, из-за чего её задачи вечно упирались в разработку — а разработка вечно отвлекалась от своих. Фабрика bottleneck’ов.

Живой пример из тех времён. В поддержку прилетает баг по фиче, которую делали полгода назад. Сама поддержка починить не может — экспертизы не хватает — и эскалирует в разработку. Разработчик, который эту фичу когда-то писал, уже месяц живёт в другом контексте: он поднимает старый код, вспоминает, чинит — и теряет полтора-два дня своего спринта. Умножьте на десятки тикетов в месяц. Формально у нас «был Scrum». По факту — две команды, которые мешали друг другу работать, и обе честно выгорали.

Что стало «после». Я собрал кросс-функциональные полноцикловые команды (по духу — stream-aligned): каждая владеет своей частью продукта от и до — от проработки идеи и разработки до поставки, пост-продакшн-обслуживания, багфиксов, мониторинга сервисов и метрик. Внутрь команды вошли все нужные экспертизы, включая поддержку.

Эффект, который я видел своими глазами: заметно выросли ответственность и автономность команд и отдельных инженеров за свой функционал; ушёл целый пласт bottleneck’ов и межкомандных зависимостей; качество не просело, а выросло — меньше багов после релиза. Исчез разрыв «разработка ↔ поддержка»: раньше поддержка была слабым звеном со внешней зависимостью, теперь экспертиза живёт внутри команды. И, что для меня ценнее всего вдолгую, — внутри команд завелась культура непрерывного обмена знаниями и роста прямо на рабочих задачах.

Осознанный размен, который я бы повторил: да, команды стали отгружать чуть меньше «сырого» функционала в единицу времени — но кратно выигрывали в качестве, скорости реакции и предсказуемости. И, что важнее, уменьшилось не полезное, а сорное: переделки, rework, возвраты багов из прода, работа «на выброс». Меньше суеты — больше реальной ценности. Та же линия, что я отстаиваю в теме предсказуемости доставки: предсказуемый поток ценности важнее голой скорости.

Для случая «много команд — один продукт» это ложится поверх feature-команд из LeSS идеально: LeSS даёт единый бэклог и общий ритм, Team Topologies — правильную нарезку команд и потоков под него.

3. FAST Agile / Kanban-flow — крайняя степень адаптивности. Когда приоритеты меняются буквально на ходу, помогает поток без жёстких спринтов: Kanban с WIP-лимитами и коротким cycle time — как самый простой способ «реагировать очень быстро». А из свежего — FAST Agile (Fluid Adaptive Scaling Technology): флюидные самоформирующиеся команды, которые каждую короткую итерацию перегруппировываются вокруг главных приоритетов. Пока это ниша, но по духу — самый «адаптивный из адаптивных».

Вывод по AI-эре: AI не отменяет инженерную и процессную дисциплину — он повышает ставки. В мире, где код пишется быстрее, выигрывает тот, у кого быстрее и чище поток: понятная структура команд, короткая обратная связь, право собрать процесс под контекст. Это ещё один гвоздь в гроб идеи «один фреймворк на всё».

---

Часть 6. Практический гайд: как выбрать под контекст

Вместо серебряной пули — рабочая эвристика. Не догма, а стартовая карта; дальше адаптируете.

Три вопроса, которые я задаю раньше выбора фреймворка:

1. Сколько команд и один ли продукт? Одна — Scrum/Kanban достаточно. Несколько на один продукт — это про структуру и поток (LeSS, Team Topologies), а не про размножение церемоний.

2. Какая зрелость инженерии? Без CI, автотестов и работы в общем коде любой «масштабированный Agile» станет масштабированным хаосом. Сначала инженерная база.

3. Насколько изменчив контекст? Чем быстрее меняются вводные (привет, AI), тем легче и потоковее должен быть процесс, и тем больше веса у адаптивности, а не у ритуала.

---

Вывод

Серебряной пули нет — и в этом хорошая новость. Scrum не «плохой»; он отличный инструмент для своей задачи и бесполезный (а то и вредный) не по своей вине, когда его натягивают туда, где нужен другой инструмент. Настоящая экспертиза руководителя разработки — не в том, чтобы знать наизусть церемонии Scrum после двухдневного курса. Она в том, чтобы поставить диагноз контексту и собрать под него процесс: где-то это чистый Scrum, где-то Kanban-поток, для «много команд — один продукт» — LeSS с feature-командами и Team Topologies поверх, а в AI-эру — крен в лёгкость, поток и право выбирать Way of Working под ситуацию.

Если после этой статьи вы поймаете себя на фразе «давайте просто раскатим Scrum на всех» — остановитесь и задайте три вопроса выше. Это сэкономит вам год и одну репутацию.

---

Источники

• Scrum Guide 2020 — Schwaber & Sutherland: https://scrumguides.org/scrum-guide.html

• ScrumBut — Scrum.org: https://www.scrum.org/resources/what-scrumbut

• Dark Scrum — Ron Jeffries (2016): https://ronjeffries.com/articles/016-09ff/defense/

• Four Symptoms of Zombie Scrum — The Liberators / Scrum.org: https://www.scrum.org/resources/blog/four-symptoms-zombie-scrum

• Flaccid Scrum — Martin Fowler (2009): https://martinfowler.com/bliki/FlaccidScrum.html

• Larman’s Laws of Organizational Behavior — Craig Larman: https://www.craiglarman.com/wiki/index.php?title=Larman’s_Laws_of_Organizational_Behavior

• 17th State of Agile Report — Digital.ai (2024): https://digital.ai/resource-center/analyst-reports/state-of-agile-report/

• LeSS Framework — less.works (Larman & Vodde): https://less.works/less/framework/introduction

• More with LeSS — less.works: https://less.works/less/principles/more-with-less

• LeSS Huge / Requirement Areas — less.works: https://less.works/less/less-huge/requirement-areas

• «unSAFe at any speed» — Ken Schwaber (2013): https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/

• Scrum@Scale Guide — Jeff Sutherland: https://www.scrumatscale.com/scrum-at-scale-guide/

• Team Topologies — Skelton & Pais: https://teamtopologies.com/

• FAST Agile — Ron Quartel: https://www.fastagile.io/

• DORA Report 2025 (AI-assisted development) — Google/DORA: https://dora.dev/dora-report-2025/

• Types of Agile Frameworks (2026 Guide) — Agilemania: https://agilemania.com/types-of-agile-frameworks

• SAFe vs LeSS vs Spotify vs Nexus — Naveen Kumar Singh, Agilemania: https://agilemania.com/safe-vs-less-vs-spotify-or-nexus-to-be-agile

Об авторе

Head of Delivery / R&D Director. Пишу о доставке без воды: предсказуемость, метрики, масштабирование, people management. LinkedIn: linkedin.com/in/aliaksei-labachou-28047890