Scrum of scrums

Масштабирование Scrum

Chris Spanner Chris Spanner
Просмотр тем

Развитие — это не то же самое, что масштабирование

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

На протяжении нескольких десятилетий Руководство по 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 по масштабированию

Поэтому разделение слишком большой команды на две или три небольших будет способствовать развитию более личных взаимоотношений и достижению желаемых результатов.

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

При наличии нескольких команд, работающих на общий результат, необходима их координация. Это и послужило причиной создания Scrum of scrums.

Назначение Scrum of scrums

Scrum of scrums — это виртуальная команда, состоящая из представителей исходных команд поставки, каждый из которых ссылается на свою команду. По сравнению с обычными организационными иерархиями или командами, созданными на основе проекта, командная структура с такой организацией взаимосвязей позволяет сократить пути коммуникации. Это обеспечивает координацию в небольших независимых командах. В командах, применяющих Scrum of scrums, не только координируется процесс поставки, но и обеспечивается создание полностью интегрированного продукта в конце каждого спринта. Таким образом, команда Scrum of scrums работает как команда по выпуску релизов и отвечает за поставку ценности клиентам. 

Как правило, организации используют этот подход на первом этапе работы, чтобы осуществить agile-масштабирование и организовать поставку крупных и комплексных продуктов.

Диаграмма, показывающая структуру команд Scrum of scrums с дополнительными подключенными сотрудниками в центре и командами поставки снаружи по периметру.

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».

Up Next
Kanban