Large Scaled Scrum (LeSS), как и Scrum, не предписывает вам практически ничего. Это легкий каркас, который позволяет вам добавить в него только то, что вам нужно.
В LeSS все, что вы добавляете от себя, называется экспериментом. Лично мне очень нравится такое название, потому что, как и любой эксперимент, ваш может быть или удачным, или нет. Фактически это готовит команду психологически к возможной неудаче и изменениям процесса. Классический Inspect & Adapt :)
Одним из экспериментов, которые я проводил в крупном стартапе, было общее планирование в 14 команд. Этот подход известен из Scaled Agile Framework (SAFe) под название Product Increment Planning.
Контекст и структура организации
Для понимания проблемы, которую мы решали, следует понимать контекст структуры компании.
На тот момент у нас было 5 tribes, всего 14 команд по всех tribes. Мы использовали каркас LeSS Huge.
Он отлично ложился на тот продукт, который компания разрабатывает. В итоге работы всех 14-ти команд получается один marketable продукт. Проблемой, которую мы решали, была синхронизация всех со всеми в отношении целей.
Так как продукт - “коробочное решение”, которое устанавливается клиенту on-premise, у нас нет необходимости выпускать систему очень часто. Наш релиз-цикл — квартал.
Что бы синхронизировать всех между собой и построить общий план реализации, мы решили попробовать провести эксперимент — сделать общее планирование всех со всеми, как в SAFe.
Product Increment Planning
Немного теории. PI Planning — это встреча в SAFe, в процессе которой ряд команд, вытягивая (pull) задачи с общего беклога, планируют их выполнение в многих командах. Такая встреча проводится раз в квартал (или другой релиз-цикл).
В нашем случае, такая встреча длится 2 дня и проходит по следующему примерному плану:
День 1. Ретроспектива и первичный Refinement
10:00–10:30 Вступительное слово. Ревью результатов пошлого релиза
10:30–12:00 Ретроспектива прошлого релиза
12:00–13:00 Презентация Scope текущего релиза, приоритеты
14:00–18:00 Работа в командах, PBR
18:00–18:30 Синхронизация работы команд
День 2. Актуализация плана, осознание рисков
10:00–11:30 Confidence Voting
11:00–13:00 Работа в командах, PBR
14:00–16:00 Plan Review
16:00–18:00 Закрытие планирования, презентация работы рабочих групп.
Вводная информация (до начала PI Planning)
Что должно быть готово, чтобы сделать планирование эффективным? Feature, которые будут разобраны на планировании, предварительно рассматриваются командами. То есть на планировании они не первый раз их видят.
Готовимся к сессии планирования, делаем пре-планирование фокус-группой
По некоторым из них делаются Proof of Concepts (прототипы), по другим — есть high-level декомпозиция.
Know your backlog!
В многом эффективность планирования зависит от подготовленности команд. Потому мы начинаем готовится заранее.
День 1. Ретроспектива и первичный Refinement
Наше планирование мы начинаем сессии общего осознания “где мы есть”. То есть с презентации бизнеса о наших достижениях с прошлого раза.
CTO компании говорит о новой визии для инжиниринговой команды
Ретроспектива
После вступительного слова мы начинаем сессию “Inspect & Adapt" — делаем глобальную ретроспективу в 14 команд. Да, это звучит сложно, но на деле все происходит просто:
Все люди разделяются на команды, в которых и работают.
Каждая команда находит себе место в офисе, проводит ретро в течение часа. Обсуждается процесс командного и межкомандного взаимодействия. Мы используем шаблон Start-Stop-Continue.
Голосование, выбор топиков, которые команда хочет вынести на общее обсуждение.
Сбор в главном холле, формирование доски с топиками
Далее те проблемы, которые в колонке "Stop" и те инициативы, которые в колонке "Start" приоритизируются представителями (делегатами) от команд. Выбираются от 1 до 3 проблем/инициатив, над которыми будет работать отдельная группа. На данном этапе они паркуются, мы вернемся к ним позже.
Презентация бэклога следующего релиза продукта
После небольшого перерыва, мы начинаем сессию планирования нашего Backlog Refinement на следующие 2 дня. Фактически идет презентация беклога, который бизнес хотел бы сделать за следующие 3 месяца.
Product Owner презентует самую приоритетную задачу в следующем релизе
Обычно, мы делаем сессию приоритизации беклога на месте. То есть Chief Product Owner фактически при всех выставляет задачи в очередность выполнения.
Внимание! В беклог для планирование попадают не только бизнес Features, но и технические идеи и наши задачи с ретроспективы.
Планирование Планирования
Итак, после бизнес-контекста, приоритетов, нам необходимо приступать к Product Backlog Refinement. Для этого нам нужно иметь беклог на карточках или стикерах, где-то на стене.
Рядом с беклогом делаем календарь. По горизонтали в календаре — названия точек для проведения PBR, это могут быть переговорки, офисные спейсы или другое. По вертикали — таймслоты, в которых будет идти работа. Должно выйти что то похожее:
Дальше отдаем все на откуп самоорганизации. Важно: на время планирования у них нет команд. То есть Features могут обсуждаться многими командами вместе. Мы создаем "Feature Group" — объединение представителей команд для совместного refinement. То есть люди должны сами решить, кто им нужен для обсуждения той или иной задачи, и выбрать, где именно будет проходить это обсуждение.
Такой календарик нужен для простой навигации: если вы хотите подключится к какой-либо группе, вы просто находите их по календарю.
Обычно после планирования мы делаем обед, чтобы было время выбрать, кто куда будет присоединяться.
Product Backlog Refinement
Работа начинается прямо после обеда. Процесс строится спринтами, длина спринта — 2 часа.
Работа над беклогом в группах в разных частях офиса
По прошествии 2 часов команды делают общую синхронизацию в большом холле, где размещена план-доска релиза.
Визуализация общего плана релиза. Команды добавляют свои User Stories и технические задачи на общую доску.
До конца дня мы делаем 2 спринта, периодически выполняя синхронизацию работы, и собираем предварительный план.
На доске каждая строчка — это команда, колонки — спринты. То есть команда делает Forecast в каких спринтах какие задачи они сделают. Общий план должен визуализировать все задачи, которые должны быть выполнены, что бы сделать релиз успешным.
День 2. Актуализация плана, осознание рисков
Второй день мы классически начинаем с очень важного упражнения: Confidence voting. Это простая проверка, на сколько реалистичен план.
Как это делается: мы собираем всех вместе и просим поднять руку и на пальцах показать, на сколько они верят в реалистичность этого плана, от 1 до 5. Таким образом, мы проверяем, не делают ли люди план ради плана, не веря в его реалистичность.
После Confidence voting. Chief Product Owner (в центре). Обсуждаем, что убирать, потому что средний confidence 2.5
Тут возможна реальная реприоритизация. В последний раз, мы отсекли половину изначального плана. Это окей, и общая доска дает понять, почему больше не влезет. С визуализированным общим планом сложно спорить.
На последнем PI так и получилось: план, который построили в первый день, фактически был составлен, чтобы порадовать бизнес, но не имел ничего общего с реальностью. Мы тут же совместно договорились, что необходимо убрать все лишнее.
Думаем, что нужно убрать, что бы стало реалистично
Далее, до обеда, мы занимались актуализаций плана.
Plan Review
После обеда мы делаем еще одно голосование, теперь средний балл 4.5, что значит, что команды верят в то, что это реально сделать.
Для более точной проверки мы делаем командный ревью плана — проходимся по каждой команде и ищем зависимости, неточности. Так же, мы просматриваем доску рисками и Impediments, разбираемся, что с ними делать, кто будет ответственный.
Эта часть занимает, по меньшей мере, 2 часа. Тут сложно держать общую вовлеченность, советую экспериментировать с техниками фасилитации.
Закрытие планирования. Презентация рабочих групп
Как вы помните, не только бизнес-задачи планируются. У нас есть еще технические улучшения и follow-up ретроспективы. Под эти задачи, так же как и под бизнес-задачи, собираются рабочие группы (волонтерские). В конце планирования я отвожу 2 часа на общий Inspect & Adapt по инженерии и топикам ретроспективы.
Мы презентуем командам, какие поинты мы хотим улучшить в следующем релизе, какие новые договоренности мы хотим внести. Команды могут внести изменения в результаты работы групп.
На этом все, планирование закончено. Команды уходят с беклогами. Стена остается в офисе, по ней отслеживается прогресс.
Приятных вам планирований!
Commentaires