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

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

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

lego1

Предыдущие части книги читайте здесь: 1 часть, 2 часть.

Скачать полную версию книги (2,6 Мб, PDF)

День второй — стабилизация плана

На следующее утро вы спрашиваете кого-нибудь за завтраком:

— «А зачем вообще нужен второй день? Вы разве еще не закончили? У каждой команды есть план, зависимости определены, риски разобраны и так далее. Что теперь?»

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

— «То есть, планирование всегда длится два дня?»

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

Перемотка вперед: мы это сделали и действительно стало лучше! Понимай, как хочешь. Все детали позже.

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

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

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

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

— «Иногда проблема может появиться у зависимой от вас команды, и если вы где-то поблизости, она может быть решена быстро».

В некоторых случаях часть команды уходит домой, оставляя нескольких представителей для общения с другими командами.

К середине дня планы уже стабильны (настолько, насколько это возможно) и приходит время для финального рецензирования плана. Формат тот же, 4 сессии, и команды могут перемещаться по залу, слушая презентации планов друг друга. Цветные детальки LEGO на каждой доске сигнализируют, насколько сильно план изменился со вчерашнего дня. Это своего рода индикатор статуса, помогающий участникам решить, куда пойти.

lego25

Вотум доверия

После выставки планов команды возвращаются к своим столам и ведущий объявляет, что пришло время для вотума доверия.

— «Насколько вы уверены в своей способности достичь заявленных целей PI

Каждый участник поднимает вверх 1-5 пальцев, где «1» означает «не стоит и говорить», а «5» — «полностью уверен».

lego26

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

Мини-ретроспектива

Последний пункт на повестке дня — мини-ретроспектива. Каждая команда садится и обсуждает свои впечатления от мероприятия, что стало лучше с прошлого раза и что было бы здорово улучшить в следующий. Дополнительно каждый участник команды анонимно оценивает по пятибалльной шкале ценность для себя прошедшего PI-планирования («насколько хорошо я провел время»).

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

lego27

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

— «Погодите! Но это же в основном разработчики! Я думал, они НЕНАВИДЯТ совещания?»

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

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

lego28

Один из моментов, который всплыл на мини-ретроспективе в этот раз, касается вотума доверия. Насколько он реально полезен? Кто-то предлагает изменить его формат, другие считают, что он вообще бесполезен и его нужно убрать. После недолгих обсуждений они решаются на эксперимент: «Давайте в следующий раз не будем проводить этот этап и посмотрим, захотим ли мы его вернуть!»

Перемотка вперед: так мы отказались от голосования и, как мы и подозревали, вернуть его нам не захотелось! Команды составляют свои планы через «вытягивание», а не «впихивание», что по определению означает, что они достаточно в них уверены, и делает голосование избыточным. Пока-пока, вотум доверия! И это всего один из многих примеров того, как мы продолжаем экспериментировать с форматом, чтобы увеличить пользу события и минимизировать ненужные затраты.

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

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

Итак, теперь вы увидели PI-планирование! Надеюсь, вам понравилось.

А теперь — давайте сделаем шаг в сторону.

Это была 3 часть книги. Но и это еще не все! В последней части вы узнаете, к чему все это привело. Продолжение следует…

Следующие части книги читайте здесь: 4 часть.

Скачать полную версию книги (2,6 Мб, PDF)

16 ноя 2017, Сергей Рогачев
Тренинги по теме
Другие статьи
nor
11 дек 2017, Алексей Дерюшкин
Что такое Agile-подход и зачем он нужен бизнесу?

В чем суть Agile с точки зрения здравого смысла и пользы для бизнеса? Давайте без применения специальных терминов разберёмся, что такое Agile, зачем он нужен, из чего состоит и какими инструментами добивается ключевых целей.

Исследование Agile в России
24 ноя 2017, Сергей Рогачев
Отчет об исследовании Agile в России 2017

Компания ScrumTrek провела первое масштабное исследование востребованности и особенностей внедрения гибких методологий управления в России.

lego1
22 ноя 2017, Сергей Рогачев
Совместное планирование #4

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