Введение в LeSS (Large-Scale Scrum, Скрам в Масштабе) 💎 — OnAgile Consulting

Введение в LeSS (Large-Scale Scrum, Скрам в Масштабе)

Scrum доказал свою эффективность на уровне одной команды – простой процесс, прозрачность, постоянная адаптация и результат. Но что происходит, когда в разработку продукта вовлечены десятки или даже сотни людей?

Представьте себе небольшую Scrum-команду, которая работает слаженно и быстро. Каждые пару недель она поставляет улучшенный продукт, заказчики довольны, руководство в восторге. Scrum доказал свою эффективность на уровне одной команды – простой процесс, прозрачность, постоянная адаптация. Но что происходит, когда таких команд становится не одна, а пять, десять, двадцать? Первоначальная легкость Scrum начинает давать сбои. То, что отлично работало для семи разработчиков в одной комнате, внезапно становится с хаосом в масштабе сотен людей. 

Почему масштабирование Scrum становится проблемой?

Когда организация пытается распространить успех одной Agile-команды на весь отдел или компанию, она натыкается на неожиданные трудности. Добавление новых команд не даёт линейного роста продуктивности – порой происходит наоборот. 

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

Почему так произошло? Дело в том, что Scrum изначально задуман для одной небольшой команды, которая самостоятельно управляет всеми аспектами разработки. Эта команда имеет единое видение продукта через одного Product Owner, работает над единым бэклогом и каждый спринт выдаёт цельный инкремент. Но когда команд много, сохранять единое направление сложно – появляются разрозненные кусочки продукта, несовпадающие приоритеты, и риск вернуться обратно к старой иерархической бюрократии. 

В больших группах люди начинают специализироваться на узких компонентах, теряя ощущение целостности продукта. Интеграция результатов откладывается «на потом» – до большого релиза – вместо того, чтобы происходить каждую итерацию. В итоге Agile-принципы размываются: вместо быстрого получения обратной связи мы снова видим длительные циклы, зависимость от долгосрочных планов и нарастающую сложность управления.

Можно ли этого избежать 

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

И все же, необходимость масштабировать Agile никуда не делась. По мере распространения Scrum стало ясно, что индустрии нужны новые подходы для крупных продуктов – и они начали появляться. Одним из них стал Large-Scale Scrum (LeSS).

Какие проблемы LeSS решает в больших организациях

Масштабируя Scrum, организация сталкивается с несколькими проблемами, и каждая из них отражена в дизайне LeSS.

  • Одна из таких проблем – утрата общего фокуса и видения продукта. Когда десять команд работают над одним продуктом, есть риск, что каждая сконцентрируется лишь на своей части и упустит из виду сам продукт, который нужен клиенту.
  • Добавьте к этому нехватку синхронизации – команды работают в разном ритме, информация о изменениях не успевает распространяться, и внезапно выясняется, что то, что построила команда X, уже устарело, потому что команда Y изменила общую архитектуру. 

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

  • Следующая проблема – интеграция. Отдельные команды могут прекрасно справляться со своими задачами, но их результаты не стыкуются друг с другом. В одном углу сделали модуль A, в другом – модуль B, а вместе они не работают.В LeSS все команды работают над общим инкрементом продукта в рамках одного спринта. Практически это означает, что к концу каждой итерации получается единая потенциально выпускаемая версия продукта, включающая вклад всех команд. Никто не откладывает интеграцию на потом – она происходит постоянно, на каждом шагу. Да, это требует больше самостоятельной координации между командами, но именно к этому и стремится LeSS. Так у организации исчезает привычная проблема крупных проектов, когда “всё собрано вместе” только перед релизом.
  • Наконец, LeSS решает проблему избыточной сложности управления. В традиционных масштабных проектах число ролей, артефактов и процессов растёт лавинообразно – появляются менеджеры проектов, координаторы, отдельные команды архитекторов, и прочие “надстройки”, которые должны склеивать работу десятков групп. Large-Scale Scrum – это Scrum. LeSS сознательно не вводит новых ролей сверху. По-прежнему есть лишь Scrum-команды, Scrum-мастера и единый Product Owner. Нет программных менеджеров, нескольких уровней владельцев требований и прочей сложной иерархии (по крайней мере в базовой LeSS, для совсем уж больших продуктов вводится лишь роль Area Product Owner в LeSS Huge, но это исключение).

Благодаря такому упрощению снижается организационное трение – решения принимаются быстрее, команд не сковывает чрезмерный контроль, а коммуникация происходит напрямую “команда – команда” или “команда – владелец продукта”. LeSS, по сути, убирает лишние помехи, чтобы проблемы крупной разработки решались не бюрократией, а самими людьми. В результате уменьшается количество производственных потерь: меньше совещаний ради совещаний, меньше передачи ответственности по цепочке, меньше артефактов ради отчетности.

