Agile Scaling: лучшие практики SAFe для Scrum Masters

Эта статья является второй частью серии статей Toptal о масштабировании Agile, предназначенной для руководителей проектов в их усилиях по расширению команды. Прочитайте первую часть «Сравнение 5 Agile Scaling Frameworks: какую из них следует использовать?» для подробного обзора наиболее популярных вариантов.

По мере того, как продукты растут и становятся более сложными, растут и команды, которые их производят. Когда приходит время масштабирования, многие компании переходят от Scrum к Scaled Agile Framework (SAFe), системе, которая внедряется на уровне предприятия и позволяет компаниям управлять несколькими сложными продуктами, для разработки которых требуются группы команд.

Мастер Scrum, переходящий в структуру SAFe, попадет в среду, которая одновременно знакома и нова. Артефакты, роли и церемонии основаны на Scrum. Но работа в более высоком масштабе сопряжена с некоторыми дополнительными обязанностями, особенно для Scrum-мастеров, которые решили перейти на роль инженера по выпуску поездов (RTE), что является обычной траекторией. RTE выступает в роли Scrum-мастера всей цепочки релизов. Вместо того, чтобы руководить Scrum-командой из 9–11 человек, RTE становятся лидерами-слугами команд, состоящих из нескольких отделов, и организуют мероприятия большего размера и размаха.

Основы: от Scrum до SAFe

SAFe позволяет компании применять подходы, ценности и принципы Agile в нескольких командах. Получившаяся в результате «команда команд» известна как Agile Release Train (ART). Отдельные команды продолжают нанимать Scrum-мастера для ведения бизнеса в обычном режиме, в то время как роль Scrum-мастера в ART выполняется RTE. RTE применяет общие механизмы и управление Scrum, но на уровне организации, а не команды. Соответственно меняются и другие традиционные роли и артефакты Scrum на уровне команды. Например, «владелец продукта» ART становится менеджером по продукту; «Бэклог продукта» становится Бэклогом программы; «спринт-бэклог» — это итерационный бэклог; а «приращение продукта» теперь является приращением программы (PI).

Существует четыре конфигурации SAFe — Essential, Large Solution, Portfolio и Full — и та, которую вы используете, зависит от того, насколько широко ваша компания использует эту платформу. Конфигурации позволяют реализовывать решения на нескольких уровнях, начиная от совместной работы нескольких групп и заканчивая полной интеграцией портфолио и гибкостью бизнеса в масштабе всего предприятия. Но на каждом уровне целью остается масштабирование практик Agile и Scrum, а не их замена.

Скрам-мастера в SAFe

Скрам-мастера, работающие в рамках SAFe на уровне команды, обнаружат, что их работа не сильно отличается. Они останутся лидерами-слугами Agile-команды, ответственными за обучение и обучение, устранение препятствий и создание среды, в которой члены команды чувствуют себя в безопасности, чтобы работать лучше и постоянно совершенствоваться.

Однако появятся новые обязанности. Мастер SAFe Scrum поддерживает RTE на мероприятии по планированию PI и при выполнении программы, а также представляет свою команду на собраниях по синхронизации ART. Когда есть препятствия, которые команда не может устранить, скрам-мастер передает их RTE.

Скрам-мастер, решивший стать RTE, обнаружит, что его роль связана с гораздо большим количеством соображений. В состав ART могут входить команды, которые являются новыми для вас или новичками в Agile, например, в области бизнес-анализа, аппаратного обеспечения или соответствия требованиям. А поскольку более высокие конфигурации SAFe включают в себя программные или портфельные операции, руководство будет напрямую и регулярно участвовать в процессах, которых не было бы в Scrum, чтобы убедиться, что все согласовано с целями на уровне предприятия и/или портфеля.

RTE отвечает за устранение препятствий, которые не под силу одной команде. Они общаются с заинтересованными сторонами и способствуют постоянному совершенствованию на уровне АРТ. RTE тренирует не только команды, но и лидеров этих команд, помогая всем уровням ART двигаться к самоорганизации и самоуправлению.

БЕЗОПАСНЫЕ МЕРОПРИЯТИЯ

Точно так же, как Scrum-мастер организует мероприятия на уровне команды, RTE помогает проводить мероприятия на уровне ART — планирование PI, синхронизацию ART, демонстрацию системы, а также проверку и адаптацию. Как RTE, вы будете взаимодействовать с более широким кругом заинтересованных сторон, чем когда вы были мастером Scrum, и работать с несколькими командами с конкурирующими интересами. На каждом мероприятии присутствует больше — и более разных — участников, и вам нужно выровнять приоритеты и заручиться поддержкой инициатив заблаговременно.

