Product Increment Planning как эксперимент в LeSS | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

Product Increment Planning как эксперимент в LeSS

28 Feb 2019

Large Scaled Scrum (LeSS), как и Scrum,  не предписывает вам практически ничего. Это легкий каркас, который позволяет вам добавить в него только то, что вам нужно.

В LeSS все, что вы добавляете от себя, называется экспериментом. Лично мне очень нравится такое название, потому что, как и любой эксперимент, ваш может быть или удачным, или нет. Фактически это готовит команду психологически к возможной неудаче и изменениям процесса. Классический Inspect & Adapt :)

Одним из экспериментов, которые я проводил в крупном стартапе, было общее планирование в 14 команд. Этот подход известен из Scaled Agile Framework (SAFe) под название Product Increment Planning.

Контекст и структура организации

Для понимания проблемы, которую мы решали, следует понимать контекст структуры компании.

Alt Text

На тот момент у нас было 5 tribes, всего 14 команд по всех tribes. Мы использовали каркас LeSS Huge.

Alt Text

Он отлично ложился на тот продукт, который компания разрабатывает. В итоге работы всех 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, которые будут разобраны на планировании, предварительно рассматриваются командами. То есть на планировании они не первый раз их видят.

Alt Text Готовимся к сессии планирования, делаем пре-планирование фокус-группой

По некоторым из них делаются Proof of Concepts (прототипы), по другим  —  есть high-level декомпозиция.

Know your backlog!

В многом эффективность планирования зависит от подготовленности команд. Потому мы начинаем готовится заранее.

День 1. Ретроспектива и первичный Refinement

Наше планирование мы начинаем сессии общего осознания “где мы есть”. То есть с презентации бизнеса о наших достижениях с прошлого раза.

Alt TextCTO компании говорит о новой визии для инжиниринговой команды

Ретроспектива

После вступительного слова мы начинаем сессию “Inspect & Adapt" —  делаем глобальную ретроспективу в 14 команд. Да, это звучит сложно, но на деле все происходит просто:

  1. Все люди разделяются на команды, в которых и работают.
  2. Каждая команда находит себе место в офисе, проводит ретро в течение часа. Обсуждается процесс командного и межкомандного взаимодействия. Мы используем шаблон Start-Stop-Continue.
  3. Голосование, выбор топиков, которые команда хочет вынести на общее обсуждение.
  4. Сбор в главном холле, формирование доски с топиками

Далее те проблемы, которые в колонке "Stop" и те инициативы, которые в колонке "Start" приоритизируются представителями (делегатами) от команд. Выбираются от 1 до 3 проблем/инициатив, над которыми будет работать отдельная группа. На данном этапе они паркуются, мы вернемся к ним позже.

Презентация бэклога следующего релиза продукта

После небольшого перерыва, мы начинаем сессию планирования нашего Backlog Refinement на следующие 2 дня. Фактически идет презентация беклога, который бизнес хотел бы сделать за следующие 3 месяца.

Alt TextProduct Owner презентует самую приоритетную задачу в следующем релизе

Обычно, мы делаем сессию приоритизации беклога на месте. То есть Chief Product Owner фактически при всех выставляет задачи в очередность выполнения.

Внимание! В беклог для планирование попадают не только бизнес Features, но и технические идеи и наши задачи с ретроспективы.

Планирование Планирования

Итак, после бизнес-контекста, приоритетов, нам необходимо приступать к Product Backlog Refinement. Для этого нам нужно иметь беклог на карточках или стикерах, где-то на стене.

Рядом с беклогом делаем календарь. По горизонтали в календаре  —  названия точек для проведения PBR, это могут быть переговорки, офисные спейсы или другое. По вертикали  —  таймслоты, в которых будет идти работа. Должно выйти что то похожее:

Alt Text

Дальше отдаем все на откуп самоорганизации. Важно:  на время планирования у них нет команд. То есть Features могут обсуждаться многими командами вместе. Мы создаем "Feature Group"  —  объединение представителей команд для совместного refinement. То есть люди должны сами решить, кто им нужен для обсуждения той или иной задачи, и выбрать, где именно будет проходить это обсуждение.

Alt Text

