Развитие — это не то же самое, что масштабирование
Доминик Прайс, статья Забудьте эти пять заблуждений и откройтесь инновациям
Попытка решить проблему, постоянно включая в процесс новых людей, только усложняет ситуацию. Но если по мере роста вы находите новые, более эффективные способы решения проблем, это называется масштабированием.
На протяжении нескольких десятилетий Руководство по scrum служило общим ориентиром, с помощью которого команды и компании решали такие проблемы. Однако когда scrum выходит за пределы отдельных команд, требуется иной подход. Для таких случаев была создана технология Scrum of Scrums, иногда называемая SoS.
История Scrum of scrums
Технология Scrum of Scrums была впервые применена в 1996 г. Джеффом Сазерлендом и Кеном Швабером, пионерами методики scrum. Сазерленду и Шваберу нужно было придумать, как координировать восемь бизнес-единиц, имеющих по несколько линеек продуктов, и синхронизировать работу отдельных команд. Для достижения этой цели они попытались масштабировать scrum-команды. Вдохновившись этим опытом, в 2001 г. Сазерленд опубликовал статью под названием «Масштабирование agile-подхода возможно: внедрение и переосмысление подхода SCRUM в пяти компаниях». В этом тексте и был впервые публично упомянут Scrum of Scrums.
С этого момента метод Scrum of Scrums стал набирать популярность в контексте agile-масштабирования. Он включен в Руководство Scrum@Scale, и на него ссылаются другие масштабируемые agile-платформы как на структуру, помогающую командам осуществлять масштабирование.
Если вам сложно справиться со Scrum на уровне отдельной команды, вы не сможете применить эту методику для группы команд. Перед тем как приступить к масштабированию, остановите все процессы и разрешите трудности, с которыми столкнулась ваша команда.
Что такое Scrum of scrums?
Scrum of Scrums — это масштабируемая agile-платформа, предлагающая способ объединения нескольких команд, которые должны работать вместе для поставки сложных решений.
С ее помощью команды разрабатывают и выпускают комплексные продукты, при любом масштабе опираясь на принципы прозрачности, контроля и адаптивности. Использование этой платформы особенно эффективно, когда высокопроизводительная команда scrum сообща и слаженно работает над общей целью с доверием и уважением ко всем участникам.
В этих условиях критичен размер команды. Согласно исследованиям Хэкмена и Видмара, теоретический «идеальный размер команды» составляет 4,6 человека. Слишком маленькие или слишком большие команды испытывают трудности при создании комплексных продуктов.
Помните закон Брука из книги «Мифический человеко-месяц»? Согласно этому закону, если проект по разработке ПО не укладывается в срок, добавление рабочей силы часто затягивает его еще больше.
Чем больше команда, тем сложнее каналы связи между ее участниками, что осложняет их взаимопонимание и работу над общей целью.
Поэтому разделение слишком большой команды на две или три небольших будет способствовать развитию более личных взаимоотношений и достижению желаемых результатов.
Разделять команды следует очень аккуратно! Необходимо выдержать баланс навыков в командах, перестроить сложившиеся способы взаимодействия и грамотно распределить рабочие обязанности. В этом процессе могут возникнуть неожиданные зависимости и новые узкие места, затрудняющие достижение результата. Преодолеть эти трудности поможет четкая фокусировка на ретроспективах и приоритетная работа над историями, направленными на улучшение.
При наличии нескольких команд, работающих на общий результат, необходима их координация. Это и послужило причиной создания Scrum of scrums.
Назначение Scrum of scrums
Scrum of Scrums — это виртуальная команда, состоящая из представителей исходных команд поставки, каждый из которых ссылается на свою команду. По сравнению с обычными организационными иерархиями или командами, созданными на основе проекта, командная структура с такой организацией взаимосвязей позволяет сократить пути коммуникации. Это обеспечивает координацию в небольших независимых командах. В командах, применяющих Scrum of Scrums, не только координируется процесс поставки, но и обеспечивается создание полностью интегрированного продукта в конце каждого спринта. Таким образом, команда Scrum of Scrums работает как команда по выпуску релизов и отвечает за поставку ценности клиентам.
Как правило, организации используют этот подход на первом этапе работы, чтобы осуществить agile-масштабирование и организовать поставку крупных и комплексных продуктов.
Scrum of scrums: масштабируемая структура
Вновь сформированная команда Scrum of Scrums применяет практически те же самые методы, участвует в тех же самых событиях и имеет те же самые роли, что и обычная scrum-команда. Чтобы в конце каждого спринта получать интегрированный и потенциально готовый к выпуску продукт, могут потребоваться дополнительные роли, например, архитектора или руководителя отдела контроля качества.
Например, есть роль главного владельца продукта. Главный владелец продукта курирует команду владельцев продукта и участвует в формировании общей концепции продукта.
Для этой роли не требуется назначать специального сотрудника, и ее носитель отвечает за те же задачи, что и владелец продукта, только в соответствующем масштабе.
Другая новая роль — мастер Scrum of Scrums. Исполнитель этой роли отвечает за ведение открытых для других команд бэклогов достижений и проблем, участвует в приоритизации проблем или их устранении и занимается постоянным повышением эффективности Scrum of Scrums.
Для этих новых ролей проводится ежедневное 15-минутное scrum-собрание для изучения, корректировки и решения проблем. Представители команд и (или) владельцы продукта обсуждают проблемы команды, риски на пути к цели спринта, зависимости от других команд и обнаруженные улучшения, которые могут быть полезны для других команд.
Заключение и выводы
Scrum of Scrums широко используется, в том числе как основной способ масштабирования scrum. Важным условием масштабирования является верно подобранная структура команды и наличие у нее времени и ресурсов для поэтапного развития в соответствии с моделью Такмена (формирование, конфликт, нормализация и функционирование).
Существует несколько факторов, которые целесообразно учитывать готовым командам.
- Ежедневные собрания Scrum of Scrums должны занимать не более 15 минут, как и у обычной команды.
- 15-минутное собрание Scrum of Scrums следует проводить после ежедневного scrum-собрания последней команды.
- Создайте рабочее соглашение по Scrum of Scrums.
- Согласуйте групповые и индивидуальные критерии готовности работы и, разумеется, поделитесь ими с коллегами!
- Разработайте процедуру или повестку, чтобы ежедневное собрание Scrum of Scrums проходило организованно.
- Начните отслеживать, в течение скольких дней проблемы препятствовали достижению цели.
- Отслеживайте, сколько ежедневных собраний Scrum of Scrums началось и завершилось вовремя.
- В первую очередь выполняйте истории с зависимостями, чтобы сократить риски и помочь другим командам.
- Отслеживайте с помощью графического представления дни, оставшиеся до демонстрации.
Честно говоря, при agile-подходе не существует единственно верного способа масштабирования. Однако множество организаций добились больших успехов в создании процессов, команд и концепций работы, используя платформы для масштабирования Agile. Подробнее о самых популярных масштабируемых agile-платформах см. в разделе «Agile-подход при любом масштабе» руководства «Тренер по Agile».