Какие принципы лежат в основе LeSS – и почему

Если начать задумываться, как именно масштабировать Scrum, то становится понятно, что нельзя терять те ценности и принципы, которые сделали Scrum успешным. Поэтому фундаментальные идеи LeSS родились из принципов Scrum, дополненных бережливыми и системными подходами. 

Эмпирический подход

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

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

Прозрачность 

Если проблемы и результаты скрыты, то и адаптироваться невозможно. Поэтому LeSS требует прозрачности на всех уровнях: общий Definition of Done, открытая информация о прогрессе, регулярные обзоры продукта, где участвуют все команды. Когда десятки команд видят реальную картину целиком – что сделано, что нет, куда движется продукт – им легче синхронизироваться и принимать верные решения.

Lean (бережливое) и системного мышление

Lean-принцип – ценность для клиента без лишних трат. Постоянно спрашивайте себя: а нужна ли эта роль или артефакт? Добавляет ли она ценность для продукта – или лишь усложняет систему?

Получать большее за счёт меньшего

Проще говоря, это означает стремиться к большему эффекту через меньшие средства – меньше правил, меньше лишней работы, меньше бюрократии. Если какая-то практика не приносит ощутимой пользы пользователю или командам – можно от неё смело отказаться. 

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

Что толку, если одна команда работает сверх-эффективно, но общий продукт при этом задерживается? Системное видение позволяет держать в центре внимания сквозной поток ценности – от замысла до поставки клиенту. Задача LeSS – сократить общий цикл поставки продукта, а не максимизировать загрузку каждой отдельной команды. 

Фокус на продукте целиком, клиентоориентированность и непрерывное улучшение

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

В итоге экспериментальные решения оформились в десять принципов LeSS:

  1. Large-Scale Scrum — это Скрам, 
  2. Эмпирический подход, 
  3. Прозрачность, 
  4. Лучшие результаты меньшими усилиями, 
  5. Фокус на целом продукте. 
  6. Ориентир на клиента
  7. Непрерывное совершенствование
  8. Системное мышление
  9. Бережливое мышление
  10. Теория массового обслуживания (queuing theory) для управления потоком работы

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

Руководствуясь ими, компании строят более ответственные команды, ориентированные на клиента и на сотрудничество друг с другом. Эти команды учатся и улучшаются каждую итерацию, сохраняя дух Scrum даже на масштабе. Вместо того чтобы быть жёстким рецептом, LeSS задает направление и ценности, позволяющие крупному продукту оставаться Agile.

Как LeSS сохраняет простоту и гибкость

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

Такая минималистичность – это осознанный выбор. Она позволяет большой организации быстрее учиться и меняться. Вместо толстого регламента LeSS предоставляет небольшой набор правил и рекомендаций. Их действительно немного – базовые правила LeSS укладываются на нескольких страницах. Всё остальное – гайды и эксперименты, которыми команды могут воспользоваться при необходимости. 

То есть LeSS скорее говорит "попробуйте вот это, если у вас такая-то ситуация", нежели "вы обязаны делать X, Y, Z". Это дает простор для адаптации. Каждая компания может слегка по-своему реализовать LeSS, не нарушая его основных принципов, подстраивая детали под свою культуру и специфику. Ключевые элементы – один продукт, кросс-функциональные команды, общий инкремент – остаются неизменными, а остальное можно экспериментировать.

Простота LeSS — не самоцель, а средство

Меньше правил и ролей означает меньше препятствий для творческой работы команд. Когда нет длинной цепочки согласований, команды могут быстрее принимать решения и реагировать на изменения. Когда артефактов минимум, ничто не отвлекает от главной цели – создания ценности для клиента. 

Представьте себе масштабный проект, где сотрудники тратят уйму времени на заполнение статус-отчётов, согласование документов между отделами и хождение по бесконечным совещаниям. LeSS возвращает людям время и пространство, чтобы сосредоточиться на продукте. Гибкость рождается из доверия к командам и устранение ограничений. Если завтра рынок поменяется или придет новая идея от пользователя – большая организация, работающая по LeSS, способна развернуться почти так же быстро, как одна маленькая команда. Потому что у неё нет есть короткий цикл доставки, прозрачность, контакт с клиентом – всё то же самое, что и у Scrum, просто распространяющееся на множество исполнителей.

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

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

Самоорганизующиеся команды и единый продукт

Наконец, мы подошли к сердцу LeSS – тому, без чего невозможна ни гибкость, ни успех в масштабировании. Речь о самоорганизации команд и едином продуктовом подходе. 

