Все статьи

Сергей Рогачев

Генеральный директор «Лидеры изменений», Agile-коуч, эксперт в Agile-трансформации крупных компаний.

Развивает SAFe® и OKR в России, продюсер исследования «Agile в России», конференций Enterprise Agile Russia и OKR Russia. Публичные кейсы: Монитор Электрик, РТЛабс, Газпром нефть, ХМАО, HeadHunter, Главстрой, Xsolla, Администрация города Саратов, Билайн, DSSL и Сбербанк.

Подробнее

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

Дата: 12.09.2017

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

Оглавление

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

Предыстория

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

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

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

Проблема

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

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

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

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

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

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

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

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

Перемены

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

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

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

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

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

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

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

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

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

Выступления

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

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

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

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

Один из ведущих обращается к вам:

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

Автор:

Поделиться

VK
Telegram

Масштабирование Agile по SAFe®

Тренинг Leading SAFe® призван помочь крупным компаниям и быстро растущим командам справиться с проблемами синхронизации, возникающими вследствие сложной структуры, большого числа проектов и продуктов. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Agilist (SA).

Зарегистрироваться