Фреймворк LeSS — Scrum для крупных компаний

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

Неужели нужно переходить на новую методику управления продуктом? Хорошая новость — нет, можно попробовать LeSS. В этой статье разберем, чем этот инструмент отличается от Scrum и других Agile-методик и как внедрить его в крупную компанию.

Подготовить этот материал нам помог Илья Павличенко — единственный LeSS-тренер в России, профессиональный Scrum- и Nexus-тренер, соавтор книги «Creating Agile Organizations». Он помогает крупным компаниям подбирать необходимую методику управления продуктом и грамотно использовать ее для повышения результативности компании.

Что такое LeSS

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

Цель LeSS — создать высокоадаптивные команды, которые смогут фокусироваться на самом важном для бизнеса.

Адаптивность — возможность дешево и быстро сменить направление разработки. Представьте, 10 команд из 10 человек разрабатывают продукт. Требования рынка резко меняются, и необходимо перестроить планы, чтобы продукт не потерял актуальность. Чем быстрее и дешевле команды могут перестроиться, чтобы работать над самым важным, тем они адаптивнее.

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

💡
Под продуктовой организацией подразумевается не компания в целом, а те команды, которые отвечают за производство продукта. Например, Kaiten производит один продукт, поэтому вся компания является одной продуктовой организацией. А, например, банкам часто принадлежат разные виды бизнесов, и каждый из них является отдельной продуктовой организацией.

Виды LeSS

У LeSS есть два вида:

  • LeSS — предназначен для 2–8 команд (10–50 человек),
  • LeSS Huge — 8 и более команд (от 50 человек).

Виды немного отличаются планированием спринтов и составом команд, но суть фреймворков одинаковая. Сначала разберем общие правила LeSS, а затем поясним особенности LeSS Huge.

Поделитесь своим опытом работы в Kaiten
Если хотите рассказать о своем кейсе, управленческом опыте или стать соавтором статьи, напишите нашему редактору d.lebedeva@kaiten.io

Правила LeSS

Мы опишем 5 самых важных правил для LeSS. Прочитать все вы можете на сайте.

Правило 1. Большинство команд должно быть кросс-функциональными (еще их называют фиче-командами). Команды в Scrum и LeSS обладают всеми необходимыми компетенциями продуктовой команды (feature-team). Они должны выполнять весь спектр задач по созданию продукта от разработки пользовательских интерфейсов и кода до анализа продуктовых метрик.

Правило 2. Только один Бэклог Продукта и только один Product Owner. Неважно сколько команд — 7 или 20. Благодаря этому все фокусируются на одном продукте, а Владелец Продукта задает направление развития продукта.

Правило 3. Команды не должны специализироваться на конкретной части продукта, а видеть его целиком. Крупные компании часто разделяют один продукт на несколько маленьких продуктов и плодят Scrum-команды с локальными Владельцами Продуктов. Из-за этого:

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

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

Попробуйте Kaiten – профессиональный инструмент для работы по Scrum и LeSS

Попробовать бесплатно

10 принципов LeSS

Источник: less.works

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

1. В основе Large Scale Scrum лежит Scrum
LeSS — это не улучшенная версия Scrum, а лишь минимальный набор дополнительных правил, которые помогают масштабировать эту Agile-методику на крупный продукт.

2. Эмпирический контроль процессов
Решения принимаются только на основе предыдущего опыта и полученных данных.

3. Прозрачность
Информация должна быть доступна для всех сотрудников и отображать реальное положение дел, без искажений.

4. Фокус на всем продукте
Один Бэклог Продукта, один Владелец Продукта, один спринт и один инкремент. Неважно, сколько команд участвует в разработке продукта, они все должны двигаться в сторону одного интегрированного инкремента. Клиентам нужен продукт целиком, а не отдельные его части.

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

5. Клиентоориентированность
За продукт платят клиенты, поэтому и разрабатываться он должен с учетом их потребностей. Прислушивайтесь к обратной связи от потребителей и создавайте только то, что действительно нужно клиентам. Сама структура организации должна создаваться так, чтобы удовлетворять потребителей. Формируются фиче-команды, которые закрывают конкретные потребности клиентов.

6. Бережливое мышление
Бережливое мышление — это подход, основанный на концепции непрерывного улучшения, оптимизации эффективности потока создания ценности, уважении сотрудников, менеджерах-учителях.