Почему мы считаем их краеугольными камнями? Потому что альтернативы не работают. Невозможно руководить каждым шагом десятка команд централизованно и при этом оставаться быстрыми и адаптивными. Поэтому LeSS опирается на самоорганизующиеся команды, так же как Scrum, но в большем масштабе. Командам доверена большая ответственность – не только за выполнение задач, но и за координацию, планирование и совместное решение возникающих меж-командных проблем. 

В традиционных структурах при большом числе групп обычно вводят слои менеджмента, которые говорят командам, кто что делает. LeSS принципиально уходит от этого. Вместо менеджеров-посредников команды общаются напрямую. Например, если двум командам нужен один и тот же компонент, они сами договариваются, как лучше распределить работу, без приказа сверху. Еженедельные общие встречи, где собираются представители всех команд, позволяют выявить зависимости и быстро их распутать. Scrum-мастера в LeSS часто работают на несколько команд и помогают им наладить самоуправление, выступая скорее коучами, чем руководителями. 

А что же делают менеджеры среднего звена? Они перестают командовать и переходят в роль наставников и учителей, передавая знания, убирая организационные препятствия и развивая людей. Это коренной культурный сдвиг – доверие вместо контроля. Но без него масштабная Agile-трансформация невозможна. 

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

Второй ключевой элемент – единый продуктовый подход

Это означает, что все команды работают над одним общим продуктом, а не над разрозненными компонентами или проектами. Звучит очевидно: «ну конечно, у нас один продукт». Но на практике, без специального подхода, десятки команд легко превращают один продукт в множество частичных под-продуктов. 

Каждая команда может быть привязана к своему модулю и оптимизировать только его, теряя из виду целое. LeSS сознательно ломает такие стены. Команды формируются как кросс-функциональные фиче-команды, способные выполнить любую функциональность от запроса пользователя до готового результата. Они не закреплены навечно за узкими компонентами – наоборот, поощряется, что команды берут задачи по всему продукту.

Конечно, у каждой команды могут быть области экспертизы, но границы гибкие. Даже если над продуктом трудятся 50 или 500 человек, у нас всё равно остаётся один бэклог для одного продукта, один список работ, один Product Owner, единые критерии готовности и единый ритм спринтов.

Все команды планируют спринт вместе, чтобы разойтись по задачам так, чтобы в конце спринта получился единый интегрированный инкремент. Это и есть тот самый принцип «фокус на продукте целиком». Зачем такая строгость? Чтобы все участники думали о продукте, а не только о своей части. Клиенту ведь нужен целый продукт, а не набор несобранных деталей. Если бы каждая команда работала обособленно и выпускала только свой фрагмент, то клиенту пришлось бы самому собирать пазл из этих фрагментов – вряд ли он останется доволен. Единый продуктовый подход заставляет команду действовать как части одного механизма. Успех измеряется не выполнением отдельной задачи, а ценностью для пользователя, которую доставил совместный инкремент.

Самоорганизация команд и единое видение продукта дополняют друг друга

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

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

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

В этом введении мы рассмотрели, как LeSS решает ключевые проблемы – несовпадение приоритетов, интеграцию, избыточную сложность – опираясь на фундаментальные принципы Scrum, Lean и системного мышления. 

Простота может быть мощнее сложности, если за ней стоят правильные принципы. LeSS сохраняет гибкость, потому что доверяет командам самоорганизоваться и направляет их общим видением одного продукта. В итоге организация получает много-командный Scrum, работающий как единое целое. Именно этого добивались авторы LeSS – чтобы масштаб не убивал Agile. 

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

LeSS лишь указывает путь. Следовать по нему предстоит вам.

Интересно узнать подробнее?

Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.

Еще публикации по Agile в Масштабирование: SAFe, LeSS, Nexus

Публикация
Масштабирование: SAFe, LeSS, Nexus
Сравнение фреймворков масштабирования Agile
Рассмотрим четыре популярных подхода: SAFe, LeSS, Nexus и Flight Levels — чем они отличаются, где применяются и как выбрать подходящий для вашей организации.
Публикация
Масштабирование: SAFe, LeSS, Nexus
Роли и организационная структура в LeSS
Large-Scale Scrum (LeSS) родился из стремления расширить Scrum на несколько команд, не растеряв при этом его дух и основные принципы.
Публикация
Масштабирование: SAFe, LeSS, Nexus
Процесс спринта и события в LeSS
LeSS – это прозрачность, синхронность и живое взаимодействие команд без посредников и новых ролей.
Публикация
Масштабирование: SAFe, LeSS, Nexus
Как масштабируемые фреймворки ускоряют работу команд и улучшают качество решений
Agile отлично работает в небольших командах, но что, если у вас сотни сотрудников? Или даже тысячи? Фреймворки масштабирования помогают внедрить гибкость на всех уровнях компании, сохраняя прозрачность и эффективность.

Ближайшие тренинги по Agile и Scrum

С 2004 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!