Технологическая компания организует команды строго по техническим компонентам системы — отдельная команда фронтенда, отдельная бэкенда, отдельная база данных. Простая клиентская фича, требующая небольших изменений на всех трёх уровнях, вынуждена последовательно проходить через очереди всех трёх команд, каждая из которых имеет собственные приоритеты и независимо спланированную работу. Реализация, которую одна кросс-функциональная команда могла бы завершить за несколько дней, растягивается на недели межкомандной координации и ожидания в очередях — не из-за сложности самой фичи, а из-за структуры команд, требующей передачи работы между разными компонентными командами.
При масштабировании Scrum именно структура команд определяет, будет ли координация лёгкой или мучительной — фиче-команды, способные самостоятельно довести клиентскую ценность до конца, устраняют межкомандные зависимости, тогда как компонентные команды, владеющие только отдельным техническим слоем, систематически создают их.
Происхождение и исследовательская база
LeSS разработан Крэйгом Ларманом и Басом Водде на основе многолетнего опыта масштабирования Scrum в крупных организациях, систематизирован в книгах «Large-Scale Scrum: More with LeSS» (2016) — центральная философия LeSS в минимализме: не добавлять новые роли и процессы для координации (как это делают многие альтернативные фреймворки), а последовательно применять принципы Scrum и убирать структурные причины сложности, прежде всего — организацию команд вокруг технических компонентов вместо клиентских фич.
Ключевые идеи и принципы
Принцип: Фиче-команды вместо компонентных команд
Фиче-команда кросс-функциональна и кросс-компонентна — обладает всеми необходимыми навыками для самостоятельной реализации клиентской функции от начала до конца, не завися от других команд; компонентная команда владеет только отдельным техническим слоем и вынуждена координироваться с другими компонентными командами для реализации любой сквозной функции — именно это структурное решение определяет большую часть межкомандных задержек при масштабировании.
Принцип: Один бэклог, один владелец продукта, один спринт на все команды
В отличие от подходов, вводящих дополнительные уровни иерархии бэклогов и владельцев продукта для каждой команды, LeSS сохраняет единый бэклог продукта и единого владельца продукта для всех команд, работающих над продуктом, а также единый синхронизированный спринт — это минимизирует структурную сложность координации вместо добавления новых координационных ролей.
Принцип: Минимализм — «больше с меньшим» (More with LeSS)
При столкновении со сложностью координации LeSS предпочитает убирать структурные причины сложности (например, реорганизовать компонентные команды в фиче-команды), а не добавлять новые процессы, роли или уровни управления для управления этой сложностью — философия минимализма противопоставляется более тяжеловесным фреймворкам, добавляющим дополнительную инфраструктуру координации.
Ограничения, слепые зоны и критика
Переход от компонентных к фиче-командам требует значительного обучения и перекрёстного развития навыков сотрудников, специализировавшихся на отдельных технических компонентах, что является длительным и не всегда простым организационным изменением. LeSS также требует высокой организационной зрелости для работы с единым бэклогом и минимальной координационной инфраструктурой — в организациях с недостаточной дисциплиной единый бэклог для множества команд может стать узким местом без дополнительной структуры.
Типовые ошибки
Ошибка 1: Команды продолжают формироваться вокруг технических компонентов вместо клиентских фич.
Компания декларирует переход на LeSS, но сохраняет прежнюю структуру команд по техническим слоям, из-за чего межкомандные зависимости и задержки, характерные для компонентных команд, никуда не исчезают.
Как избежать: Последовательно переформировывать команды в кросс-функциональные фиче-команды, способные самостоятельно доводить клиентскую ценность до конца.
Ошибка 2: При росте сложности координации добавляются новые процессы и роли вместо устранения структурных причин.
Организация реагирует на растущую сложность координации между командами добавлением новых координационных ролей и процессов, вместо того чтобы пересмотреть структуру команд и убрать источник сложности — компонентную организацию.
Как избежать: Следовать философии минимализма LeSS — искать и устранять структурные причины сложности координации, а не наращивать процессную надстройку поверх них.
Главное, что нужно знать
LeSS масштабирует Scrum минималистично, сохраняя единый бэклог продукта, владельца продукта и спринт на все команды, при этом настойчиво предпочитая кросс-функциональные фиче-команды компонентным — именно структура команд вокруг фич, а не вокруг технических слоёв, устраняет большую часть межкомандных зависимостей при масштабировании. Философия LeSS — убирать структурные причины сложности, а не наращивать процессную инфраструктуру для управления ею.
План внедрения
Неделя 1: провести аудит текущей структуры команд — фиче-команды или компонентные.
Неделя 2: определить план поэтапного перехода компонентных команд в кросс-функциональные фиче-команды.
Неделя 3: организовать единый бэклог продукта и единого владельца продукта для всех команд.
Неделя 4: синхронизировать спринты всех команд на единый общий ритм.
Далее: регулярно отслеживать долю фиче-команд и устранять оставшиеся источники межкомандных зависимостей.
Книги по теме
Larman C., Vodde B. — «Large-Scale Scrum: More with LeSS» (2016). Основополагающая работа по методологии LeSS.