Основные трудности в освоении Скрама возникают при фасилитации событий. Особенно сложны кейсы масштабируемого Скрама, когда Scrum Teams с общим Product Owner разрабатывают один продукт. В статье детально описываем кейс Sprint Planning в Nexus из 8-ми команд. Статья полезна всем, кто имеет отношение к масштабируемой разработке в Скраме.
Контекст
В продуктовой группе из 60+ человек работают 8 команд, используя фреймворк Nexus. У команд общий Product Owner и Product Backlog. К сожалению, команды не кросс-функциональны на 100%, между ними существуют зависимости, в том числе, от внешних поставщиков.
Организационный дизайн отражен на рис. 1.1 и это пример профессионального масштабируемого Скрама:
Если Scrum Teams становятся слишком большими, участникам следует рассмотреть возможность реорганизации в несколько сплоченных Scrum Teams, каждая из которых сфокусирована на одном и том же продукте. Следовательно, у них должна быть та же Product Goal, тот же Product Backlog, тот же Product Owner (Руководство по Скраму, 2020).
Планирование Спринта в Nexus
Концептуально Sprint Planning в масштабируемом Скраме остается тем же. В таблице событие показано в разрезе эмпирического контроля.
Цель — создание плана координации между командами в Спринте для достижения Nexus Sprint Goal. Для этого создается совместный верхнеуровневый план работ (Nexus Sprint Backlog) с визуализацией зависимостей и индивидуальные планы команд (Sprint Backlogs).
Поиск Nexus Sprint Goal #1 (20 мин)
Мы пригласили Scrum Teams в большой амфитеатр и начали с обсуждения агенды и цели события. Ответив на несколько уточняющих вопросов, приступили к основной части.
Накануне мы попросили Product Owner подумать о возможных целях на Спринт (business objective). Он предложило командам три варианта, объяснив их важность и связь с Product Goal. Во время открытой дискуссии выяснилось, что две являются подцелями третьей. Scrum Master помогал фасилитировать дискуссию и вел записи на флип-чарте.
Формулировка командных целей на Спринт #2 (30 мин)
Мы предложили командам, принимая во внимание Nexus Sprint Goal и текущее состояние Product Backlog, сформулировать командные цели и верхнеуровневые задачи (forecast). Мы дали 20 мин и команды разошлись выполнять задание по своим станциям.
Во время упражнения Scrum Masters (3 на 8 команд) перемещались между командами, подсказывая, направляя и стимулируя взаимодействие. Три команды поставить себе общую Sprint Goal.
Создание дерева целей #3 (20 мин)
Вернувшись в амфитеатр, мы попросили представителей команд представить сформулированные цели и визуализировать связи между ними и Nexus Sprint Goal в виде дерева на магнитной доске.
Во время представления выявились новые взаимозависимости четыре Sprint Goal были помечены значками восклицательных знаков. Договорились их уточнить после детального планирования на уровне команд.
Создание командных Sprint Backlog(s) #4 (60 мин)
Перед тем, как отправить команды на детальное планирование, мы напомнили им о том, что:
- На выходе у них должен быть Sprint Backlog.
- По выявлении зависимостей они могут синхронизироваться с другими командами в течение часа.
- Можно обновлять и переформулировать Sprint Goal.
- Нужно поместить прогноз на Nexus Sprint Backlog.
Scrum Masters перемещались между станциями, помогая командам. Мы наблюдали за тем, как три команды “расшивали” вместе зависимости в течение получаса, и только после этого разошлись по своим станциям. Также мы стали свидетелями того, как неожиданно четыре команды объединились в Спринте под одной Sprint Goal. Самоорганизация в действии нас приятно удивила!
Создание Nexus Sprint Backlog и уточнение целей #5 (10 мин)
Через час мы снова встретились в общем пространстве, чтобы перейти к финальной части планирования. Представители команд перенесли прогноз на Спринт на общий для продуктовой группы артефакт, который в Nexus называется Nexus Sprint Backlog. Он представляет верхнеуровневый план работ команд в едином месте с визуализаций зависимостей. Мы использовали такую агенду для визуализации зависимостей.
Команды зачитали обновленные Sprint Goals(s). И, как вишенка на торте, проголосовали за достижение общей Цели Спринта точками на флип-чарте. Итого, Планирование Спринта на 8 команд заняло у нас 3 ч. 20 мин.
Факторы успеха
Анализируя прошедшее событие, мы выделяем несколько факторов, которые влияют успешность Sprint Planning:
- Качественный
- Cross-Team Refinement (PBR)
- , который приводит к тому, что верхушка Product Backlog находится в состоянии ready.
- Правильное и достаточно широкое определение продукта (закрывает потребности рынка, имеет покупателя/пользователя за границами организации, PnL)
- Product Owner представитель бизнеса (в нашем случае CEO), понимающий рынок, отвечающий на стратегию и видение, продукта, PnL/ROI.
- Качественная фасилитация больших групп.
- Тщательная подготовка (план, визуализация, координация между Scrum Masters).
Надеюсь, что такое детальное описание фасилитации Sprint Planning было вам полезно и вы что-то вынесли для себя. Удачных вам фасилитаций!
Scrum ON!
