Agile-трансформация
Beyond Budgeting
DevOps
HR
Kanban
LeSS
PMI
Project management
SAFe
Scrum
Scrum-мастер
Бюджетирование
Игра
Конфликты
Обучение
Фасилитация
Применить

Совместное планирование

Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 1

lego1

Перевод книги Henrik Kniberg и Eik Thyrsted Brandsgård «Planning as a Social Event» выполнен с разрешения авторов.

Масштабирование Agile в компании LEGO
Хенрик Книберг и Тирстед Брэндсгард
Декабрь 2016

— Что? Встреча на 150 человек на целых 2 целый день?
— Конечно! Каждый второй месяц. И работает отлично.
— Но зачем? И как?

Предыстория

LEGO Digital Solutions (DS) — это группа из 20 или около того команд, отвечающих за выстраивание коммуникаций с детьми и родителями посредством компьютеров, планшетов, приложений, носимой электроники, VR или других устройств, которые они используют. А еще мы заглядываем в будущее наших продуктов и придумываем, как внедрить новые технологии и как улучшить классический способ играть, добавив в него что-то крутое, типа дополненной реальности или сканирования физических моделей с их последующим переносом в игру на вашем устройстве. Большинство наших команд расположены в городе Биллунд в Дании, но есть также группа команд, находящихся в Индии.

lego2

Вообще LEGO не является IT-компанией. Это 80-летняя организация, в которой 17000 человек трудятся над проектированием, производством и маркетингом физических игрушек. Как и большинство организаций, LEGO пытается адаптироваться к ускоряющемуся темпу цифрового мира — мира, где изменения постоянны, а Agile-разработка становится нормой.

Digital Solutions находится на передовой подобных изменений в LEGO, и это очень интересное путешествие, которым мы хотим поделиться с вами.

Проблема

В те времена, когда у нас было всего 5 команд разработки, планирование и синхронизация работ были довольно просты и управляемы. Команды и Владельцы Продуктов могли просто поговорить друг с другом и решить, что делать. Однако, когда мы выросли до 15-20 команд, все стало гораздо сложнее.

У LEGO в целом довольно хорошие процессы управления портфелями проектов и бюджетирования. Инвестирование обсуждается и выделяется на годовой основе (X часов для проекта Y), а фактические решения по конкретному проекту отделены от финансовых решений, поэтому департаменты могут быть довольно гибкими в управлении своими затратами.

Таким образом, в 2014 году у нас было стабильное управление портфелями проектов на верхнем уровне и 15-20 команд, работающих спринтами по Скраму. Проблема же была посередине — на уровне программы!

lego3

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

Или к вам, владельцу продукта платформы, одновременно приходят запросы от 10 человек, но вы физически не можете сразу взять их все в работу. И как вы решите, что важнее? В нашем случае это порой приводило к тому, что команды разрабатывали идентичные решения в стиле: «Хм, а почему бы нам не сделать в дополнение к пяти существующим каруселям еще и американские горки? Хорошего ведь много не бывает, правда?»

В итоге, нашими основными сложностями были:

  • Межкомандное согласование — как направить движение команд в одном направлении вместо того, чтобы бежать, спотыкаясь друг о друга.
  • Сотрудничество с клиентом — как установить реалистичные ожидания и удовлетворять клиентов без переоценки.
  • Планирование релизов — как планировать и приоритезировать работу на несколько параллельных спринтов, несколько команд и несколько продуктов.
  • Разработка платформы — как убедиться, что мы инвестируем в будущее, а не просто реализуем кучу одноразовых решений.

И в конце 2014 мы решили попробовать что-то другое.

Перемены

В январе 2015 мы набрались смелости и начали перестройку. Мы переделали структуру Digital Solutions в плоскую, ввели общие каденции спринтов, децентрализованную синхронизацию и управление зависимостями, а еще — общее планирование каждые 8 недель. Эти меры дали очень позитивный эффект, причем не только для DS, но и для смежных департаментов.

Давайте же посмотрим, чего мы добились за 1.5 года наших экспериментов.

Предупреждение: Наше путешествие еще не закончено, мы продолжаем совершенствовать наш подход — например, к концу 2016 года мы уменьшили продолжительность сессии общего планирования с 2 дней до 1. Заманчиво постоянно обновлять данную статью, но тогда я никогда ее не закончу, поэтому ниже представлено состояние дел на середину 2016 года.

Обзор совместного планирования

Сейчас утро среды и вас пригласили на загадочное событие «PI-планирование», о котором все только и говорят. Вы знаете, что оно расшифровывается как «Планирование Инкремента Программы» (прим. ред. Product Increment Planning, PI Planning) и что это какое-то планирование, проходящее каждые 8 недель. Вы входите в большой зал и видите:

lego4

Шучу-шучу… На самом деле вы видите подобную картину:

lego5

Осмотревшись, вы замечаете, что тут присутствуют все команды разработки DS, руководители, множество клиентов и заинтересованных лиц, а также горстка таких же любопытствующих посетителей, как и вы. А на столе лежит вот такая программа:

lego6

Время демонстрации!

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

lego7

Это видео не заменяет обратную связь, изо дня в день получаемую командами на демонстрации спринтов, по результатам пользовательских тестов и тому подобного, но дает хороший обзор и мотивирует. Оно напоминает всем о том, что мы делаем и для чего.

Выступления

Далее слово берет руководитель и за несколько минут рассказывает, что происходит сейчас и какие важные вещи нас ждут впереди. После него выступают еще несколько человек с короткими вдохновляющими речами на такие темы как цифровая безопасность для детей, предстоящий хакатон, стратегия развития платформы и другие актуальные вопросы. Кто-то демонстрирует, насколько проще стало выпускать функционал используя новую платформу, кто-то запускает веселую, но незатейливую Kahoot-викторину.

lego8

К середине утра общая часть завершается, и во время перерыва на кофе участники оценивают каждое выступление на доске обратной связи по шкале от 1 до 5.

— Джо: «Смотри, одни 4-ки и 5-ки! Гораздо лучше, чем в прошлый раз».
— Лиза: «Да, кроме этого четвертого выступления. Тьфу!»
— Джо: «Ага, оно было интересно от силы десятку человек. Лично я уснул».

Рядом с оценками можно увидеть небольшие комментарии о том, как можно было бы улучшить выступления в следующий раз. Несколько людей спорят, насколько вообще нужны эти разговоры и не лучше бы в следующий раз сразу приступить к планированию.

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

Это только первая часть книги. В следующей серии вы узнаете, как без жертв провести совместное планирование работ 150 человек. Модификация инструментов SAFe и конкретные рекомендации Хенрика Книберга. Продолжение следует…

12 сен 2017, Сергей Рогачев
Тренинги по теме
Другие статьи
Как построить карьеру скрам-мастера
4 сен 2017, Иван Селеверстов
Cкрам-мастер. Обучение и карьера

Scrum был и остается самым популярным фреймворком в Agile. И успех его внедрения во многом зависит от роли скрам-мастера. Если судить по вакансиям, опубликованным на job-сайтах, спрос на них с каждым годом растет. По мере того как меняется организация, происходит масштабирование Agile в компании, меняются и требования к скрам-мастеру и его роли.

version_one_blog
23 авг 2017, Сергей Рогачев
11-й ежегодный отчет State of Agile

ScrumTrek подготовил официальный перевод на русский язык ежегодного опроса State of Agile.

21621867[1]
27 июл 2017, Сергей Рогачев
Глоссарий SAFe 4.0

На днях Scaled Agile опубликовали русский перевод глоссария терминов SAFe 4.0. А мы предлагаем вам альтернативный вариант.