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

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

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

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

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

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

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

Итеративный метод в квадрате (Scrum of Scrums)

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

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

• фасилитатор (scrum master);
• владелец продукта;
• разработчики.

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

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

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

• Разработчики со всех команд объединяются, а затем дробятся на автономные единицы по 1-3 человека во главе с опытным коллегой-наставником. Ключевой признак — компетенции группы.
• На всех разработчиков будет достаточно 1-2 фасилитаторов.
• Владельцы продукта также собираются в небольшую отдельную команду для решения операционных вопросов.

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

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

Итеративный метод для крупных компаний (LeSS)

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

У метода есть 2 варианта реализации — классический и метод дляочень крупных компаний(LeSS и LeSS Huge).

Классический ИМКК (LeSS)

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

• владелец продукта;
• список задач;
• спринты;
• мероприятия по планированию и обзору спринтов.

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

ИМКК для очень крупных компаний (LeSS Huge)

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

В ИМКК для очень крупных компаний речь также идет о группе команд с одним владельцем продукта. При этом в силу масштаба вся работа делится на области требований (requirement areas). Это не конкретные части продукта, а скорее направления, по которым группируется функционал продукта.

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

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

В помощь владельцу продукта также создается команда помощников — владельцы области продукта**(****Area Product Owners)**. За каждым из ВОП закрепляется своя область.

Модель Spotify

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

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

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

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

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

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

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

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

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

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

Масштабируемая гибкая модель (SAFe)

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

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

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

• МГМ (SAFe) выстраивает многоуровневую иерархическую структуру , которая делится на уровни Портфеля , Программы и Команды. На каждом уровне есть свои роли, зоны ответственности и артефакты.
• Большое внимание в МГМ уделяется координации и синхронизации работы между командами и уровнями. Для этого проводятся регулярные мероприятия по планированию итерации, а на разных уровнях нередко использует упомянутый ранее ИМК.
• МГМ также предоставляет набор методов для управления зависимостями между командами и уровнями проектов. Так сводятся к минимуму риски, связанные с интеграцией различных частей продукта.
• Во многом МГМ основан на сочетании принципов бережливого производства**(**Lean) и гибких методологий****Agile — устранении потерь, регулярном сборе обратной связи, постоянном совершенствовании, а также гибкости в работе и планировании. МГМ поощряет и включение в рабочие процессы практик из Канбана и других гибких методологий с поправкой на масштабирование.

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

Итерационная модель для бизнеса (Enterprise Scrum)

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

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

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

• Руководитель отслеживает не только производительность команды, а сразу множество метрик. Сколько и каких — владелец бизнеса решает сам. Важно отслеживать баланс и взаимосвязи между ними.
• Роль фасилитатора также превращается в роль наставника. Он следит не только за соблюдением ритуалов итерационного метода, но и за эмоциональным состоянием команды.
• Для работы над общими целями несколько команд могут объединяться на основе ИМК.
• Модель поощряет эксперименты. ИМБ не запрещает добавлять в рабочие процессы различные практики из других методологий. Например, WIP-лимиты из Канбана.
• В основе разработки лежит не решение конкретных задач, а реализация пользовательских историй. Команды поставляют не просто продукт или его часть, а какую-либо ценность (business value).

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

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

Итоги

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

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