7. Бесконечное движение к совершенству
Внедрить LeSS очень сложно, особенно когда в компании команды были сильно изолированы друг от друга: у каждой был свой Владелец Продукта, цели и зоны ответственности. Нужно постепенно приводить разрозненные команды к одному Бэклогу Продукта и улучшать процессы.

8. Лучшие результаты меньшими усилиями
LeSS минималистичен. У него мало правил, ролей и артефактов. Благодаря своей простоте он помогает достигать больших результатов.

9. Системное мышление
Необходимо видеть и оптимизировать систему целиком, а не отдельные ее части. Избегайте локальной оптимизации работы сотрудников или команд.

10. Теория массового обслуживания
Теория массового обслуживания исследует поведение очередей и их экономические последствия для масштабной продуктовой разработки.

Поставлять продукт заказчику или потребителю нужно как можно быстрее. Однако ускорять работу нужно не за счет переработок и снижения качества товара, а за счет устранения препятствий и ненужной работы.

💡
Очередь — список задач или функций для команды, которые они должны выполнить. На рабочей доске задачи визуализированы с помощью карточек. От того, как настроена система взятия карточек в работу, установлены правила составления ТЗ и сдачи проекта, зависит скорость поставки.

👉 Процесс пополнения очереди. Как планировать то, что принесет пользу бизнесу

💡
Теория массового обслуживания — это математическое исследование очередей, которое предсказывает последствия появления новых задач. То есть, когда задача попадает в очередь, должно быть понятно, когда ее возьмут в работу, как быстро ее выполнят и не отвлечет ли она работников от других дел. Цель теории массового обслуживания — не дать сотрудникам перегружаться. Рабочий поток должен быть предсказуемым и сбалансированным. Только в этом случае сотрудники могут фокусироваться на одной задаче и выполнять ее максимально быстро и качественно.

Как происходит планирование спринта в LeSS и чем оно отличается от Scrum

Бэклог Продукта в LeSS глобально ничем не отличается от Scrum. Единственное, планирование спринта в LeSS состоит из 2 этапов:

Этап 1. Это общее планирование спринта для всех команд, работающих над продуктом. На этой встрече не обязательно должны присутствовать все разработчики команд. Достаточно представителей и Владельца Продукта.

На этой встрече нужно:

  1. Сформулировать цель спринта.
  2. Найти возможности для координации команд.
  3. Выбрать задачи из Бэклога Продукта, которые необходимо взять в спринт.  

Этап 2. Участники первого этапа планирования должны передать команде результаты встречи. После этого каждая фиче-команда создает бэклог задач на ближайший спринт.

Также в LeSS очень важен вопрос фасилитации. Необходимо наладить межкомандное взаимодействие. Идеи и возражения всех команд должны быть учтены.

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

Как организована работа в LeSS Huge

LeSS и LeSS Huge отличаются тем, что во втором появляется специализации команд вокруг областей требований и дополнительная роль Владельца Продукта области.

Даже при условии, что команды сами уточняют нюансы каждой задачи, Владелец Продукта не может быть экспертом во всех частях продукта. Поэтому в рамках LeSS Huge у него есть помощники — Area Product Owner (APO).

Area Product Owner специализируются в какой-либо ориентированной на клиента области (в области не менее 4-х команд) и действует как Владелец Продукта по отношению к командам для этой области. APO выполняет те же функции, что и Владелец Продукта в LeSS, но находится в постоянном контакте с Владельцем Продукта.

Владелец Продукта и несколько Area Product Owner образуют команду Владельца Продукта. Когда Владелец Продукта видит, что конкретные команды перегружены, он перераспределяет ресурсы и перебрасывает команды из одной области продукта в другую.

Кому подходит LeSS, а кому — SAFe

👉Подкаст. SAFe 6.0 и 8 практик ускорения потока

Параметры

LeSS

SAFe

Цель

Адаптивность команд и

высокая ценность для клиента.

Легкий старт и повышение качества работы.

Работа с зависимостями

Устранение зависимостей за счет создания кросс-функциональных команд.


Зависимостей между командами в продуктовой организации почти нет или они минимальны.

Возможно только частичное устранение зависимостей за счет оптимизации оргструктуры компании. 


Управление зависимостями чаще происходит вручную на встречах команд.  


Фокусирование на общих бизнес-целях. Организация Бэклога Продукта

Есть один продуктовый бэклог на все команды и один Владелец Продукта. Это обеспечивает полную синхронизацию всех команд, работающих над проектом.