Такой календарик нужен для простой навигации:  если вы хотите подключится к какой-либо группе, вы просто находите их по календарю.

Alt Text

Обычно после планирования мы делаем обед, чтобы было время выбрать, кто куда будет присоединяться.

Product Backlog Refinement

Работа начинается прямо после обеда. Процесс строится спринтами, длина спринта  —  2 часа.

Alt TextРабота над беклогом в группах в разных частях офиса

По прошествии 2 часов команды делают общую синхронизацию в большом холле, где размещена план-доска релиза.

Alt TextВизуализация общего плана релиза. Команды добавляют свои User Stories и технические задачи на общую доску.

До конца дня мы делаем 2 спринта, периодически выполняя синхронизацию работы, и собираем предварительный план.

На доске каждая строчка  —  это команда, колонки  —  спринты. То есть команда делает Forecast в каких спринтах какие задачи они сделают. Общий план должен визуализировать все задачи, которые должны быть выполнены, что бы сделать релиз успешным.

День 2. Актуализация плана, осознание рисков

Второй день мы классически начинаем с очень важного упражнения: Confidence voting. Это простая проверка, на сколько реалистичен план.

Как это делается: мы собираем всех вместе и просим поднять руку и на пальцах показать, на сколько они верят в реалистичность этого плана, от 1 до 5. Таким образом, мы проверяем, не делают ли люди план ради плана, не веря в его реалистичность.

Alt TextПосле Confidence voting. Chief Product Owner (в центре). Обсуждаем, что убирать, потому что средний confidence 2.5

Тут возможна реальная реприоритизация. В последний раз, мы отсекли половину изначального плана. Это окей, и общая доска дает понять, почему больше не влезет. С визуализированным общим планом сложно спорить.

На последнем PI так и получилось:  план, который построили в первый день, фактически был составлен, чтобы порадовать бизнес, но не имел ничего общего с реальностью. Мы тут же совместно договорились, что необходимо убрать все лишнее.

Alt TextДумаем, что нужно убрать, что бы стало реалистично

Далее, до обеда, мы занимались актуализаций плана.

Plan Review

После обеда мы делаем еще одно голосование, теперь средний балл 4.5, что значит, что команды верят в то, что это реально сделать.

Для более точной проверки мы делаем командный ревью плана  —  проходимся по каждой команде и ищем зависимости, неточности. Так же, мы просматриваем доску рисками и Impediments, разбираемся, что с ними делать, кто будет ответственный.

Эта часть занимает, по меньшей мере, 2 часа. Тут сложно держать общую вовлеченность, советую экспериментировать с техниками фасилитации.

Закрытие планирования. Презентация рабочих групп

Как вы помните, не только бизнес-задачи планируются. У нас есть еще технические улучшения и follow-up ретроспективы. Под эти задачи, так же как и под бизнес-задачи, собираются рабочие группы (волонтерские). В конце планирования я отвожу 2 часа на общий Inspect & Adapt по инженерии и топикам ретроспективы.

Мы презентуем командам, какие поинты мы хотим улучшить в следующем релизе, какие новые договоренности мы хотим внести. Команды могут внести изменения в результаты работы групп.

Alt Text

На этом все, планирование закончено. Команды уходят с беклогами. Стена остается в офисе, по ней отслеживается прогресс.

Приятных вам планирований!

Если вам интересна тема Agile в больших организациях, welcome на мой авторский курс Transition to Agile Enterprise, который пройдет в Киеве 23-25 мая!

Рекомендовані заходи

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Дмитро Незабитовський, Олександр Червінський  

Decomposition for Agile Teams – це двомодульний, 12-годинний тренінг-інтенсив для охочих докладно розібратися в інструментах декомпозиції, оцінки та пріоритезування елементів для використання у своїх Agile командах. Після закінчення навчання ви отримаєте іменний сертифікат з унікальним номером, англійською мовою – "Decomposition for Agile T...

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

Рекомендовані статті

Скільки коштують ваші зустрічі? Та як не втрачати гроші.

Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …

Top 5 питань про Agile Retrospectives

Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

Чому коучинговий підхід актуальний у бізнесі?

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

©2017 - 2024 Scrum Ukraine. Всі права захищені.

Політика конфіденційності