Запуск Скрам-команды
Подготовка, установочная сессия
и первый спринт
и первый спринт
Команда познакомилась, согласовала календарь событий Скрама, заполнила «Канву команды» (Team Canvas) и запланировала первый спринт. По итогам установочной сессии казалось, что запуск Скрам-команды состоялся.
Через две недели выяснилось, что продуктовые решения принимать некому, одной из ключевых компетенций внутри команды нет, внешние согласования занимают больше времени, чем сам спринт, а участники по-разному понимают, какой результат должна создавать команда.
Формально запуск состоялся. К совместной работе команда оказалась не готова.
Практика запусков и перезапусков команд показывает: качество старта определяется не количеством упражнений и заполненных шаблонов. Гораздо важнее, что было подготовлено до установочной сессии, какие решения команда смогла принять во время неё и как они проявили себя в первом спринте.
Установочная сессия – только один из этапов запуска Скрам-команды. Сам запуск начинается раньше общей встречи и не заканчивается вместе с ней. До сессии нужно проверить продуктовый и организационный контекст. Во время неё команда должна согласовать цель продукта, прояснить ответственность и зависимости, договориться о правилах совместной работы. А в первом спринте становится видно, работают ли эти договорённости за пределами фасилитационной доски.
Из этой статьи вы узнаете, как подготовить запуск Скрам-команды, что должно произойти на установочной сессии, с каким результатом команда должна войти в первый спринт и что предстоит делать Скрам-мастеру после запуска.
Через две недели выяснилось, что продуктовые решения принимать некому, одной из ключевых компетенций внутри команды нет, внешние согласования занимают больше времени, чем сам спринт, а участники по-разному понимают, какой результат должна создавать команда.
Формально запуск состоялся. К совместной работе команда оказалась не готова.
Практика запусков и перезапусков команд показывает: качество старта определяется не количеством упражнений и заполненных шаблонов. Гораздо важнее, что было подготовлено до установочной сессии, какие решения команда смогла принять во время неё и как они проявили себя в первом спринте.
Установочная сессия – только один из этапов запуска Скрам-команды. Сам запуск начинается раньше общей встречи и не заканчивается вместе с ней. До сессии нужно проверить продуктовый и организационный контекст. Во время неё команда должна согласовать цель продукта, прояснить ответственность и зависимости, договориться о правилах совместной работы. А в первом спринте становится видно, работают ли эти договорённости за пределами фасилитационной доски.
Из этой статьи вы узнаете, как подготовить запуск Скрам-команды, что должно произойти на установочной сессии, с каким результатом команда должна войти в первый спринт и что предстоит делать Скрам-мастеру после запуска.
Навигация по статье:
- Запуск Скрам-команды: не только установочная сессия
- Что проверить до запуска Скрам-команды
- Что подготовить вместе с Владельцем продукта
- Кто проводит установочную сессию
- Что должно произойти на установочной сессии
- С каким результатом команда должна войти в первый спринт
- Почему даже хороший запуск может не сработать
- Что делает Скрам-мастер после запуска
Запуск Скрам-команды: не только установочная сессия
В Руководстве по Скраму нет отдельного события «запуск команды» и не описано, как именно новая команда должна начинать работу. Скрам задаёт минимальную рамку, но не предлагает готового сценария старта. Поэтому запуск Скрам-команды я рассматриваю не как дополнительное событие Скрама, а как практический процесс подготовки команды к работе.
Этот процесс начинается до общей встречи. Нужно понять, для чего создаётся команда, какой продукт она будет развивать, есть ли у неё цель продукта, кто может принимать решения о продукте и достаточно ли в составе команды компетенций для создания ценного готового инкремента. Важно также увидеть внешние зависимости, ограничения и реальные полномочия команды. Скрам-команда должна быть кросс-функциональной и иметь все навыки, необходимые для создания ценности в каждом спринте, а организация должна предоставить ей возможность управлять собственной работой.
Установочная сессия помогает участникам выровнять понимание продукта и цели, прояснить зоны ответственности и зависимости, обсудить способы принятия решений и договориться о совместной работе. Она делает видимыми вопросы, которые до встречи могли существовать только в головах отдельных участников.
Если команда начинает первый спринт в тот же день, после установочной части она переходит к планированию спринта. Это уже отдельное событие Скрама, в ходе которого вся Скрам-команда определяет, почему спринт будет ценным, что можно сделать и как будет создан готовый инкремент. Установочная сессия может подготовить условия для качественного планирования, но не должна его подменять.
После общей встречи запуск продолжается в реальной работе. Первый спринт показывает, может ли Владелец продукта оперативно принимать решения, хватает ли команде компетенций, удаётся ли ей самостоятельно организовывать работу и насколько внешние зависимости влияют на достижение цели спринта.
Команда может договориться доводить работу до готового результата, а затем обнаружить, что тестирование выполняется другим подразделением, доступ к данным согласовывается несколько дней, а решение Владельца продукта требует дополнительного одобрения руководителя. На установочной сессии эти ограничения можно выявить. В первом спринте становится понятно, насколько серьёзно они влияют на результат.
Поэтому за один день можно провести установочную сессию и начать первый спринт. Но запуск Скрам-команды как процесс на этом не заканчивается. Он включает предварительную подготовку, решения во время общей встречи и сопровождение команды, когда эти решения впервые проверяются реальной работой.
Задача Скрам-мастера здесь шире, чем подготовка сценария и проведение фасилитации. Ему важно помочь команде увидеть условия, в которых она будет работать, сделать ограничения прозрачными и не подменять реальную готовность команды набором формально зафиксированных договорённостей.
Этот процесс начинается до общей встречи. Нужно понять, для чего создаётся команда, какой продукт она будет развивать, есть ли у неё цель продукта, кто может принимать решения о продукте и достаточно ли в составе команды компетенций для создания ценного готового инкремента. Важно также увидеть внешние зависимости, ограничения и реальные полномочия команды. Скрам-команда должна быть кросс-функциональной и иметь все навыки, необходимые для создания ценности в каждом спринте, а организация должна предоставить ей возможность управлять собственной работой.
Установочная сессия помогает участникам выровнять понимание продукта и цели, прояснить зоны ответственности и зависимости, обсудить способы принятия решений и договориться о совместной работе. Она делает видимыми вопросы, которые до встречи могли существовать только в головах отдельных участников.
Если команда начинает первый спринт в тот же день, после установочной части она переходит к планированию спринта. Это уже отдельное событие Скрама, в ходе которого вся Скрам-команда определяет, почему спринт будет ценным, что можно сделать и как будет создан готовый инкремент. Установочная сессия может подготовить условия для качественного планирования, но не должна его подменять.
После общей встречи запуск продолжается в реальной работе. Первый спринт показывает, может ли Владелец продукта оперативно принимать решения, хватает ли команде компетенций, удаётся ли ей самостоятельно организовывать работу и насколько внешние зависимости влияют на достижение цели спринта.
Команда может договориться доводить работу до готового результата, а затем обнаружить, что тестирование выполняется другим подразделением, доступ к данным согласовывается несколько дней, а решение Владельца продукта требует дополнительного одобрения руководителя. На установочной сессии эти ограничения можно выявить. В первом спринте становится понятно, насколько серьёзно они влияют на результат.
Поэтому за один день можно провести установочную сессию и начать первый спринт. Но запуск Скрам-команды как процесс на этом не заканчивается. Он включает предварительную подготовку, решения во время общей встречи и сопровождение команды, когда эти решения впервые проверяются реальной работой.
Задача Скрам-мастера здесь шире, чем подготовка сценария и проведение фасилитации. Ему важно помочь команде увидеть условия, в которых она будет работать, сделать ограничения прозрачными и не подменять реальную готовность команды набором формально зафиксированных договорённостей.
Что проверить до запуска Скрам-команды
Одна из самых дорогих ошибок при запуске команды состоит в том, чтобы сразу перейти к сценарию установочной сессии. Подготовить упражнения, собрать доску, пригласить участников, а уже на встрече обнаружить, что непонятно, какой продукт создаёт команда, кто принимает решения и почему половина людей занята ещё в нескольких проектах.
Хорошая фасилитация такие проблемы не устраняет. В лучшем случае делает их видимыми.
Хорошая фасилитация такие проблемы не устраняет. В лучшем случае делает их видимыми.
Подходит ли Скрам характеру работы
Он полезен там, где есть сложность и неопределённость, а решение невозможно полностью спроектировать заранее. Команда создаёт результат короткими циклами, получает обратную связь и корректирует дальнейшие действия.
Если основную часть работы составляют повторяющиеся запросы, инциденты или регламентные операции, Скрам может оказаться избыточным. В таком контексте полезнее рассмотреть Канбан-метод.
Бывает и наоборот: организацию называют продуктовой, но от команды ждут выполнения заранее утверждённого списка задач. Можно завести бэклог и поставить события Скрама в календарь, но возможности исследовать, принимать решения и адаптировать продукт у команды от этого не появится.
Если основную часть работы составляют повторяющиеся запросы, инциденты или регламентные операции, Скрам может оказаться избыточным. В таком контексте полезнее рассмотреть Канбан-метод.
Бывает и наоборот: организацию называют продуктовой, но от команды ждут выполнения заранее утверждённого списка задач. Можно завести бэклог и поставить события Скрама в календарь, но возможности исследовать, принимать решения и адаптировать продукт у команды от этого не появится.
Понимаем ли мы, какой продукт создаёт команда
Иногда за словом «продукт» скрывается название проекта, перечень систем или список функций. Участники могут организовать работу, но по-разному понимать, для кого и ради какого результата они её выполняют.
До запуска важно хотя бы на базовом уровне прояснить:
До запуска важно хотя бы на базовом уровне прояснить:
- какой продукт создаёт или развивает команда;
- кто его пользователи;
- какую проблему он помогает решить;
- к какой цели продукта движется команда.
Есть ли у команды реальный Владелец продукта
Название роли ещё не означает, что человек может принимать решения.
Если каждое изменение приходится согласовывать с несколькими руководителями, Владелец продукта быстро превращается в передаточное звено. Команда задаёт вопрос, он уходит за ответом, возвращается через несколько дней, а спринт тем временем продолжается.
До запуска важно понять, может ли Владелец продукта определять порядок элементов бэклога, выбирать между конкурирующими приоритетами и быть доступным команде в ходе спринта.
Если каждое изменение приходится согласовывать с несколькими руководителями, Владелец продукта быстро превращается в передаточное звено. Команда задаёт вопрос, он уходит за ответом, возвращается через несколько дней, а спринт тем временем продолжается.
До запуска важно понять, может ли Владелец продукта определять порядок элементов бэклога, выбирать между конкурирующими приоритетами и быть доступным команде в ходе спринта.
Способна ли команда создавать готовый инкремент
На организационной схеме она может выглядеть кросс-функциональной, а в реальности зависеть от внешнего тестирования, аналитики, архитекторов, доступа к данным или отдельного подразделения, которое выводит изменения в рабочую среду.
Полная независимость встречается редко. Но до запуска нужно увидеть, каких компетенций не хватает, какая работа остаётся за пределами команды и какие зависимости могут заблокировать результат уже в первом спринте.
Здесь же стоит проверить реальную занятость участников. Если каждый одновременно работает ещё в двух или трёх инициативах, команда существует скорее на слайде. В реальной работе люди будут постоянно выбирать между разными целями, приоритетами и руководителями.
Полная независимость встречается редко. Но до запуска нужно увидеть, каких компетенций не хватает, какая работа остаётся за пределами команды и какие зависимости могут заблокировать результат уже в первом спринте.
Здесь же стоит проверить реальную занятость участников. Если каждый одновременно работает ещё в двух или трёх инициативах, команда существует скорее на слайде. В реальной работе люди будут постоянно выбирать между разными целями, приоритетами и руководителями.
Установочная сессия не должна становиться первым знакомством со Скрамом
К общей встрече участникам важно понимать базовые принципы работы, ответственность участников Скрам-команды, связь между целью продукта, бэклогом продукта и целью спринта.
Речь не о многодневном обучении. Но команда должна прийти на запуск готовой обсуждать свою работу, а не впервые разбираться в терминологии.
Такая проверка не устраняет все будущие сложности. Она помогает отделить вопросы, которые команда сможет решить во время установочной сессии, от организационных ограничений, для работы с которыми понадобятся руководители, смежные подразделения и время.
Только после этого имеет смысл переходить к подготовке продукта и материалов для установочной сессии.
Речь не о многодневном обучении. Но команда должна прийти на запуск готовой обсуждать свою работу, а не впервые разбираться в терминологии.
Такая проверка не устраняет все будущие сложности. Она помогает отделить вопросы, которые команда сможет решить во время установочной сессии, от организационных ограничений, для работы с которыми понадобятся руководители, смежные подразделения и время.
Только после этого имеет смысл переходить к подготовке продукта и материалов для установочной сессии.
Что подготовить вместе с Владельцем продукта
После проверки контекста можно переходить к подготовке установочной сессии. И здесь большая часть предварительной работы проходит вместе с Владельцем продукта.
Иногда на общую встречу выносят только идею продукта, рассчитывая, что команда сама сформулирует всё остальное. Участие команды действительно важно: разработчики могут увидеть риски, ограничения и возможности, которые не заметил Владелец продукта. Но начинать с пустого листа не стоит. Владелец продукта должен прийти с основой, которую команда сможет обсудить, дополнить и при необходимости оспорить.
Первое, что необходимо прояснить, какой продукт создаёт команда и к какой цели продукта движется. В Руководстве по Скраму цель продукта описывает его будущее состояние и служит ориентиром для планирования работы Скрам-команды. При этом понимание продукта не фиксируется раз и навсегда: оно будет уточняться по мере получения обратной связи и появления новых данных.
В моей практике Владельцу продукта часто помогает «Lean Canvas» (см.рис.1). Он позволяет собрать в одном месте основные предположения о пользователях, их проблемах, ценностном предложении, каналах, метриках и экономике продукта.
Это не артефакт Скрама и не обязательный шаблон. Можно использовать другую модель. Важно, чтобы Владелец продукта сам мог связно объяснить команде, для кого создаётся продукт, какую проблему он решает и за счёт чего должен приносить ценность.
Иногда на общую встречу выносят только идею продукта, рассчитывая, что команда сама сформулирует всё остальное. Участие команды действительно важно: разработчики могут увидеть риски, ограничения и возможности, которые не заметил Владелец продукта. Но начинать с пустого листа не стоит. Владелец продукта должен прийти с основой, которую команда сможет обсудить, дополнить и при необходимости оспорить.
Первое, что необходимо прояснить, какой продукт создаёт команда и к какой цели продукта движется. В Руководстве по Скраму цель продукта описывает его будущее состояние и служит ориентиром для планирования работы Скрам-команды. При этом понимание продукта не фиксируется раз и навсегда: оно будет уточняться по мере получения обратной связи и появления новых данных.
В моей практике Владельцу продукта часто помогает «Lean Canvas» (см.рис.1). Он позволяет собрать в одном месте основные предположения о пользователях, их проблемах, ценностном предложении, каналах, метриках и экономике продукта.
Это не артефакт Скрама и не обязательный шаблон. Можно использовать другую модель. Важно, чтобы Владелец продукта сам мог связно объяснить команде, для кого создаётся продукт, какую проблему он решает и за счёт чего должен приносить ценность.
Рис. 1 Lean Canvas
На установочной сессии Владелец продукта презентует эту основу команде. Не для того, чтобы участники молча согласились с готовой картиной, а чтобы они могли задать вопросы, обнаружить противоречия и выровнять понимание продукта.
Следующий уровень подготовки – направление развития продукта. Здесь может помочь «Дорожная карта продукта» (Product Roadmap). Она показывает не детальный план реализации на несколько месяцев вперёд, а крупные изменения и результаты, к которым движется продукт.
Дорожная карта также не входит в обязательные элементы Скрама. В этой статье она выступает как практический инструмент, который помогает связать цель продукта с будущей работой команды.
Следующий уровень подготовки – направление развития продукта. Здесь может помочь «Дорожная карта продукта» (Product Roadmap). Она показывает не детальный план реализации на несколько месяцев вперёд, а крупные изменения и результаты, к которым движется продукт.
Дорожная карта также не входит в обязательные элементы Скрама. В этой статье она выступает как практический инструмент, который помогает связать цель продукта с будущей работой команды.
Рис. 2 Дорожная карта продукта (Product RoadMap)
От дорожной карты можно переходить к первичной Карте пользовательских историй (User Story Map). Она помогает увидеть продукт через действия пользователя, разложить крупные направления на части и связать будущие элементы бэклога с пользовательским сценарием.
Карту не обязательно доводить до идеального состояния до установочной сессии. Владелец продукта может подготовить первый вариант вместе со специалистами по пользовательскому опыту, аналитиками и другими участниками продуктового исследования, а затем обсудить его с командой.
Здесь важно не впасть в другую крайность и не пытаться завершить все исследования до начала работы по Скраму. Исследование продукта, проверка гипотез и создание инкрементов могут идти параллельно. К установочной сессии нужна не окончательная истина о продукте, а достаточная основа для начала осмысленной работы.
К планированию первого спринта у команды должен быть первоначальный упорядоченный бэклог продукта. Его элементы не обязаны быть описаны на месяцы вперёд, но ближайшая работа должна быть достаточно понятна, чтобы команда могла обсудить её, уточнить и выбрать элементы для первого спринта. Сам бэклог будет развиваться по мере того, как команда узнаёт больше о продукте и его пользователях.
Отдельно вместе с Владельцем продукта стоит составить первичную карту заинтересованных сторон. Особенно важно увидеть тех, кто может повлиять на создание, согласование или вывод результата в рабочую среду: представителей информационной безопасности, юридической службы, архитектуры, эксплуатации, владельцев связанных систем и внешних партнёров.
На практике команды нередко вспоминают о таких участниках уже после создания инкремента. С точки зрения команды результат готов, но использовать его нельзя: не получено обязательное согласование, отсутствует доступ или изменение противоречит требованиям другого подразделения.
Карту заинтересованных сторон не обязательно завершать до установочной сессии. Владелец продукта готовит первоначальную версию, а команда дополняет её теми зависимостями и участниками, которые видит со своей стороны.
К установочной сессии у Владельца продукта должна быть рабочая основа:
- цель продукта;
- общее понимание пользователей и их потребностей;
- направление развития продукта;
- первоначальная Карта пользовательских историй;
- упорядоченный бэклог с подготовленными ближайшими элементами;
- предварительная карта заинтересованных сторон.
Это не готовая картина, которую команда должна принять без обсуждения. Задача предварительной подготовки в другом: дать участникам достаточно материала, чтобы на установочной сессии обсуждать реальные продуктовые решения, задавать содержательные вопросы и готовиться к первому спринту, а не заполнять шаблоны с чистого листа.
Когда бэклог не связан с целью продукта и пользовательским сценарием, он быстро превращается в перечень разрозненных задач. На тренинге «Управление бэклогом продукта. Построение Карты пользовательских историй» участники учатся выстраивать эту связь и создают карту на практике.
Посмотреть программу тренинга →
Посмотреть программу тренинга →
Кто проводит установочную сессию
В Руководстве по Скраму нет отдельного события «установочная сессия», поэтому там не определено, кто должен её проводить. Это практический формат подготовки команды к совместной работе. В большинстве случаев логично, чтобы сессию вёл Скрам-мастер, который затем будет сопровождать команду. В Scrum Guide 2020 Скрам-мастер отвечает за то, чтобы Скрам был установлен в соответствии с Руководством, и помогает Скрам-команде повышать эффективность.
Но назначить Скрам-мастера ведущим ещё не означает, что сессия пройдёт качественно.
Я не раз видела, как начинающему специалисту передавали готовый сценарий и отправляли проводить первый запуск в одиночку. Формально всё могло пройти по плану: участники познакомились, заполнили шаблоны, договорились о календаре. А важные вопросы так и оставались без решения.
Проблема не в том, что новичок не способен провести упражнение. Сценарий и упражнения как раз являются самой понятной частью работы. Гораздо сложнее одновременно следить за динамикой группы, удерживать цель встречи, замечать противоречия, останавливать преждевременное согласие и помогать участникам принимать решения.
Например, команда может быстро согласиться с целью продукта, потому что никто не хочет спорить с Владельцем продукта. Или зафиксировать правило принятия решений, хотя у участников нет реальных полномочий ему следовать. На доске появится результат. В первом спринте выяснится, что договорённость не работает.
Если Скрам-мастер впервые ведёт установочную сессию и ещё не умеет одновременно удерживать содержание, групповую динамику и организационные ограничения, безопаснее не оставлять его с этой задачей один на один. Можно пригласить опытного Скрам-мастера, Agile-коуча или консультанта как ведущего или софасилитатора. Другой вариант — заранее разобрать сценарий с наставником, распределить роли на встрече, а после подробно обсудить, что происходило с командой.
Это не означает, что более опытный специалист должен полностью забрать работу себе. Задача поддержки состоит в том, чтобы начинающий Скрам-мастер постепенно учился видеть не только запланированные этапы сессии, но и то, что происходит между участниками.
Если внутри компании такого опыта пока нет, установочную сессию может провести внешний специалист. Но тогда важно заранее договориться, кто будет сопровождать команду после встречи. Иначе внешний консультант уйдёт, а внутренний Скрам-мастер останется с красивой доской и решениями, происхождение которых он не до конца понимает.
Владелец продукта при этом активно участвует в установочной сессии: представляет продукт, отвечает на вопросы и обсуждает решения с командой. Но ему не стоит одновременно вести весь процесс. Сложно содержательно защищать продуктовую позицию и в то же время оставаться нейтральным фасилитатором.
Готовый сценарий помогает удержать последовательность встречи. Но он не заменяет умение работать с групповой динамикой, разногласиями и ограничениями системы. Именно здесь обычно становится заметна разница между знанием терминов Скрама и готовностью работать в роли Скрам-мастера.
Источник: Scrum Guide 2020
Но назначить Скрам-мастера ведущим ещё не означает, что сессия пройдёт качественно.
Я не раз видела, как начинающему специалисту передавали готовый сценарий и отправляли проводить первый запуск в одиночку. Формально всё могло пройти по плану: участники познакомились, заполнили шаблоны, договорились о календаре. А важные вопросы так и оставались без решения.
Проблема не в том, что новичок не способен провести упражнение. Сценарий и упражнения как раз являются самой понятной частью работы. Гораздо сложнее одновременно следить за динамикой группы, удерживать цель встречи, замечать противоречия, останавливать преждевременное согласие и помогать участникам принимать решения.
Например, команда может быстро согласиться с целью продукта, потому что никто не хочет спорить с Владельцем продукта. Или зафиксировать правило принятия решений, хотя у участников нет реальных полномочий ему следовать. На доске появится результат. В первом спринте выяснится, что договорённость не работает.
Если Скрам-мастер впервые ведёт установочную сессию и ещё не умеет одновременно удерживать содержание, групповую динамику и организационные ограничения, безопаснее не оставлять его с этой задачей один на один. Можно пригласить опытного Скрам-мастера, Agile-коуча или консультанта как ведущего или софасилитатора. Другой вариант — заранее разобрать сценарий с наставником, распределить роли на встрече, а после подробно обсудить, что происходило с командой.
Это не означает, что более опытный специалист должен полностью забрать работу себе. Задача поддержки состоит в том, чтобы начинающий Скрам-мастер постепенно учился видеть не только запланированные этапы сессии, но и то, что происходит между участниками.
Если внутри компании такого опыта пока нет, установочную сессию может провести внешний специалист. Но тогда важно заранее договориться, кто будет сопровождать команду после встречи. Иначе внешний консультант уйдёт, а внутренний Скрам-мастер останется с красивой доской и решениями, происхождение которых он не до конца понимает.
Владелец продукта при этом активно участвует в установочной сессии: представляет продукт, отвечает на вопросы и обсуждает решения с командой. Но ему не стоит одновременно вести весь процесс. Сложно содержательно защищать продуктовую позицию и в то же время оставаться нейтральным фасилитатором.
Готовый сценарий помогает удержать последовательность встречи. Но он не заменяет умение работать с групповой динамикой, разногласиями и ограничениями системы. Именно здесь обычно становится заметна разница между знанием терминов Скрама и готовностью работать в роли Скрам-мастера.
Источник: Scrum Guide 2020
Что должно произойти на установочной сессии
Установочная сессия нужна не для того, чтобы команда за один день заполнила как можно больше шаблонов. Её задача в другом: создать общую основу, с которой участники смогут перейти к совместной работе и планированию первого спринта.
Хороший сценарий отвечает не только на вопрос «что мы будем делать на встрече», но и на более важный вопрос: что команда должна понять, обсудить и решить к её завершению.
Выровнять понимание продукта и цели продукта
Владелец продукта представляет подготовленную основу: цель продукта, понимание пользователей и их потребностей, направление развития, первоначальную Карту пользовательских историй и карту заинтересованных сторон.
Команда не просто слушает презентацию. Участники задают вопросы, проверяют предположения и дополняют общую картину тем, что видят со своей стороны. На этом этапе нередко обнаруживается, что люди одинаково называют продукт, но по-разному понимают, какой результат он должен создавать. Лучше увидеть это до первого спринта, чем после нескольких недель работы над задачами, которые ведут команду в разные стороны.
Команда не просто слушает презентацию. Участники задают вопросы, проверяют предположения и дополняют общую картину тем, что видят со своей стороны. На этом этапе нередко обнаруживается, что люди одинаково называют продукт, но по-разному понимают, какой результат он должен создавать. Лучше увидеть это до первого спринта, чем после нескольких недель работы над задачами, которые ведут команду в разные стороны.
Познакомить людей не только по именам и должностям
Если участники раньше не работали вместе, им важно узнать, какой опыт и профессиональные интересы есть у коллег, с какими задачами они умеют справляться и в каких областях им потребуется поддержка. Для знакомства можно использовать «Персональную карту» (Personal Mind Map) или другой подходящий формат. Само упражнение здесь вторично. Важно, чтобы за названиями ролей появились реальные люди, которым предстоит вместе принимать решения и создавать результат.
Понять, достаточно ли команде компетенций
Даже если состав был предварительно проверен, на общей сессии обычно становится видна более точная картина. Участники лучше знают собственные навыки, ограничения и области, в которых зависят от коллег.
В своей практике я использую для этого «Звёздную карту». Она помогает сопоставить компетенции, необходимые для развития продукта, с теми, которые уже есть у команды. Так становятся заметны узкие места, высокая зависимость от одного специалиста и направления, в которых команде нужно развиваться.
Необязательно устранить все дисфункции и риски прямо на сессии. Но команда должна понимать, какие ограничения уже существуют и что она будет с ними делать.
В своей практике я использую для этого «Звёздную карту». Она помогает сопоставить компетенции, необходимые для развития продукта, с теми, которые уже есть у команды. Так становятся заметны узкие места, высокая зависимость от одного специалиста и направления, в которых команде нужно развиваться.
Необязательно устранить все дисфункции и риски прямо на сессии. Но команда должна понимать, какие ограничения уже существуют и что она будет с ними делать.
Договориться о совместной работе
Для этого можно использовать «Канву команды» (Team Canvas), но сам по себе заполненный шаблон ещё ничего не меняет.
Команде важно обсудить:
Часть ответов появится только после начала работы. Поэтому первые договорённости не нужно высекать в граните. Команда сможет уточнить их на ретроспективе, когда увидит, что действительно помогает, а что осталось красивой формулировкой на доске.
Команде важно обсудить:
- чего участники ожидают друг от друга;
- как будут принимать решения;
- как поступят, если не смогут договориться;
- где и как будут обсуждать рабочие вопросы;
- какие договорённости помогут не терять информацию;
- что каждый участник считает важным для нормальной совместной работы.
Часть ответов появится только после начала работы. Поэтому первые договорённости не нужно высекать в граните. Команда сможет уточнить их на ретроспективе, когда увидит, что действительно помогает, а что осталось красивой формулировкой на доске.
Согласовать рабочую среду и календарь событий Скрама
До начала первого спринта участники должны понимать, где находится бэклог продукта, в какой системе они будут вести работу, где хранится документация и каким каналом пользоваться для оперативной коммуникации.
Здесь же команда согласует продолжительность спринта и календарь событий Скрама с учётом часовых поясов, корпоративных ограничений и уже существующего ритма организации.
Это кажется технической частью запуска. Но если договорённости не появились, уже в первую неделю команда начинает выяснять, где искать актуальную информацию, почему половина людей не может присутствовать на ежедневном Скраме и в каком из трёх чатов было принято решение.
Здесь же команда согласует продолжительность спринта и календарь событий Скрама с учётом часовых поясов, корпоративных ограничений и уже существующего ритма организации.
Это кажется технической частью запуска. Но если договорённости не появились, уже в первую неделю команда начинает выяснять, где искать актуальную информацию, почему половина людей не может присутствовать на ежедневном Скраме и в каком из трёх чатов было принято решение.
Создать первоначальное определение готовности
Команде важно обсудить, что должно быть выполнено, чтобы результат можно было считать частью готового инкремента.
Если в организации уже существует обязательное определение готовности, команда принимает его как базовый минимум и при необходимости дополняет под свой продукт. Если общего стандарта нет, Скрам-команда создаёт первоначальную версию самостоятельно.
На первой сессии это определение редко получается окончательным. По мере работы команда увидит новые требования к качеству, тестированию, безопасности, документации и интеграции. Но начать спринт без общего понимания готового результата значит почти гарантированно получить несколько разных версий слова «сделано».
После этого установочная часть завершается. Если команда начинает первый спринт в тот же день, она переходит к планированию спринта.
Это важно не смешивать. Установочная сессия создаёт условия для совместной работы. На планировании спринта Скрам-команда уже обсуждает ценность предстоящего спринта, формулирует цель спринта, выбирает работу и определяет, как будет создан инкремент. В актуальной официальной версии Руководства по Скраму планирование спринта остаётся отдельным событием, которое инициирует спринт.
Качественная установочная сессия не обязана дать ответы на все будущие вопросы. Но к её завершению участники должны одинаково понимать, какой продукт они развивают, к какой цели движутся, какими компетенциями располагают, как будут работать вместе и что для них означает готовый результат.
Если в организации уже существует обязательное определение готовности, команда принимает его как базовый минимум и при необходимости дополняет под свой продукт. Если общего стандарта нет, Скрам-команда создаёт первоначальную версию самостоятельно.
На первой сессии это определение редко получается окончательным. По мере работы команда увидит новые требования к качеству, тестированию, безопасности, документации и интеграции. Но начать спринт без общего понимания готового результата значит почти гарантированно получить несколько разных версий слова «сделано».
После этого установочная часть завершается. Если команда начинает первый спринт в тот же день, она переходит к планированию спринта.
Это важно не смешивать. Установочная сессия создаёт условия для совместной работы. На планировании спринта Скрам-команда уже обсуждает ценность предстоящего спринта, формулирует цель спринта, выбирает работу и определяет, как будет создан инкремент. В актуальной официальной версии Руководства по Скраму планирование спринта остаётся отдельным событием, которое инициирует спринт.
Качественная установочная сессия не обязана дать ответы на все будущие вопросы. Но к её завершению участники должны одинаково понимать, какой продукт они развивают, к какой цели движутся, какими компетенциями располагают, как будут работать вместе и что для них означает готовый результат.
Именно с этой основой команда может переходить к первому спринту.
С каким результатом команда должна войти в первый спринт
По итогам подготовки и установочной сессии у команды не должно остаться иллюзии, что все вопросы решены. Но у неё должна появиться общая рабочая основа: понимание продукта и цели продукта, ближайшей работы, существующих зависимостей, правил взаимодействия и того, что будет считаться готовым результатом.
Часть этой основы Владелец продукта и Скрам-мастер готовят заранее. Часть команда обсуждает и уточняет на установочной сессии. Важно не происхождение каждого документа или договорённости, а то, понимают ли их участники одинаково и могут ли использовать в работе.
После установочной сессии команда переходит к планированию первого спринта. Она формулирует цель спринта, обсуждает, какие элементы бэклога продукта помогут её достичь, и определяет, как будет создан готовый инкремент.
При этом от первого спринта не стоит ждать высокой скорости и предсказуемости. Новая команда ещё не знает, насколько быстро сможет принимать решения, сколько времени займут внешние согласования и какие договорённости выдержат столкновение с реальной работой. Поэтому первый спринт становится продолжением запуска.
Он показывает:
Команда может договориться быстро обсуждать возникающие вопросы, а затем обнаружить, что часть решений принимается только за её пределами. Может согласовать определение готовности, но не суметь ему следовать из-за отсутствия тестовой среды. Может выбрать реалистичную цель спринта, но потерять её после нескольких срочных поручений сверху.
Это не обязательно означает, что запуск провален. Первый спринт нужен в том числе для того, чтобы увидеть расхождение между согласованной моделью работы и реальными условиями.
Поэтому качество запуска определяется не тем, насколько уверенно команда выглядела в день установочной сессии. Оно становится заметно, когда команда впервые пытается создать готовый инкремент, получить обратную связь и изменить свою работу на основании полученного опыта.
Часть этой основы Владелец продукта и Скрам-мастер готовят заранее. Часть команда обсуждает и уточняет на установочной сессии. Важно не происхождение каждого документа или договорённости, а то, понимают ли их участники одинаково и могут ли использовать в работе.
После установочной сессии команда переходит к планированию первого спринта. Она формулирует цель спринта, обсуждает, какие элементы бэклога продукта помогут её достичь, и определяет, как будет создан готовый инкремент.
При этом от первого спринта не стоит ждать высокой скорости и предсказуемости. Новая команда ещё не знает, насколько быстро сможет принимать решения, сколько времени займут внешние согласования и какие договорённости выдержат столкновение с реальной работой. Поэтому первый спринт становится продолжением запуска.
Он показывает:
- может ли Владелец продукта оперативно принимать решения;
- удаётся ли команде удерживать цель спринта;
- хватает ли ей компетенций для создания готового инкремента;
- какие зависимости действительно блокируют работу;
- работают ли командные договорённости за пределами общей сессии.
Команда может договориться быстро обсуждать возникающие вопросы, а затем обнаружить, что часть решений принимается только за её пределами. Может согласовать определение готовности, но не суметь ему следовать из-за отсутствия тестовой среды. Может выбрать реалистичную цель спринта, но потерять её после нескольких срочных поручений сверху.
Это не обязательно означает, что запуск провален. Первый спринт нужен в том числе для того, чтобы увидеть расхождение между согласованной моделью работы и реальными условиями.
Поэтому качество запуска определяется не тем, насколько уверенно команда выглядела в день установочной сессии. Оно становится заметно, когда команда впервые пытается создать готовый инкремент, получить обратную связь и изменить свою работу на основании полученного опыта.
Почему даже хороший запуск может не сработать
Даже качественная подготовка и хорошо проведённая установочная сессия не гарантируют, что согласованная модель работы выдержит столкновение с реальностью организации.
Команда может одинаково понимать цель продукта, договориться о правилах взаимодействия и сформулировать цель первого спринта. А через несколько дней получить несколько срочных задач от разных руководителей, каждая из которых «важнее всего остального».
В итоге цель спринта теряется, команда переключается между запросами, а причиной называют недостаток фокуса или незрелость участников. Хотя проблема возникла не внутри команды. Организация одновременно ожидает от неё самостоятельности и не оставляет возможности управлять собственной работой.
Команда может одинаково понимать цель продукта, договориться о правилах взаимодействия и сформулировать цель первого спринта. А через несколько дней получить несколько срочных задач от разных руководителей, каждая из которых «важнее всего остального».
В итоге цель спринта теряется, команда переключается между запросами, а причиной называют недостаток фокуса или незрелость участников. Хотя проблема возникла не внутри команды. Организация одновременно ожидает от неё самостоятельности и не оставляет возможности управлять собственной работой.
Сделать ограничение видимым ещё не означает его устранить
На установочной сессии команда может обнаружить, что для создания готового инкремента ей необходимо согласование службы безопасности, участие другого подразделения или доступ к среде, который выдаётся несколько дней. Это важный результат. Но если после сессии никто не меняет порядок взаимодействия, зависимость продолжает определять работу команды. Только теперь она аккуратно нарисована на доске. То же происходит с нехваткой компетенций. «Звёздная карта» может показать, что критически важная область знаний сосредоточена у одного специалиста или вообще находится за пределами команды. Однако один факт осознания не создаёт недостающую компетенцию. Нужен следующий шаг: изменение состава, обучение, передача знаний или новая договорённость со смежным подразделением.
Полномочия могут существовать только на словах
Владелец продукта может быть представлен команде как человек, принимающий решения о продукте. Но если каждый приоритет, изменение или отказ приходится согласовывать выше, в первом же спринте роль превращается в передаточное звено.
Команда задаёт вопрос, Владелец продукта уходит за решением, возвращается через несколько дней, а затем получает новый набор указаний. Формально все роли на месте. Работать в коротком цикле всё равно не получается.
Команда задаёт вопрос, Владелец продукта уходит за решением, возвращается через несколько дней, а затем получает новый набор указаний. Формально все роли на месте. Работать в коротком цикле всё равно не получается.
Командные договорённости могут не выдержать давления
На установочной сессии легко договориться открыто обсуждать проблемы, не брать работу сверх возможностей и соблюдать определение готовности. Сложнее следовать этим решениям, когда приближается срок, заинтересованные стороны требуют «хотя бы показать», а недоделанный результат предлагают считать почти готовым.
Это не делает договорённости бесполезными. Наоборот, именно в таких ситуациях становится понятно, какие из них действительно помогают команде, а какие были приняты слишком общо и требуют пересмотра.
Поэтому неудачный первый спринт не всегда означает, что установочная сессия была проведена плохо. Иногда она как раз выполнила свою задачу: помогла команде начать работу и сделала видимыми противоречия, которые до этого оставались скрытыми.
Проблема начинается тогда, когда эти противоречия объясняют только поведением команды. Её отправляют ещё раз договариваться, лучше планировать и «становиться самостоятельнее», хотя часть решений находится за пределами её полномочий.
Скрам-команда должна быть кросс-функциональной и самоуправляемой, но организация должна создать условия, в которых это возможно. Нельзя передать команде ответственность за результат, сохранив все значимые решения на других уровнях.
Хороший запуск не устраняет организационные противоречия за один день. Он помогает раньше их увидеть и перестать маскировать системные ограничения разговорами о недостаточной зрелости команды.
Именно поэтому после первого спринта работа Скрам-мастера не заканчивается. Она переходит от подготовки и проведения установочной сессии к сопровождению команды в реальной работе.
Это не делает договорённости бесполезными. Наоборот, именно в таких ситуациях становится понятно, какие из них действительно помогают команде, а какие были приняты слишком общо и требуют пересмотра.
Поэтому неудачный первый спринт не всегда означает, что установочная сессия была проведена плохо. Иногда она как раз выполнила свою задачу: помогла команде начать работу и сделала видимыми противоречия, которые до этого оставались скрытыми.
Проблема начинается тогда, когда эти противоречия объясняют только поведением команды. Её отправляют ещё раз договариваться, лучше планировать и «становиться самостоятельнее», хотя часть решений находится за пределами её полномочий.
Скрам-команда должна быть кросс-функциональной и самоуправляемой, но организация должна создать условия, в которых это возможно. Нельзя передать команде ответственность за результат, сохранив все значимые решения на других уровнях.
Хороший запуск не устраняет организационные противоречия за один день. Он помогает раньше их увидеть и перестать маскировать системные ограничения разговорами о недостаточной зрелости команды.
Именно поэтому после первого спринта работа Скрам-мастера не заканчивается. Она переходит от подготовки и проведения установочной сессии к сопровождению команды в реальной работе.
Что делает Скрам-мастер после запуска
После первого спринта у Скрам-мастера появляется материал, которого невозможно получить на установочной сессии: реальный опыт команды.
Теперь видно, как быстро Владелец продукта принимает решения, удаётся ли участникам удерживать цель спринта, какие зависимости действительно блокируют работу и что происходит с командными договорённостями под давлением сроков и срочных запросов.
Задача Скрам-мастера на этом этапе не в том, чтобы немедленно исправить всё за команду. Важно помочь участникам увидеть происходящее, отделить собственные решения от организационных ограничений и выбрать изменения, на которые команда действительно может повлиять.
Теперь видно, как быстро Владелец продукта принимает решения, удаётся ли участникам удерживать цель спринта, какие зависимости действительно блокируют работу и что происходит с командными договорённостями под давлением сроков и срочных запросов.
Задача Скрам-мастера на этом этапе не в том, чтобы немедленно исправить всё за команду. Важно помочь участникам увидеть происходящее, отделить собственные решения от организационных ограничений и выбрать изменения, на которые команда действительно может повлиять.
Вернуться к договорённостям на первой ретроспективе
«Канву команды» (Team Canvas), правила взаимодействия и определение готовности не должны остаться красивыми материалами с установочной сессии. На ретроспективе команда может проверить, что из согласованного действительно помогло, что оказалось нереалистичным, а о чём участники вообще забыли уже на второй день.
При этом ретроспектива не должна превращаться в регулярное перечисление проблем, на которые команда не может повлиять. Если участники не могут самостоятельно устранить ограничение, важно определить, кого привлечь, какое решение вынести на другой уровень и кто отвечает за следующий шаг. Иначе обсуждение системных проблем повторяется от встречи к встрече, но ничего не меняет в работе.
При этом ретроспектива не должна превращаться в регулярное перечисление проблем, на которые команда не может повлиять. Если участники не могут самостоятельно устранить ограничение, важно определить, кого привлечь, какое решение вынести на другой уровень и кто отвечает за следующий шаг. Иначе обсуждение системных проблем повторяется от встречи к встрече, но ничего не меняет в работе.
Помочь команде уточнять способы совместной работы
Первые договорённости почти всегда требуют изменений. Команда может обнаружить, что выбранного канала коммуникации недостаточно, решения теряются между встречами, ежедневный Скрам превратился в отчёт, а несогласие участники предпочитают обсуждать отдельно друг от друга.
Скрам-мастер помогает сделать эти паттерны видимыми и вернуть обсуждение команде. Его задача не написать идеальные правила, а создать условия, в которых участники смогут договариваться, проверять договорённости в работе и менять их на основании опыта.
Скрам-мастер помогает сделать эти паттерны видимыми и вернуть обсуждение команде. Его задача не написать идеальные правила, а создать условия, в которых участники смогут договариваться, проверять договорённости в работе и менять их на основании опыта.
Работать с зависимостями, а не только фиксировать их
Если создание инкремента регулярно останавливается из-за внешних согласований, отсутствующих доступов или решений другого подразделения, недостаточно добавить проблему в список препятствий.
Нужно понять, кто может изменить порядок взаимодействия, какие договорённости необходимы между командами и где потребуется участие руководителей или владельцев организационных процессов.
Часть препятствий Скрам-мастер помогает устранить напрямую. В других случаях его работа состоит в том, чтобы сделать влияние ограничения понятным для тех, кто обладает необходимыми полномочиями.
Нужно понять, кто может изменить порядок взаимодействия, какие договорённости необходимы между командами и где потребуется участие руководителей или владельцев организационных процессов.
Часть препятствий Скрам-мастер помогает устранить напрямую. В других случаях его работа состоит в том, чтобы сделать влияние ограничения понятным для тех, кто обладает необходимыми полномочиями.
Следить за развитием компетенций внутри команды
Первый спринт показывает не только формальный состав команды, но и реальное распределение знаний. Может оказаться, что без одного участника работа останавливается, критически важную часть продукта понимает только внешний специалист, а отдельные компетенции существуют скорее в штатном расписании, чем в команде.
В зависимости от ситуации команда может договориться о совместной работе, передаче знаний, обучении или привлечении недостающей экспертизы. «Звёздная карта» при этом становится не результатом разового упражнения, а инструментом, к которому можно возвращаться по мере развития продукта и команды.
В зависимости от ситуации команда может договориться о совместной работе, передаче знаний, обучении или привлечении недостающей экспертизы. «Звёздная карта» при этом становится не результатом разового упражнения, а инструментом, к которому можно возвращаться по мере развития продукта и команды.
Помогать Владельцу продукта развивать бэклог
Первоначальный бэклог, с которым команда вошла в первый спринт, неизбежно меняется. Появляется обратная связь, уточняются пользовательские сценарии, часть гипотез не подтверждается, а некоторые элементы теряют актуальность.
Скрам-мастер не принимает продуктовые решения вместо Владельца продукта. Но он может помочь выстроить работу с бэклогом так, чтобы ближайшие элементы были понятны команде, сохраняли связь с целью продукта и регулярно уточнялись совместно, а не передавались разработчикам как готовое техническое задание.
Скрам-мастер не принимает продуктовые решения вместо Владельца продукта. Но он может помочь выстроить работу с бэклогом так, чтобы ближайшие элементы были понятны команде, сохраняли связь с целью продукта и регулярно уточнялись совместно, а не передавались разработчикам как готовое техническое задание.
Не требовать мгновенной предсказуемости
Новой команде нужно время, чтобы накопить общий опыт. Это касается и планирования, и понимания собственных возможностей, и оценки элементов бэклога.
По моему практическому наблюдению, команде часто требуется три или четыре спринта, чтобы увереннее сравнивать объём и сложность работы. Это не правило Скрама и не срок, к которому команда обязана начать выдавать стабильные цифры.
Одни команды используют относительную оценку, другие опираются на иные способы прогнозирования. Важнее не выбранная шкала, а способность обсуждать работу, видеть неопределённость и принимать более обоснованные решения на основании накопленных данных.
Запуск команды заканчивается не тогда, когда закрыта установочная сессия и сохранены все доски. Он заканчивается, когда команда начинает использовать реальный опыт для изменения своей работы, а Скрам-мастер помогает ей видеть не только происходящее внутри, но и условия, которые создаёт организация.
Именно поэтому роль Скрам-мастера нельзя свести к проведению событий Скрама и набору фасилитационных упражнений. Ему приходится одновременно работать с продуктом, групповой динамикой, конфликтами, зависимостями и организационными ограничениями. И каждый раз решать, где достаточно задать команде хороший вопрос, а где проблему нужно выносить за её границы.
По моему практическому наблюдению, команде часто требуется три или четыре спринта, чтобы увереннее сравнивать объём и сложность работы. Это не правило Скрама и не срок, к которому команда обязана начать выдавать стабильные цифры.
Одни команды используют относительную оценку, другие опираются на иные способы прогнозирования. Важнее не выбранная шкала, а способность обсуждать работу, видеть неопределённость и принимать более обоснованные решения на основании накопленных данных.
Запуск команды заканчивается не тогда, когда закрыта установочная сессия и сохранены все доски. Он заканчивается, когда команда начинает использовать реальный опыт для изменения своей работы, а Скрам-мастер помогает ей видеть не только происходящее внутри, но и условия, которые создаёт организация.
Именно поэтому роль Скрам-мастера нельзя свести к проведению событий Скрама и набору фасилитационных упражнений. Ему приходится одновременно работать с продуктом, групповой динамикой, конфликтами, зависимостями и организационными ограничениями. И каждый раз решать, где достаточно задать команде хороший вопрос, а где проблему нужно выносить за её границы.
Готовый сценарий помогает провести установочную сессию. Но он не подскажет, что делать, когда договорённости команды сталкиваются с реальной работой и ограничениями организации.
В Школе Скрам-мастеров участники учатся готовить запуск команды и сопровождать первые спринты: разбирать рабочие ситуации, видеть, когда причина трудностей находится не только в процессе, но и в командной динамике или устройстве организации, и выбирать действия с учётом контекста.
Посмотреть программу Школы →
В Школе Скрам-мастеров участники учатся готовить запуск команды и сопровождать первые спринты: разбирать рабочие ситуации, видеть, когда причина трудностей находится не только в процессе, но и в командной динамике или устройстве организации, и выбирать действия с учётом контекста.
Посмотреть программу Школы →
Автор статьи
Анастасия Бутова-Никишина
Организационный консультант, основатель «Лаборатории ПроЛидеров» / ProLeadersLab®.
Более 10 лет работает с командами, провела свыше 100 запусков и перезапусков. Автор программы Школы Скрам-мастеров и Модели четырёх полей устойчивости команды 4FMTR
Анастасия Бутова-Никишина
Организационный консультант, основатель «Лаборатории ПроЛидеров» / ProLeadersLab®.
Более 10 лет работает с командами, провела свыше 100 запусков и перезапусков. Автор программы Школы Скрам-мастеров и Модели четырёх полей устойчивости команды 4FMTR