Введение в LeSS (Large-Scale Scrum)

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

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

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

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

Пример

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

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

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

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

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

Следующая проблема – интеграция. Отдельные команды могут прекрасно справляться со своими задачами, но их результаты не всегда стыкуются друг с другом. В одном углу сделали модуль A, в другом – модуль B, а вместе они не работают. В LeSS все команды работают над общим инкрементом продукта в рамках одного спринта. Практически это означает, что к концу каждой итерации получается единая потенциально выпускаемая версия продукта, включающая вклад всех команд. Никто не откладывает интеграцию на потом – она происходит постоянно. Так у организации исчезает привычная проблема крупных проектов, когда “всё собрано вместе” только перед релизом.

Наконец, LeSS решает проблему избыточной сложности управления. В традиционных масштабных проектах число ролей, артефактов и процессов растёт лавинообразно – появляются менеджеры проектов, координаторы, отдельные команды архитекторов, и прочие надстройки, которые должны склеивать работу десятков групп. Large-Scale Scrum – это Scrum. По-прежнему есть лишь Scrum-команды, Scrum-мастера и единый Product Owner. Нет программных менеджеров и прочей сложной иерархии. Благодаря такому упрощению в 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, не скатываясь обратно в старые методы. Руководствуясь ими, компании строят более ответственные команды, ориентированные на клиента и на сотрудничество друг с другом. Вместо того чтобы быть жёстким каркасом, LeSS задает направление и ценности, позволяющие крупному продукту оставаться Agile.

Как убрать всё лишнее, чтобы организация сама стала гибкой

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

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

То есть "попробуйте вот это, если у вас такая-то ситуация", нежели "вы обязаны делать X, Y и Z". 

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

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

Как организованы команды в LeSS

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

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

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

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

Единый продуктовый подход

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

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

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

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

Как элементы LeSS усиливают друг друга

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

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

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

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

---

Мы подготовили серию статей о Large-Scale Scrum и постарались простым языком объяснить, как работает LeSS и как применять его на практике. Статьи можно читать в любом порядке. Все материалы о LeSS можно найти в методических материалах по LeSS или по ссылке:

Роли и организационная структура в LeSS
Процесс спринта и события в LeSS
Как техническое совершенство в LeSS помогает сохранить качество и гибкость при масштабировании
Принципы и ценности LeSS
Внедрение LeSS в организации
Масштабирование с помощью LeSS Huge

---