Запуск Scrum-команды: как сделать старт
по-настоящему осмысленным

Для ряда Scrum-мастеров и Agile-коучей запуск команды — это рутина, а для некоторых — по-прежнему загадка, вызывающая напряжение или даже панику. Это событие напоминает извечную дилемму: что появилось раньше — курица или яйцо?

За почти десять лет я запустила более 100 команд и в этой статье хочу поделиться с вами своим опытом. Расскажу о личных лайфхаках, остановлюсь на часто встречающихся ошибках, которые допускают как начинающие, так и опытные Scrum-мастера и Agile-коучи.

Для начала давайте разберёмся с важными пререквизитами. А именно – ответим на вопросы: кто может проводить запуск команды? Что необходимо сделать до запуска?

Ответить на этот вопрос проще, сказав, кто не может этого делать. Если вы – начинающий Scrum-мастер и никогда не участвовали в запуске Scrum-команды, то вы не можете проводить такую сессию. Я не раз встречала ситуации, когда подобную задачу ставили перед новичком, и это было похоже на то, как начинающему медику-аспиранту доверили провести операцию – без поддержки. В этой ситуации пострадают все. Поэтому, если вы хотите, чтобы ваша команда была действительно запущена, а не «на бумаге для галочки», то запуск стоит доверить опытному Scrum-мастеру, Agile-коучу или внешнему консультанту, если в компании пока нет внутреннего специалиста с таким опытом.

Для ответа на этот вопрос нужно сделать шаг назад и убедиться в нескольких важных аспектах – они формируют пререквизиты на входе:

1. Контекст и “нарезка” продукта. Будущая Scrum-команда действительно будет работать над созданием продукта в рамках Change-деятельности компании внутри комплексного домена (Complex domain – по Cynefin Framework).
2. Владелец продукта – зрелый специалист с продуктовым мышлением. Он понимает ценность продукта, знает целевую аудиторию, вектор развития, отличает Discovery от Delivery и осознаёт, что Scrum-команда запускается в рамках Delivery.
3. Будущие участники Scrum-команды прошли обучение по “Основам Agile и Scrum”.

Остановимся на этих трёх аспектах. Это «белые пятна», которые заметны сразу. Если их не прояснить, будут большие сложности. В процессе подготовки появятся и другие «пятна», но эти – критичны на старте.

Чтобы понять, в правильном ли контексте будет работать команда, нужно прояснить её цель. Если нет Change- или Disrupt-деятельности, и команда будет заниматься Run-деятельностью (операционной, например, наймом, подготовкой отчётности или выплатой зарплат) — сразу стоит предупредить: Scrum здесь неприменим. Посмотрите в сторону Kanban-метода.
К сожалению, бывают случаи, когда этого не делают. Команду запускают, а потом выясняется, что она не может работать по спринтам. Итог — разочарование и классическая «натянутая сова на глобус».

Представим, что всё хорошо: контекст подходящий.
Достаточно ли этого? Нет. Следующий шаг — понять, есть ли в команде end-to-end по процессу. Это нужно, чтобы учитывать реальность: если каких-то компетенций нет, вы заранее увидите, где Scrum заканчивается, а дальше — включается каскад (water-fall).

До запуска должен пройти подготовительный этап с PO, который завершится созданием ключевых артефактов: видение продукта (Product Canvas), User Story Map и первые элементы бэклога, готовые к взятию в спринт.

Помните, я говорила в самом начале, что у вас должен быть опытный Владелец продукта? Так вот, Владелец продукта не просто должен знать про продукт, но и уметь составлять карту пользовательских историй и писать элементы бэклога продукта. Если команда работает по Scrum, то самым важным входным артефактом для неё будет Бэклог продукта — и если в нём хаос, то как бы хорошо вы ни запустили процесс по Scrum, он у вас будет сбоить. Как говорится: как бы хороша ни была мясорубка — если на вход вы ей даёте гвозди, то странно ожидать на выходе мясной фарш.

🧩 Итак, у вас готовы артефакты:

• Lean Canvas,
• Product RoadMap,
• первичная User Story Map.