Встреча по планированию бэклога раз в пару недель или в месяц помогает всем командам планировать общие цели и задачи.

Синхронизация команд происходит раз в квартал на встрече (Pi Planning), в которой участвуют все команды и стейкхолдеры.


Также есть встреча PO Sync, где общаются только Владельцы Продуктов.


То есть команды встречаются довольно редко. Риск, что цели рабочих групп будут сильно отличаться, выше, чем у LeSS. 


Прозрачность результатов

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

В конце каждого спринта команды проводят System Demo. На этой встрече каждая команда показывает, что она сделала для достижения общей цели. 


Проблема в том, что команда может намерено преподнести информацию так, как будто она внесла вклад в общий результат, но на самом деле ситуация может быть обратная.


Также команда может выбрать неправильный путь (к примеру, не синхронизироваться с другими командами) и тем самым выполнит задачи, которые не принесут пользу бизнесу.

SAFe очень популярен в крупных компаниях, так как его проще внедрить и он не требует радикального изменения организационной структуры. У каждой команды есть свои Бэклоги Продуктов, привычная иерархия команд и руководителей. Да, эта методика поможет оптимизировать некоторые рабочие процессы и немного синхронизировать команды, чтобы они двигались к единой цели. Однако высокой адаптивности команд не достичь, так как они всё равно изолированы друг от друга, специализируются на разных частях продукта и обсуждают общие цели только раз в квартал.

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

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

SAFe подходит компаниям, которые работают в низкоконкурентной среде, или зрелым бизнесам (Product Market Fit). Таким компаниям необходимо только ускорить поставку продуктов, а высокая адаптивность не нужна. За счет того, что в SAFe есть несколько бэклогов, а планирование происходит 1 раз в квартал, командам не нужно сильно меняться, следовательно, внедрение новой системы пройдет не так травматично для бизнеса, как переход на LeSS.

Как внедрить LeSS: 6 шагов

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

Шаг 1. Получить поддержку топ-менеджеров. Так как в командах придется сделать масштабные изменения организационной структуры, поддержка топ-менеджеров просто необходима.

Шаг 2. Обучить топ-менеджеров и поменять их мышление. Руководители должны понимать, что ждет их компанию и какая помощь с их стороны нужна. Прежде чем идти к сотрудникам, начните с обучения руководства.

Шаг 3. Заручиться поддержкой команд. Работать в новой системе будут сами участники команд. Им придется много учиться, так как обычно они ничего не знают о других частях продукта. Переход на LeSS для них будет стрессом.

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

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

Шаг 4. Подготовиться к переходу на LeSS. Это может занимать 3–4 месяца. В это время нужно обучить сотрудников (рассказать не только о LeSS, но и научить команду декомпозировать задачи, рассказать про пользовательские истории и другое), изменить HR-политики, создать Бэклог Продукта и выполнить много других подготовительных активностей.

* Шаг 5. (для Basic LeSS). Моментально перейти на новую систему. Поведение людей изменяется только после изменения системы. Постепенно перейти на LeSS не получится.  Если делать все постепенно, высок риск откатиться назад. Команда должна сразу начать работать с новым Бэклогом Продукта и общим Владельцем Продукта.

Если вы работаете с LeSS Huge, перевести всех на новую систему одномоментно не получится. Изменений будет слишком много, из-за чего может не хватить Scrum-мастеров и агентов изменений. В этом случае переходить на ​​LeSS нужно небольшими группами (лучше не более 50 человек).

Шаг 6. Поддерживать результат. Еще полгода команды будут привыкать к новым реалиям, задавать вопросы и делать ошибки. Только после этого периода можно ждать от команды эффективности. Чем меньше команд, тем быстрее они адаптируются и наладят процессы. Запаситесь терпением и поддерживайте сотрудников, отвечайте на их вопросы.

Совет напоследок

Прежде чем внедрять тот или иной фреймворк масштабирования, определите, какие организационные способности вы хотите развить. В зависимости от вашей цели станет понятно, какой организационный дизайн (LeSS, SAFe, Nexus или другой) вам выбрать.

Часто менеджеры приходят к Agile-тренерам и просят внедрить конкретный фреймворк, не понимая, подойдет ли он компании. Нужно мыслить системно: делать анализ разных фреймворков, изучать потребности своего бизнеса и только потом решать, какой инструмент использовать.

Kaiten поможет выстроить прозрачный рабочий процесс в команде и в организации. Попробуйте модуль для работы по Scrum бесплатно

Попробовать