Agile-преобразование всей организации с помощью Scrum@Scale

Как тренировка помогает регбийной команде подготовиться к важному матчу, так и методология Scrum помогает командам работать более эффективно для достижения общей цели. Но что если организация хочет применить Scrum в более крупном масштабе? Если Scrum создает фундамент для разработки, поставки и поддержки сложных продуктов одной командой, то Scrum@Scale (S@S) предлагает способ преобразования всей организационной культуры, главную роль в котором играет экосистема команд.

Методология Scrum@Scale была разработана совместными усилиями организации Scrum Inc. и ассоциации Scrum Alliance под руководством доктора Джеффа Сазерленда, одного из создателей Scrum и соавтора Манифеста agile.

Scrum@Scale — это способ масштабирования Scrum согласно базовым принципам Scrum и теории сложных адаптивных систем. В рамках Scrum@Scale все сотрудники организации поделены на несколько взаимозаменяемых Scrum-команд, которые могут сотрудничать в составе одной экосистемы в зависимости от целей. Концепция Scrum@Scale разработана для масштабирования Scrum в крупных предприятиях. При желании сотрудники могут пройти обучение и сертификацию.

Создавая Scrum@Scale, Сазерленд стремился добиться линейной масштабируемости с помощью «немасштабируемой архитектуры». Ей сопутствует подход «минимально приемлемая бюрократия» (minimum viable bureaucracy, MVB), agile-концепция, которая приобрела известность благодаря Mozilla и Spotify. Согласно этой концепции количество процессов следует свести до такого, при котором эффективность и целостность сохранялась бы в любом масштабе без ограничения творческого потенциала.

Эти особенности Scrum@Scale позволяют избежать увеличения сложности при формировании дополнительных команд, поскольку для группирования людей не используется стандартная иерархия. В Scrum@Scale масштабирование идет от команды к команде команд, затем к системе команд и дальше.

В конечном итоге главной целью Scrum@Scale является решение основных задач, стоящих перед многими организациями:

• эффективная расстановка приоритетов в условиях ограниченности ресурсов;
• поставка работоспособного программного обеспечения высокого качества за ограниченный период времени;
• разработка ПО, которое бы допускало рефакторинг;
• реагирование на изменения с точки зрения как организации, так и продукта.

Scrum@Scale стоит на трех «китах»:

• Небольшие команды
• масштабирование в пределах всей организации;
• применение подхода минимально приемлемой бюрократии.

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

Главным условием масштабирования практик agile в рамках концепции Scrum@Scale являются работоспособные Scrum-команды.

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

Компоненты Scrum@Scale помогают организациям разработать индивидуальные планы по трансформации и подходы к ней.

Проиллюстрировать эту методологию помогут два цикла: цикл scrum-мастера и цикл владельца продукта. Каждый из этих циклов строится вокруг разных аспектов работы (цикл владельца продукта сосредоточен на том, что нужно сделать, а цикл scrum-мастера — на том, как это будет сделано), но у них есть и точки пересечения.

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

Поскольку методология Scrum@Scale выросла из Scrum, у владельца продукта и scrum-мастера, знакомых нам по Scrum, остались те же зоны ответственности, что описаны в Руководстве по Scrum. С понятием команды команд появилось и несколько новых ролей.

• Главный владелец продукта (CPO) взаимодействует с отдельными командами и владельцами продукта, чтобы согласовать порядок выполнения задач в бэклогах с заинтересованными лицами и разработать концепцию долгосрочного развития команды Scrum of Scrums. Главный владелец продукта составляет единый бэклог для всех участников команды Scrum of Scrums.
• Мастер Scrum of Scrums (SoSM) отвечает за совместную работу над релизом и имеет те же обязанности, что и scrum-мастер, только в большем масштабе.

Ключом к успеху в Scrum являются эти простые, но имеющие огромное значение мероприятия:

• Спринт
• Планирование спринтов
• Ежедневное scrum-совещание
• Планирование спринта
• Ретроспектива

При увеличении масштаба команды продолжают практиковать Scrum, как и раньше, но с одним дополнительным мероприятием: ежедневным масштабированным scrum-совещанием, в котором должен принимать участие представитель каждой команды.

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

С увеличением масштаба применения Scrum увеличится и количество проблем, поэтому методология Scrum@Scale требует сформировать исполнительную инициативную команду (Executive Action Team, EAT). Эта команда отвечает за стратегию преобразования, контролирует следование ценностям Scrum и исполнение обязанностей, предписанных Scrum-ролями, оказывает поддержку при принятии решений и устранении препятствий. Команда EAT обязательно должна обладать полномочиями высшего руководства, чтобы менять организацию.

Стандартную зону ответственности команды EAT можно описать следующим образом.

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

Исполнительная мета-команда Scrum (Executive MetaScrum Team, EMT) отвечает за общую концепцию развития организации и ставит перед организацией стратегические приоритеты. В зону ответственности этой команды входят изменение направления развития организации и принятие решений о том, какие продукты или сервисы необходимо реструктурировать или вывести из оборота. Она также проверяет, следует ли компания дорожной карте. Эта команда может функционировать на постоянной основе или собираться для определенной цели.

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

Scrum@Scale позволяет организации эволюционировать естественным образом в комфортном для нее темпе и эффективно координировать работу неограниченного количества scrum-команд благодаря концепции «немасштабируемой архитектуры». Ключевые понятия этой методологии подробно описаны в специальных документах и допускают большую свободу выбора, нежели другие методологии. Поэтому, если вы умело обращаетесь со Scrum на уровне команды, вы без труда сможете применять Scrum@Scale в масштабе всей организации.

Если вы решите внедрить Scrum@Scale, важно добиться точного следования принципам Scrum, прежде чем приступать к увеличению масштаба, и сформировать команду EAT, у которой были бы полномочия совершать изменения и устранять препятствия. Определить, насколько эффективна ваша scrum-команда, помогут различные тесты, которые можно найти в Интернете. Для начала советуем ознакомиться с рекомендациями Джеффа Сазерленда по оценке скорости команды, степени удовлетворенности команды и точкам дохода.

Методологии наподобие Scrum@Scale помогают компаниям эффективно масштабировать методики agile и добиваться желаемых бизнес-результатов. Но не менее важны и инструменты, которые они выбирают для усиления существующих методов работы и реализации всех преимуществ этих методов. С помощью Jira Align, платформы для корпоративного agile-планирования от Atlassian, вы сможете улучшить видимость, обеспечить соответствие стратегическим целям и потребностям компании, чтобы быстрее осуществить цифровые преобразования.