Играем по-крупному: фреймворки для масштабирования Agile

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

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

Как же быть, если команду нужно наращивать, а терять гибкость не хочется? Ответ прост: Agile следует масштабировать.

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

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

Содержание:

Самый простой и сравнительно популярный фреймворк — Scrum of Scrums (SoS). Как можно догадаться по названию, он предполагает кооперацию нескольких Scrum-команд.

Но для начала освежим в памяти несколько фактов. Во-первых, держим в уме, что количество участников Scrum-команды не должно превышать 10 человек. Во-вторых, состав ее следующий:

Для применения Scrum of Scrums нужно разбивать эти единицы на более автономные. Структурировать команды можно несколькими способами.

Способ первый. Подходит, если в компании трудится несколько независимых Scrum-команд над разными продуктами. Достаточно будет выделить владельцев продукта из каждой — их собрание и будет отвечать за общую стратегию и координацию между разработчиками из разных команд.

Способ второй. Предположим, несколько Scrum-команд в компании работают над одним сложным продуктом. Например, CRM-системой, состоящей из множества разных модулей. Разработчики не успевают, командам не хватает согласованности — отсутствие кооперации оборачивается повторными проверками, двойной работой и долгим рефакторингом кода. Scrum of Scrums предлагает раздробить и пересобрать все команды:

Scrum of Scrums может использоваться как отдельный инструмент организации рабочего процесса в более сложных фреймворках масштабирования Agile.

Кроме того, его можно масштабировать до более высоких уровней во фреймворк Scrum@Scale. Он предполагает создание целой экосистемы из множества команд на основе Scrum of Scrums.

LeSS (сокращение от Large Scale Scrum — Scrum в крупных масштабах) — это методика применения принципов Scrum в крупных проектах или нескольких Scrum-командах одновременно. В общих чертах LeSS предполагает частичное сращение команд.

У LeSS есть 2 варианта реализации — классический LeSS и LeSS Huge.

Стандартный LeSS подходит для организаций, где над одним продуктом совместно трудится от 2 до 8 команд. Однако в отличие от SoS, LeSS предполагает, что у всех Scrum-команд будут общие:

В остальном принципы Scrum применяются как обычно: команды работают по Scrum в том же режиме, но отчитываются одному владельцу продукта.

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

В LeSS Huge речь также идет о группе команд с одним владельцем продукта. При этом в силу масштаба вся работа делится на области требований (Requirement Areas). Это не конкретные части продукта, а скорее направления, по которым группируется функционал продукта.

Вернемся к примеру с разработчиками CRM-системы со множеством модулей. Допустим, одна часть ее модулей связана с управлением финансами, а другая — с управлением проектами. Получается следующая картина:

В помощь владельцу продукта также создается команда помощников — Area Product Owners, дословно «владельцы области продукта». За каждым из APO закрепляется своя область.

Довольно замысловатую структуру продуктовых команд реализовали разработчики музыкального сервиса Spotify. От компании модель и получила свое название.

Она уже значительно отступает от Scrum, но использует некоторые его элементы в своей основе. Структура команды представлена в виде матрицы и делится на следующие элементы:

Клан (tribe) — это группа в 100-200 разработчиков, задействованных в работе над конкретным продуктом или проектом. Основная единица в модели Spotify. Именно клан и превращен матрицу.

Отряд (squad) — самоорганизующаяся кросс-функциональная команда, аналог Scrum-команды. В отряде задействованы разные специалисты. Например, фронтендер, UX-дизайнер и копирайтер. Они реализуют новый функционал.

Отдел (chapter) — функциональная группа, которая контролирует работу конкретных специалистов из разных команд. Например, отдел фронтенда, отдел UX-дизайна, отдел копирайтинга и т.д.

Отделы существуют параллельно отрядам, но решают общие организационные вопросы и отвечают за обмен знаниями и применение инструментов внутри конкретных проектов компании или кланов. Например, решает, какой стек используют фронтендеры, создают редполитику и Tone of Voice для копирайтеров.

Аналогичные операционные вопросы в рамках всей компании или нескольких структурных подразделений решают схожие единицы — гильдии (guilds).

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

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

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

SAFe (сокращение от Scaled Agile Framework — «масштабированный фреймворк для Agile») — один из наиболее популярных организационных фреймворков для крупных компаний. Технически это целая платформа для построения организационных и рабочих процессов. SAFe реализует одновременно принципы бережливого производства и манифеста Agile-разработки.

Цель SAFe — создать из крупной организации гибкую систему, которая позволяет легко управлять разработкой нескольких разных продуктов или проектов, а также обеспечивать согласованное взаимодействие между разными Agile-командами.

Ключевые моменты SAFe:

Майк Бидл, один из создателей манифеста Agile, в 2010-х работал над созданием своего фреймворка для масштабирования — Enterprise Scrum («Scrum для бизнеса»).

В основе Enterprise Scrum лежит идея перехода от разработки конкретного продукта к регулярной поставке ценности для пользователя, а уровень управления от одной команды переносится на бизнес в целом. Соответственно, роль владельца продукта превращается во владельца бизнеса (business owner).

Работу по Enterprise Scrum Бидл основывал на следующих принципах:

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

Увы, документация для Enterprise Scrum так и не была полностью закончена. В 2018-м Майк Бидл умер. Поэтому фреймворк не нашел широкого распространения и в полном виде практически не используется.

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

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