Для ряда Scrum-мастеров и Agile-коучей запуск команды – это рутина, а для некоторых – по-прежнему загадка, вызывающая напряжение или даже панику. Это событие напоминает извечную дилемму: что появилось раньше – курица или яйцо?
За почти десять лет я запустила более 100 команд и в этой статье хочу поделиться с вами своим опытом. Расскажу о личных лайфхаках, остановлюсь на часто встречающихся ошибках, которые допускают как начинающие, так и опытные Scrum-мастера и Agile-коучи..
I. Подготовка к запуску
Для начала давайте разберёмся с важными пререквизитами. А именно – ответим на вопросы: кто может проводить запуск команды? Что необходимо сделать до запуска?
Кто может проводить запуск команды?
Ответить на этот вопрос проще, сказав, кто не может этого делать. Если вы – начинающий Scrum-мастер и никогда не участвовали в запуске Scrum-команды, то вы не можете проводить такую сессию. Я не раз встречала ситуации, когда подобную задачу ставили перед новичком, и это было похоже на то, как начинающему медику-аспиранту доверили провести операцию – без поддержки. В этой ситуации пострадают все. Поэтому, если вы хотите, чтобы ваша команда была действительно запущена, а не «на бумаге для галочки», то запуск стоит доверить опытному Scrum-мастеру, Agile-коучу или внешнему консультанту, если в компании пока нет внутреннего специалиста с таким опытом.
С чего всё начинается?
Для ответа на этот вопрос нужно сделать шаг назад и убедиться в нескольких важных аспектах – они формируют пререквизиты на входе:
- Контекст и “нарезка” продукта. Будущая Scrum-команда действительно будет работать над созданием продукта в рамках Change-деятельности компании внутри комплексного домена (Complex domain – по Cynefin Framework).
- Владелец продукта – зрелый специалист с продуктовым мышлением. Он понимает ценность продукта, знает целевую аудиторию, вектор развития, отличает Discovery от Delivery и осознаёт, что Scrum-команда запускается в рамках Delivery.
- Будущие участники Scrum-команды прошли обучение по “Основам Agile и Scrum”.
Остановимся на этих трёх аспектах. Это «белые пятна», которые заметны сразу. Если их не прояснить, будут большие сложности. В процессе подготовки появятся и другие «пятна», но эти – критичны на старте.
Правильный контекст и “нарезка”
Чтобы понять, в правильном ли контексте будет работать команда, нужно прояснить её цель. Если нет Change- или Disrupt-деятельности, и команда будет заниматься Run-деятельностью (операционной, например, наймом, подготовкой отчётности или выплатой зарплат) – сразу стоит предупредить: Scrum здесь неприменим. Посмотрите в сторону Kanban-метода.
К сожалению, бывают случаи, когда этого не делают. Команду запускают, а потом выясняется, что она не может работать по спринтам. Итог – разочарование и классическая «натянутая сова на глобус».
Представим, что всё хорошо: контекст подходящий.
Достаточно ли этого? Нет. Следующий шаг – понять, есть ли в команде end-to-end по процессу. Это нужно, чтобы учитывать реальность: если каких-то компетенций нет, вы заранее увидите, где Scrum заканчивается, а дальше – включается каскад (water-fall).
Работа Владельца продукта (Product Owner - PO)
До запуска должен пройти подготовительный этап с PO, который завершится созданием ключевых артефактов: видение продукта (Product Canvas), User Story Map и первые элементы бэклога, готовые к взятию в спринт.
Артефакт #1: Lean Canvas
Мне нравится работать с PO через Lean Canvas (см. рис. 1). Вы также можете использовать Business Model Canvas – отличие лишь в нескольких ячейках.
Я рекомендую Lean Canvas – он помогает владельцу продукта структурировать мышление.
Можно ли что-то не заполнять?
Конечно, часто остаются пустыми пункты 6 и 7, но они всё равно должны быть прояснены, чтобы PO мог считать экономику продукта.
Готовый Canvas будет презентован на запуске, в блоке «Над чем мы будем работать», чтобы команда выровнялась по видению. В процессе артефакт может быть скорректирован, если появятся важные дополнения от команды.
Артефакт #2: Product Roadmap и переход к User Story Map
Иногда PO сложно сразу приступить к созданию User Story Map – он хочет сделать это с командой. Такое возможно, но тогда нужен дополнительный день до запуска: чтобы обучить команду созданию карты и начать делать её вместе
Roadmap помогает наполнить User Story Map: сначала – крупные элементы, затем их декомпозиция до подходящего размера, чтобы взять в спринт.
⚡️ Лайфхак: я рекомендую составлять User Story Map вместе с UI/UX и CJE-экспертами, на базе проведённых исследований (CustDev) и при необходимости прототипов. Затем презентовать первый драфт USM остальным участникам команды.
Важно: фреймворк Scrum описывает процесс Delivery. Он не включает Discovery (см. Scrum Guide 2020). Поэтому классический запуск Scrum-команды — это запуск процесса Delivery, после работы Discovery. Все необходимые артефакты Discovery должны быть готовы к запуску.
Помните, я говорила в самом начале, что у вас должен быть опытный Владелец продукта? Так вот, Владелец продукта не просто должен знать про продукт, но и уметь составлять карту пользовательских историй и писать элементы бэклога продукта. Если команда работает по 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), это необходимо выяснить заранее. Также у компании может быть свой релизный календарь, и спринты привязываются к его такту.
В одной из команд, с которой я работала, такт был следующим:
2 недели – 2 недели – 3 недели
поскольку последняя неделя отводилась на регрессионное тестирование, а затем происходил релиз на прод.
Важно: конец спринта ⧣ релиз. Ваша команда может релизиться внутри спринта, так же как и выпустить релиз по окончании квартала. Инкремент, который команда получает в конце спринта, – это потенциально готовый к поставке элемент: он может быть не поставлен на прод, так же как и в конце спринта вы можете показать инкремент, который уже находится на проде. Всё зависит от команды и её правил или контекста.
Теперь можно сказать, что подготовка к запуску завершена. Но помните: всегда найдётся что-то, что следовало сделать заранее и вы это могли упустить. Не переживайте: просто сделайте заметку для себя и вернитесь к ней, когда будете готовить следующий запуск.
II. Запуск Scrum-команды (Kick-off / Lift-Up)
В этой части я распишу сам день запуска команды и напомню: если ваша команда не проходила обучение по “Основам Agile и Scrum”, то до этого дня её необходимо обучить. А если вы решили использовать USM на запуске, то обучить команду работе с картой пользовательских историй также нужно до запуска.
Когда вы проводите запуск Scrum-команды, вы должны помнить: это планирование, по итогам которого участники должны уйти с бэклогом спринта. Вся ваша деятельность должна быть сосредоточена на этом результате.
Если вы не успеваете сделать что-то второстепенное по отношению к этой цели, это можно отложить на другие дни
Каждый запускает команду по-своему. Ниже – этапы дня запуска команды, которые использую я:
- Открытие дня через упражнение Personal Mind Map — участники лучше узнают друг друга. (Если на обучении это упражнение уже проводилось — пропускаем.)
- Владелец продукта презентует продукт (Lean Canvas) и цели, которые стоят перед командой на ближайшее время (Product RoadMap), а также карту стейкхолдеров. Developers задаёт уточняющие вопросы.
- Начало составления Team Canvas. После того как Владелец продукта рассказал о продукте, сверяем часы через сердцевину Team Canvas – как поняли, зачем команда собралась. Это может быть вдохновляющий лозунг или мотивирующая фраза.
- Работа Scrum-команды с USM: размещение элементов Product RoadMap, расстановка приоритетов.
- Составление командой первого командного артефакта – «Звёздной карты» – с учётом необходимых компетенций для развития продукта. Выявление узких мест (bus factor), планирование шагов для дальнейшей работы со «Звёздной картой».
- Продолжение работы с Team Canvas: заполняем поля «Личные цели», «Потребности и ожидания», «Ценности», «Люди и роли», «Сильные стороны», «Слабые стороны».
- Составление командой первичного Definition of Done (критериев готовности инкремента).
- Составление календаря Scrum-событий. Это очень важный этап, особенно если участники находятся в разных часовых поясах. Здесь формируются первые договорённости, которые пойдут в раздел Team Canvas – «Правила»
- Если в компании не регламентировано, где команда общается, необходимо выбрать мессенджер и установить в нём первичные правила общения. Это также фиксируем в разделе Team Canvas – «Правила».
И здесь, а возможно и раньше, вы столкнётесь с необходимостью выработки правила принятия решений
🚀 И только теперь команда готова к тому, чтобы начать планировать свой первый спринт
11. Работа Scrum-команды с USM: выбор элементов на первый спринт.
12. Проведение планирования спринта (часть 2). Проводится с использованием трекера.
Поскольку команда только запустилась, у неё пока не будет никакой оценки. Однако команда должна знать, что через несколько спринтов (обычно через 3–4) начнётся процесс оценки элементов бэклога продукта.
Перед этим будет проведена встреча, на которой участникам расскажут об оценке и вместе с командой будет составлена её собственная шкала оценки
С чем Scrum-команда уходит с запуска?
- заполненной USM;
- запланированным бэклогом спринта;
- “Звёздной картой”;
- Заполненным Team Canvas;
- Пониманием дальнейших шагов по развитию команды – например, уточнение “Правил и договорённостей” на ретроспективе после окончания первого спринта, проведение “Воркшопа по относительной оценке”, обновление “Звёздной карты” и т. д.
Кто и куда переносит всё, что получилось на запуске команды?
Командные артефакты переносятся в Wiki/Confluence тем, кто проводил запуск и будет сопровождать Scrum-команду: Scrum-мастером, Agile-коучем или консультантом.
---
👩🏼💻 Автор статьи Анастасия Бутова-Никишина — основатель и генеральный директор компании «Лаборатория ПроЛидеров», организационный консультант, автор и тренер “Школы Скрам-мастеров” ProLeadersLab®
💬 Если у вас остались вопросы или вы с чем-то не согласны – пожалуйста, напишите мне, и мы вместе сделаем эту статью лучше
