LeSS — Scrum на больших масштабах
LeSS — это Scrum, применяемый к множеству команд, работающих совместно над одним продуктом.

Тема работоспособности и, вообще, возможности применения Agile в больших масштабах не дает покоя отрасли разработки программного обеспечения последний десяток лет. Появилось большое количество подходов таких как Scaled Agile Framework, Disciplined Agile Delivery, Nexus, примитивный Scrum-of-Scrums и т.п. Все они либо сложны, поэтому применение их очень затруднительно и часто не дает ожидаемых результатов, либо настолько просты, что решают лишь частные проблемы в ограниченном количестве кейсов.
Хочется найти какую-то золотую середину, что-то «элегантное», такое же «элегантное», простое и провоцирующее к развитию продукта, процессов и команд, как Scrum.
И вот оно свершилось. Встречайте Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших масштабах. LeSS — это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом.
С этого момента мы начинаем серию статей о подходе Large-Scale Scrum и о том, как он применяется в реальных компаниях. Начнем мы с простого — рассмотрим, из чего состоит LeSS в целом и его особенности.
Коротко о LeSS
LeSS — это Скрам. Скрам на больших масштабах (LeSS, Large-Scale Scrum) — это не новый или улучшенный Скрам. И это не разделение на «Скрам на уровне каждой команды» и «что-то другое на уровне выше». Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Scrum или любой другой настоящий Agile-фреймворк, LeSS является «минимально достаточным подходом» для максимальной отдачи.
Скрам на больших масштабах — это не специальный фреймворк расширения, работающий только на уровне команд. По-настоящему масштабированный Скрам — это тот же Скрам, но работающий на большем масштабе.
В LeSS основная часть команд — это кросс-функциональные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и разработки до снятия продуктовых метрик) для создания полноценного рабочего продукта.
Эти команды работают вместе над одним Бэклогом Продукта, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является не компонентной, а продуктовой командой (feature-team), и отвечает за end-to-end продукт, а не только за его отдельную часть.
Что представляет собой продукт в LeSS? Это полноценное (end-to-end), клиенториентированное решение, которое будет использоваться реальными людьми. Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или библиотека.
LeSS — это не просто процессный фреймворк. LeSS включает в себя:
- фундаментальные принципы, формирующие основу для других элементов LeSS;
- два процессных фреймворка;
- руководства по запуску LeSS в компании;
- реальные эксперименты в компаниях, которые привели к созданию LeSS.
Скрам на больших масштабах состоит из двух фреймворков:
- LeSS — от 2 до 8 команд;
- LeSS Huge — 8+ команд.
LeSS
Обычный LeSS-фреймворк предполагает наличие одного (и только одного) Владельца Продукта, который владеет продуктом, оптимизируя продукт в целом, и управляет одним Бэклогом Продукта, над которым работают команды в рамках общего для всех Спринта. Элементы LeSS-фреймворка практически идентичны элементам Скрам для одной команды, только применяются уже не к одной команде, а к «команде команд».
LeSS Huge
В какой-то момент, когда один Владелец Продукта более не может держать в голове полный контекст, у него не получается соблюдать баланс между внутренними и внешними коммуникациями, а Бэклог Продукта разрастается настолько, что один человек более не способен с ним справляться. Это сигнал для перехода от обычного LeSS к LeSS Huge.
В LeSS Huge по-прежнему есть один владелец Продукта, но у него есть команда помощников (Area Product Owners). В LeSS Huge работа над продуктом разделяется по Областям Требований (Requirement Areas). Область требований — это не компонент продукта, а определённая группа end-to-end функционала продукта с точки зрения клиента, то есть каждый элемент Бэклога Области Требований (Area Backlog) несет конечную ценность для клиента. Работа над Requirement Area осуществляется Area Product Owner и от 3-х до 8-ми команд.
Вот в целом как выглядит LeSS, но, конечно же, под капотом много нюансов: как плавно запустить LeSS, какие изменения необходимы в организации, как происходит распределение команд, как плавно перейти к feature-team, как определить, что является продуктом в вашей компании? Об этом всем читайте в наших следующих статьях.
Приходите на наш тренинг
Certified Large-Scale Scrum Practitioner
29-31 мая 2017 г.
Курс проводят 2 ведущих специалиста по LeSS:
- Ran Nyman — сертифицированный LeSS-тренер, специализируется на поддержке изменений в крупных транснациональных компаниях;
- Алексей Воронин — сертифицированный тренер консорциумом ICAgile.
Полезные материалы (на английском):
- Large-Scale Scrum: More with LeSS — самая свежая книга о LeSS, содержит полное описание фреймворка и руководства по запуску LeSS в организациях.
- Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum — в этой книге создатели LeSS (Craig Larman и Bas Vodde) делятся сотнями реальных экспериментов, которые они провели в компаниях, и результаты которых привели к созданию LeSS.
Помимо этих книг, рекомендую сайт less.works, который содержит подробное описание подхода LeSS и кейсов его реализации в различных компаниях.

Как масштабировать разработку при отсутствии кросс-функциональности? Рассмотрим несколько реальных примеров.

Типовой шаблон Kanban Программы, позволяющий оптимизировать полный жизненный цикл крупных инициатив, от известного эксперта SAFe (Scaled Agile Framework) Марка Ричардса.

Ключевая компетенция организации, без развития которой масштабирование Agile обречено на провал.