PI-планирование

Мероприятие по планированию PI — важная церемония для SAFe, гигантская двухдневная сессия для согласования целей всех команд в рамках ART на следующие восемь-двенадцать недель путем создания плана PI. Это похоже на мероприятие по планированию спринта, но оно охватывает несколько спринтов в нескольких командах.

Входы

• Видение бизнеса
• Список 10–15 основных функций, которые необходимо реализовать
• Подробная информация о возможностях каждой команды

Выходы

• PI-план (план доставки на следующие пять-шесть спринтов)
• Цели PI
• Список потенциальных рисков

Общие советы по событию планирования PI

• Заручитесь поддержкой заинтересованных сторон. Перед собранием RTE должны установить, кто является ключевыми заинтересованными сторонами, и поделиться своим мнением с группой.
• Выровняйте приоритеты. Перед сеансом запланируйте однодневную встречу с командой управления продуктом, чтобы согласовать общее представление о том, какие функции должны быть реализованы, а также о будущих приоритетах. На мероприятии будет много работы, в том числе риски и зависимости, и хорошо иметь базовое соглашение о направлениях.
• Репетируйте! Планирование PI — это огромное событие. Возможно, нет смысла тратить два полных дня на репетиции, но двух-четырехчасовая сессия с руководителями группы ART, которая создает максимально близкий опыт, очень поможет. Создайте упрощенную версию программы мероприятия и поделитесь ею до репетиции, чтобы практика могла начаться с хорошо информированного места.
• Будьте готовы к расползанию миссии. Цель планирования PI состоит в том, чтобы предоставить долгосрочный план за сравнительно короткий период времени. Иногда люди хотят подробно рассказать обо всем, для чего мероприятие не предназначено. Объясните это руководителям групп на репетиции и на сессии; напомните командам, что цель состоит в том, чтобы предоставить планы высокого уровня и создать согласованность, а не планировать каждую минуту в течение следующих трех месяцев.
• Подготовьте информацию о возможностях команды. Попросите своих скрам-мастеров предоставить расчеты мощностей на следующие восемь-двенадцать недель. Ожидайте возражений или вопросов; например, скрам-мастер может не знать точно, сколько отсутствий будет у его команды в течение следующих двух месяцев. В таких случаях запрашивайте оценки и будьте гибкими, реагируя на ограничения мощности во время самого PI.
• Поделитесь программой планирования PI. Распространяйте расписание как минимум за две недели до мероприятия и будьте готовы ответить на множество вопросов. Будет много участников, и если SAFe является новой для вас и вашей компании, вероятно, она также будет новой для многих других членов команды. По моему опыту, ко второму или третьему мероприятию по планированию PI давление на фасилитаторов становится намного меньше, поскольку команды знакомятся с мероприятием и знают, чего ожидать.
• Обеспечение присутствия руководства. Менеджерам или старшим менеджерам часто трудно присутствовать на двухдневном мероприятии, но присутствие руководства необходимо для обеспечения согласованности на высоком уровне. Подтвердите их присутствие как минимум за две недели до планирования PI и организуйте любую поддержку, которая им потребуется. То же самое относится и к владельцам бизнеса, которым необходимо подписать цели PI.

Синхронизация ИСКУССТВА

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

Входы

• Прогресс команд
• Журнал препятствий
• План PI (для выявления любых серьезных отклонений между планом и фактическим прогрессом)

Выходы

• Эскалации (при необходимости)
• Решения о любых изменениях в плане PI

Общие советы по событию ART Sync

• Поощряйте регулярное общение. Поскольку ART Sync проводится еженедельно, а не ежедневно, как в случае со скрамом, RTE должен дать понять, что команды могут немедленно поднимать срочные вопросы и не должны ждать следующей синхронизации ART.
• Будьте готовы с данными. Попросите Scrum-мастеров и владельцев продукта предоставить количественные показатели прогресса, такие как выгорание или совокупный поток, чтобы вести информированный разговор о прогрессе.
• Не ограничивайтесь еженедельным обзором статуса. Синхронизация ART предназначена для того, чтобы быть событием, на котором выравниваются приоритеты и решаются проблемы, а не простая регистрация.

Демонстрация системы

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

Вход

• Текущее состояние работы, основанное на выводах всех членов Agile-команды в ходе предыдущей итерации.

Выходы

• Отзывы о пригодности системы для цели
• Изменения в бэклоге (при необходимости)

