Agile и его модели управления хорошо зарекомендовали себя в небольших командах и стартапах. Ведь построить горизонтальную команду из небольшой группы людей куда проще, чем на тех же принципах наладить работу крупной организации.
Однако с ростом компаний и увеличением штата начинаются сложности. В основе гибких методологий лежит распределение ответственности, а в больших командах с этим уже сложнее. Как правило, крупные коллективы переходят от Agile к директивным и вертикальным схемам работы. Самоорганизованные команды превращаются в простых исполнителей, а сама суть Agile теряется.
Как же быть, если команду нужно наращивать, а терять гибкость не хочется? Ответ прост: Agile следует масштабировать.
Это не значит, что стоит пытаться на тех же началах организовать работу уже десятков и сотен сотрудников. Стендап на 150 человек — это не масштабирование Agile, а трата времени. Работать в том же формате с увеличенной командой не получится.Масштабирование Agile предполагает организацию взаимодействия между продуктовыми командами. Они сохраняют свою продуктивность, но действуют как одно целое уже в больших масштабах.
В этой статье мы поговорим о нескольких фреймворках, которые помогают перенести принципы Agile на работу более крупных коллективов и построить взаимодействие между несколькими командами.
Scrum of Scrums
Самый простой и сравнительно популярный фреймворк — Scrum of Scrums (SoS). Как можно догадаться по названию, он предполагает кооперацию нескольких Scrum-команд.
Но для начала освежим в памяти несколько фактов. Во-первых, держим в уме, что количество участников Scrum-команды не должно превышать 10 человек. Во-вторых, состав ее следующий:
- Scrum-мастер;
- владелец продукта;
- разработчики.
Для применения Scrum of Scrums нужно разбивать эти единицы на более автономные. Структурировать команды можно несколькими способами.
Способ первый. Подходит, если в компании трудится несколько независимых Scrum-команд над разными продуктами. Достаточно будет выделить владельцев продукта из каждой — их собрание и будет отвечать за общую стратегию и координацию между разработчиками из разных команд.
Способ второй. Предположим, несколько Scrum-команд в компании работают над одним сложным продуктом. Например, CRM-системой, состоящей из множества разных модулей. Разработчики не успевают, командам не хватает согласованности — отсутствие кооперации оборачивается повторными проверками, двойной работой и долгим рефакторингом кода. Scrum of Scrums предлагает раздробить и пересобрать все команды:
- Разработчики со всех команд объединяются, а затем дробятся на автономные единицы по 1-3 человека во главе с опытным коллегой-наставником. Ключевой признак — компетенции группы.
- На всех разработчиков будет достаточно 1-2 Scrum-мастеров.
- Владельцы продукта также собираются в небольшую отдельную команду для решения операционных вопросов.
Scrum of Scrums может использоваться как отдельный инструмент организации рабочего процесса в более сложных фреймворках масштабирования Agile.
Кроме того, его можно масштабировать до более высоких уровней во фреймворк Scrum@Scale. Он предполагает создание целой экосистемы из множества команд на основе Scrum of Scrums.
LeSS
LeSS (сокращение от Large Scale Scrum — Scrum в крупных масштабах) — это методика применения принципов Scrum в крупных проектах или нескольких Scrum-командах одновременно. В общих чертах LeSS предполагает частичное сращение команд.
У LeSS есть 2 варианта реализации — классический LeSS и LeSS Huge.
LeSS классический
Стандартный LeSS подходит для организаций, где над одним продуктом совместно трудится от 2 до 8 команд. Однако в отличие от SoS, LeSS предполагает, что у всех Scrum-команд будут общие:
- владелец продукта;
- бэклог с задачами;
- спринты;
- мероприятия по планированию и обзору спринтов.
В остальном принципы Scrum применяются как обычно: команды работают по Scrum в том же режиме, но отчитываются одному владельцу продукта.
LeSS Huge
Приставка Huge (огромный, гигантский) говорит о масштабе применения методики. LeSS Huge помогает организовать работу коллективов, численность которых может достигать 100 человек, разбитых на 8 и более команд.
В LeSS Huge речь также идет о группе команд с одним владельцем продукта. При этом в силу масштаба вся работа делится на области требований (Requirement Areas). Это не конкретные части продукта, а скорее направления, по которым группируется функционал продукта.
Вернемся к примеру с разработчиками CRM-системы со множеством модулей. Допустим, одна часть ее модулей связана с управлением финансами, а другая — с управлением проектами. Получается следующая картина:
- Финансы и проекты — это области требований.
- По областям требований разбивается бэклог.
- Одна область может распределиться между несколькими командами, каждая из которых работает над конкретным модулем.
В помощь владельцу продукта также создается команда помощников — Area Product Owners, дословно «владельцы области продукта». За каждым из APO закрепляется своя область.
Модель Spotify
Довольно замысловатую структуру продуктовых команд реализовали разработчики музыкального сервиса Spotify. От компании модель и получила свое название.
Она уже значительно отступает от Scrum, но использует некоторые его элементы в своей основе. Структура команды представлена в виде матрицы и делится на следующие элементы:
Клан (tribe) — это группа в 100-200 разработчиков, задействованных в работе над конкретным продуктом или проектом. Основная единица в модели Spotify. Именно клан и превращен матрицу.
Отряд (squad) — самоорганизующаяся кросс-функциональная команда, аналог Scrum-команды. В отряде задействованы разные специалисты. Например, фронтендер, UX-дизайнер и копирайтер. Они реализуют новый функционал.
Отдел (chapter) — функциональная группа, которая контролирует работу конкретных специалистов из разных команд. Например, отдел фронтенда, отдел UX-дизайна, отдел копирайтинга и т.д.
Отделы существуют параллельно отрядам, но решают общие организационные вопросы и отвечают за обмен знаниями и применение инструментов внутри конкретных проектов компании или кланов. Например, решает, какой стек используют фронтендеры, создают редполитику и Tone of Voice для копирайтеров.
Аналогичные операционные вопросы в рамках всей компании или нескольких структурных подразделений решают схожие единицы — гильдии (guilds).
Кроме того, в компании могут существовать и другие структуры более высоких уровней. Например, за кооперацию разработчиков разных продуктов, которые как-то связаны между собой, могут отвечать бизнес-юниты (business units).
Таким образом, один разработчик может принадлежать сразу к нескольким разным коллективам внутри одной компании.
Конкретных требований к дроблению рабочего коллектива, количеству уровней или названиям единиц, не существует. Разработчики Spotify сами отмечают, что дословно копировать их структуру на опыт других компаний бессмысленно — модель нужно адаптировать под свои бизнес-реалии.
SAFe
SAFe (сокращение от Scaled Agile Framework — «масштабированный фреймворк для Agile») — один из наиболее популярных организационных фреймворков для крупных компаний. Технически это целая платформа для построения организационных и рабочих процессов. SAFe реализует одновременно принципы бережливого производства и манифеста Agile-разработки.
Цель SAFe — создать из крупной организации гибкую систему, которая позволяет легко управлять разработкой нескольких разных продуктов или проектов, а также обеспечивать согласованное взаимодействие между разными Agile-командами.
Ключевые моменты SAFe:
- SAFe выстраивает многоуровневую иерархическую структуру, которая делится на уровни Портфеля, Программы и Команды. На каждом уровне есть свои роли, зоны ответственности и артефакты.
- Большое внимание в SAFe уделяется координации и синхронизации работы между командами и уровнями. Для этого проводятся регулярные мероприятия по планированию итерации, а на разных уровнях нередко используется упомянутый ранее Scrum of Scrums.
- SAFe также предоставляет набор методов для управления зависимостями между командами и уровнями проектов. Так сводятся к минимуму риски, связанные с интеграцией различных частей продукта.
- Во многом SAFe основан на сочетании принципов Lean и Agile — устранении потерь, регулярном сборе обратной связи, постоянном совершенствовании, а также гибкости в работе и планировании. SAFe поощряет и включение в рабочие процессы практик из Kanban и других гибких методологий с поправкой на масштабирование.
SAFe считается один из самых сложных фреймворков в реализации. Руководитель, который выстраивает работу компании по SAFe, должен непременно учитывать множество факторов и добиваться слаженности между разными командами и уровнями всей системы. При этом несостоятельность какой-либо части структуры может привести к тому, что SAFe просто не будет работать.
Enterprise Scrum
Майк Бидл, один из создателей манифеста Agile, в 2010-х работал над созданием своего фреймворка для масштабирования — Enterprise Scrum («Scrum для бизнеса»).
В основе Enterprise Scrum лежит идея перехода от разработки конкретного продукта к регулярной поставке ценности для пользователя, а уровень управления от одной команды переносится на бизнес в целом. Соответственно, роль владельца продукта превращается во владельца бизнеса (business owner).
Работу по Enterprise Scrum Бидл основывал на следующих принципах:
- Руководитель отслеживает не только производительность команды, а сразу множество метрик. Сколько и каких — владелец бизнеса решает сам. Важно отслеживать баланс и взаимосвязи между ними.
- Роль Scrum-мастера также превращается в роль коуча. Он следит не только за соблюдением ритуалов Scrum, но и за эмоциональным состоянием команды.
- Для работы над общими целями несколько Scrum-команд могут объединяться на основе Scrum of Scrums.
- Фреймворк поощряет эксперименты. Enterprise Scrum не запрещает добавлять в рабочие процессы различные практики из других методологий. Например, WIP-лимиты из Kanban.
- В основе разработки лежит не решение конкретных задач, а реализация пользовательских историй. Команды поставляют не просто продукт или его часть, а какую-либо ценность (business value).
Под ценностью можно понимать, например, функционал для приложения, который реализует конкретную потребность клиентов: заказ на несколько адресов одновременно в приложении для доставки еды или новый способ оплаты.
Увы, документация для Enterprise Scrum так и не была полностью закончена. В 2018-м Майк Бидл умер. Поэтому фреймворк не нашел широкого распространения и в полном виде практически не используется.
Итоги
Ни один фреймворк, каким бы простым, сложным или эффективным он не был — не панацея. Прежде чем выбирать, какой-либо способ организации рабочих процессов, важно тщательно проанализировать, в каком состоянии находится компания и готова ли она вообще масштабироваться.
Помните, что важны не правила и фреймворки, а люди и взаимодействие между ними. Ну а организовать работу команды, будь это автономная единица или часть крупной компании, вам поможет Аспро.Agile.
