Как масштабировать Agile: с чего начинать на нескольких командах

Проверьте, та ли это задача

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

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

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

Состав команд

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

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

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

Ожидайте просадки на два-три цикла. Новые команды заново вырабатывают договорённости, и это нормальная цена.

Один список приоритетов

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

Решение простое по формулировке и трудное политически: один владелец приоритетов на продукт и один упорядоченный список. Бэклоги команд наполняются из него.

Если продукт слишком велик для одного человека, его делят на области с явными границами. Важно, чтобы у каждой области был свой единственный владелец приоритетов; комитет в этой роли не работает.

Единое определение готовности

Самый дешёвый из крупных шагов. Команды договариваются, что считается завершённым: собрано, протестировано, интегрировано, задокументировано.

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

Договорённость записывают одним списком и вешают рядом с досками всех команд.

Общий ритм

Зависимым командам нужны циклы одинаковой длины с одинаковыми датами начала. Тогда договорённость «сделаем в следующем цикле» означает у всех одно и то же.

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

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

Где здесь фреймворки

Готовые наборы правил отвечают на те же вопросы, что перечислены выше, только в разном объёме. Nexus добавляет к Scrum минимум механики для трёх-девяти команд. LeSS настаивает на одном бэклоге и одном определении готовности, требуя серьёзных организационных изменений. SAFe даёт подробную конструкцию с ролями координации и планированием на восемь-двенадцать недель.

Выбирать удобнее после того, как сделаны первые шаги: тогда понятно, какого объёма правил вам не хватает. Фреймворк, внедрённый до разговора о составе команд, добавляет событий и оставляет зависимости на месте.

Порядок шагов и их цена

Готовность к масштабированию

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

Что настроить в Shtab

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

Частые вопросы