Гибкие методологии и их модели управления хорошо зарекомендовали себя в небольших командах и стартапах. Ведь построить горизонтальную команду из небольшой группы людей куда проще, чем на тех же принципах наладить работу крупной организации.
Однако с ростом компаний и увеличением штата начинаются сложности. В основе гибких методологий лежит распределение ответственности, а в больших командах с этим уже сложнее. Как правило, крупные коллективы переходят от гибких методологий к директивным и вертикальным схемам работы. Самоорганизованные команды превращаются в простых исполнителей, а сама суть теряется.
Как же быть, если команду нужно наращивать, а терять гибкость не хочется? Ответ прост: гибких подход следует масштабировать.
Это не значит, что стоит пытаться на тех же началах организовать работу уже десятков и сотен сотрудников. Планерка на 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.