Общие советы по демонстрации системы

• Репетируйте! Раз в две недели посвящайте от 30 до 45 минут работе с докладчиками, чтобы зафиксировать их сегменты.
• Откажитесь от слайдов. Представьте фактическую комплексную работу. Если вы работаете над программным продуктом, попросите докладчиков показать заинтересованным сторонам инкремент рабочего продукта, а не набор слайдов. Если возможно, продемонстрируйте свой продукт в тестовой среде. Вы хотите, чтобы демонстрация точно напоминала работу конечного пользователя. Если вы не можете представлять интегрированную систему каждые две недели, просмотрите свой конвейер доставки и проведите мозговой штурм с командами о том, как вы можете внедрить культуру CI/CD и DevOps.
• Сосредоточьтесь на ценности бизнеса. Ваша презентация предназначена для владельцев бизнеса и заинтересованных сторон; поделиться тем, что для них важнее всего.
• Держите обратную связь целенаправленной. Отзывы заинтересованных сторон, которые вы получите, будут важны, но это событие не время для радикальных изменений в видении продукта или дорожной карте. Будьте готовы вернуть разговор к обратной связи высокого уровня, которую команды могут превратить в конкретные действия позднее.
• Держать его коротким. Заинтересованные стороны — занятые люди; встреча продолжительностью от 45 до 60 минут приведет к более частому и заинтересованному посещению.
• Дайте время для вопросов и ответов. Будьте прозрачны в своих ответах. Помните, что иногда «я не знаю, но мы можем узнать» — лучший ответ.

Проверяйте и адаптируйте

Проверка и адаптация — это мегаретроспективная сессия, которая проводится в конце PI. Сессия делится на три части,

• Демонстрация системы PI: демонстрация всех интегрированных выходных данных PI. Это похоже на демонстрацию основной системы, но вместо одной итерации на этом мероприятии демонстрируется интегрированная работа во всем PI.
• Количественные и качественные измерения: возможность для RTE представить метрики, собранные в ходе PI. Эти метрики включают (но не ограничиваются) скорость команды, принятые пользовательские истории, покрытие модульным тестом или открытые дефекты.
• Семинар по ретроспективе и решению проблем: возможность для участников оглянуться на PI, подумать о том, что сработало, а что нет, выявить систематические проблемы и предложить пути их решения.

Входы

• Прогресс команд
• Текущее состояние интегрированной работы ART, включая все выходные данные программных приращений.

Выход

• Список потенциальных улучшений

Общие советы по событию проверки и адаптации

• Предупредите владельцев бизнеса заранее. Предупредите об этом не менее чем за две недели до мероприятия. Встретьтесь с любыми присутствующими менеджерами по продуктам и владельцами бизнеса перед сессией, чтобы согласовать презентацию качественных результатов.
• Обеспечьте присутствие старших заинтересованных сторон. Их присутствие наиболее важно на демонстрации PI System, когда вы демонстрируете работу команды и развивающийся продукт. Здесь применимы многие советы для обычной демонстрации системы: репетируйте заранее, избегайте слайдов презентации и демонстрируйте фактические результаты.
• Избегайте вины. На протяжении всего сеанса убедитесь, что никому не угрожают представленные данные или проблемы, выявленные в ретроспективе. Некоторые команды могут завидовать или защищаться, если показатели другой команды выше, или чувствовать себя выделенными, если проблема возникла в их команде. Примите культуру всей команды, чтобы предотвратить такие проблемы.
• Сосредоточьтесь на системных проблемах. Постарайтесь не уделять слишком много внимания спорадическим проблемам, предоставьте вашей команде пространство, необходимое для мозгового штурма, и дайте волю воображению для предлагаемых решений.
• Создавайте действенные предложения. В конце мероприятия у вас должны быть элементы невыполненной работы для реализации командами. Выявление проблем не поможет, если вы не предпримете шаги для их решения.

В таблице ниже мероприятия SAFe сравниваются с их эквивалентами Scrum, а также описывается частота и выполнение церемоний на уровне предприятия:

Шаг вперед и масштабирование

Переход от Scrum к SAFe может быть пугающим. Работа в более высоком масштабе всегда будет представлять новые проблемы и новые способы осмысления даже самых знакомых практик. Если вы решите стать RTE, вы обнаружите, что работа больше всего зависит от навыков, которые у вас уже есть. RTE является агентом изменений и лидером-слугой, как и мастер Scrum, и эта работа дает вам возможность выполнять эту роль на уровне предприятия, повышая свои навыки вместе с вашими продуктами.