Что же дальше?
Дальше, а точнее — в параллель, вам необходимо выяснить: проходили ли участники будущей Scrum-команды, включая Владельца продукта, обучение по «Основам Agile и Scrum». Если нет — это обучение необходимо провести до запуска. Даже если какой-то процент команды уже обучен, необходимо выровнять знания, чтобы у всех было одинаковое понимание. Если же обучение проходили все, дополнительная подготовка не потребуется
Карта стейкхолдеров. Артефакт, который часто забывают

К сожалению, я встречала команды, которые упускали его из виду и после создания инкремента он не принимался, например, со стороны безопасности или юридического отдела. Карта стейкхолдеров помогает не упустить то, что обязательно должно быть добавлено либо в DoR, либо в DoD — в зависимости от того, на каком этапе требуется согласование

📍Уже много лет мы живём без размещения стикеров на стенах, а используем трекеры (Jira, Yandex, TFS, YouGile и пр.). Перед запуском Scrum-команды важно, чтобы SM, AC или консультант выяснил, в какой системе будет работать команда, какие там есть правила, и создал проект для команды самостоятельно или через заявку (в зависимости от внутренних процессов компании). Также необходимо через ответственных уточнить, где хранится документация команды и где будет размещаться база знаний (Confluence, Wiki и т. д.).

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

🗓️ На запуске команды необходимо будет составить календарь событий, то есть выбрать длину спринта. Не все компании позволяют своим командам выбирать длину так, как им удобно (разумеется, в пределах, допустимых Scrum Guide). Если в вашей компании есть чёткий регламент такта (а это обязательно для тех, кто является частью «поезда» в SAFe), это необходимо выяснить заранее. Также у компании может быть свой релизный календарь, и спринты привязываются к его такту.

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

В этой части я распишу сам день запуска команды и напомню: если ваша команда не проходила обучение по «Основам Agile и Scrum», то до этого дня её необходимо обучить. А если вы решили использовать USM на запуске, то обучить команду работе с картой пользовательских историй также нужно до запуска.

Каждый запускает команду по-своему. Ниже — этапы дня запуска команды, которые использую я:
1. Открытие дня через упражнение Personal Mind Map — участники лучше узнают друг друга. (Если на обучении это упражнение уже проводилось — пропускаем.)
2. Владелец продукта презентует продукт (Lean Canvas) и цели, которые стоят перед командой на ближайшее время (Product RoadMap), а также карту стейкхолдеров. Developers задаёт уточняющие вопросы.
3. Начало составления Team Canvas. После того как Владелец продукта рассказал о продукте, сверяем часы через сердцевину Team Canvas — как поняли, зачем команда собралась. Это может быть вдохновляющий лозунг или мотивирующая фраза.
4. Работа Scrum-команды с USM: размещение элементов Product RoadMap, расстановка приоритетов.
5. Составление командой первого командного артефакта — «Звёздной карты» - с учётом необходимых компетенций для развития продукта. Выявление узких мест (bus factor), планирование шагов для дальнейшей работы со «Звёздной картой».
6. Продолжение работы с Team Canvas: заполняем поля «Личные цели», «Потребности и ожидания», «Ценности», «Люди и роли», «Сильные стороны», «Слабые стороны».
7. Составление командой первичного Definition of Done (критериев готовности инкремента).
8. Работа Scrum-команды с USM: декомпозиция элементов с учётом выработанного DoD.

9. Составление календаря Scrum-событий. Это очень важный этап, особенно если участники находятся в разных часовых поясах. Здесь формируются первые договорённости, которые пойдут в раздел Team Canvas— «Правила»
10. Если в компании не регламентировано, где команда общается, необходимо выбрать мессенджер и установить в нём первичные правила общения. Это также фиксируем в разделе Team Canvas - «Правила».

🚀 И только теперь команда готова к тому, чтобы начать планировать свой первый спринт

11. Работа Scrum-команды с USM: выбор элементов на первый спринт.
12. Проведение планирования спринта (часть 2). Проводится с использованием трекера.

Командные артефакты переносятся в Wiki/Confluence тем, кто проводил запуск и будет сопровождать Scrum-команду: Scrum-мастером, Agile-коучем или консультантом.