Все статьи
Совместное планирование #2
Дата: 11.10.2017
Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 2.
Оглавление
Работа команд
Следующий этап — работа команд. Помещение наполняется гулом, потому что все команды в параллель начинают обсуждение наиболее важных вещей, которые необходимо реализовать в ближайшие пару месяцев. Обсуждение ведется без глубокого погружения в детали, так как за 8 недель может произойти немало неожиданностей.
Каждой команде отведены свой флипчарт и доска для планирования. Пока большинство членов команды ведет дискуссию у доски, остальные участники перемещаются по залу и синхронизируются с другими командами и заинтересованными лицами. Параллельно с этим у столов с кофе и закусками проходят обсуждения на свободные темы.
Вы замечаете, что некоторые команды или представители отдельных ролей одеты в одинаковые футболки или специальные кепки, чтобы легче находить друг друга в толпе. Индийские команды представлены на мероприятии лишь несколькими участниками, которые обеспечивают коммуникацию между людьми в зале и остальными участниками, находящимися в Индии.
На первый взгляд все кажется немного хаотичным, но на самом деле идет активная работа. И хотя некоторые участники и кажутся напряженными или утомленными, большинство выглядит так, как будто проводит время вполне хорошо и эффективно. То и дело слышатся взрывы смеха, возникают спонтанные обсуждения, заводятся новые знакомства, а существующие — укрепляются. Очевидно, что участники чувствуют себя комфортно и привычно в подобной обстановке.
Эта часть мероприятия занимает основную часть дня и по формату похожа на Open Space event (вероятно, вы принимали участие в подобных). Как и там, самое важное правило здесь — «закон 2 ног».
Вы замечаете, что ведущие часто делают акцент на этом: эффективность проведенного времени зависит только от вас, занимаетесь ли вы планированием со своей командой, обсуждаете ли архитектуру или просто беседуете у кофе-машины. Не ждите, что кто-то другой скажет, что вам делать или куда вам идти.
Однако, ограничения все же существуют, поэтому на каждом столе вы видите раздаточные материалы, описывающие общий процесс планирования и нефункциональные требования (довольно странное название, если задуматься). Такие вещи, как законодательные требования, обновления ПО, изменения в процессе разработки и другие моменты, которые команды должны учитывать при планировании. Нефункциональные требования обновляются каждый PI.
Вытягивающее планирование
Вы замечаете важную деталь — команды сами вытягивают работу, вместо того, чтобы кто-то насильно раздавал им задачи. Они решают, сколько на себя взять, основываясь на ретроспективных данных и внутреннем ощущении того, что действительно реально сделать. Чтобы это заработало, перед PI-планированием владельцы продукта каждой команды общаются с заинтересованными лицами и создают приоритезированный бэклог работ. Таким образом, владельцы продукта и клиенты задают приоритеты и отвечают за то, что нужно сделать, а команды решают сколько из этого они могут реализовать.
Некоторые команды достаточно независимы и имеют собственные бэклоги, другие же, например, команды платформы, работают с общим бэклогом программы и вытягивают задачи из него.
Вы видите группу людей из разных команд, стоящих перед большим экраном, на который выведен общий бэклог программы. Они обсуждают, какие задачи лучше взять в работу той или иной команде.
Команды в некоторой степени специализированы и каждая фокусируется на своей области, такой, например, как аутентификация по LEGO ID, облачные технологии или поиск. При этом команды склонны брать себе задачи, которые им наиболее близки и понятны, или хотя бы наименее неприятны, и владельцам продукта иногда приходится напоминать командам, что будет здорово, если КТО-ТО возьмет высокоприоритетную неприятную задачу, даже если она не лежит в области специализации их команды. На текущий момент наши команды довольно хорошо сбалансированы и мы в целом можем фокусироваться на разработке правильных вещей (вместо того чтобы очень эффективно делать не то, что нужно). Члены команд по большей части являются кросс-функциональными (T-shaped), и, несмотря на свою основную специализацию, могут помогать другим в работе над задачами.
Раньше для визуализации бэклога программы мы использовали физическую доску с напечатанными карточками:
…однако ее обслуживание требовало больших усилий, и мы придумали, как делать это напрямую в нашей системе управления бэклогом, выводя информацию из нее на стену с помощью проектора. Да, физического контакта с доской стало меньше, но, имея шесть команд по разработке платформы, стало гораздо проще отслеживать процесс совместного планирования.
Осмотревшись, вы замечаете, что у некоторых команд бэклоги тоже выводятся в электронном виде, однако большинство все-таки используют физические доски.
Доски команд
У каждой команды есть своя передвижная маркерная доска, на которой размещена Доска Команды.
Сначала она пустая и заполняется в течение дня, по мере того как план обретает очертания.
Вот что означают разные секции:
В целом, это и есть верхнеуровневый план на следующие 4 спринта (каждый спринт длится 2 недели, так что инкремент продукта занимает 8 недель) — основной результат всего мероприятия по планированию.
— Ууу… ребята, так у вас всего 1 релиз за 8 недель?
— Нет, 8 недель — это цикл нашего планирования на уровне программы. Периодичность релизов — это совершенно иное: у одних команд релизы происходят чаще, у других — реже.
Конечно, план еще будет меняться, в зависимости от стабильности окружения каждой команды, но иметь такой план все равно полезно, потому что это стимулирует всевозможные обсуждения о приоритетах, взаимозависимостях, производительности и так далее. Потребности всегда будут выше наших возможностей, поэтому командам и клиентам необходимо работать вместе, чтобы находить непростые компромиссные решения.
При планировании команды применяют принцип «вчерашней погоды»: они берут данные о том, сколько работы было сделано (в story points) в предыдущих PI. Эта цифра помогает проверить реалистичность планов, чтобы избежать завышенных обязательств. У нас было немало проблем с непосильными обязательствами, которые, в свою очередь, приводили к снижению качества, сорванным срокам и потере доверия между клиентом и командой. В ситуации неопределенности обещать меньше и затем при возможности выполнить больше работы лучше, чем подписаться выполнить невозможное и потом быть вынужденным снимать с себя невыполненную работу.
«PI-цели» — это высокоуровневые обязательства команды, в идеале описанные с точки зрения их последствий («мы получим бизнес-результат X») в противовес описанию с точки зрения продукта («мы поставим фичу Y»). Но объем реализованного в PI функционала может меняться, поэтому, кроме основных обязательств, выделяются дополнительные цели — то, что команда может успеть, или надеется успеть сделать, но не имеет достаточной уверенности, чтобы под этим подписаться.
— Но погодите, что тогда вообще значит «подписаться»?
Здорово, что спросили! Обещанная цель на PI означает следующее:
- «На основании того, что нам известно сейчас, мы искренне верим, что можем это сделать».
- «У нас есть небольшой резерв по времени, чтобы покрыть неопределенности». Сколько времени нужно резервировать? Это зависит от:
- Нашей уверенности в требуемом объеме работы.
- Нашей уверенности в окружении (меняющиеся приоритеты и так далее).
- Насколько важно выполнить такое обязательство? Чем более важным является достижение конкретной цели, тем меньше становится число других обязательств, которые мы можем на себя взять.
- «Мы сделаем все, что от нас зависит, чтобы выполнить обязательство, но мы не можем быть уверены на 100%».
- «Если в какой-то момент времени мы перестанем верить, что успеваем сделать то, на что подписались, мы немедленно уведомим об этом заинтересованных лиц».
Раньше «обязательство» часто означало «невыполнимое обещание, которое кто-то уже дал за тебя — делай!». Это пагубно сказывалось на качестве и мотивации, а также серьезно усложняло планирование и прогнозирование.
Доски рисков
В ходе планирования команды выявляют риски, которые могут привести к невыполнению взятых на себя обязательств, и потенциальные проблемы вроде «новые лицензии не будут получены вовремя». Все это отображается на распределенных по всему залу досках рисков проектов или крупных инициатив. Часть рисков решается путем разговора с нужными людьми, но некоторые требуют эскалации и поэтому остаются висеть на доске, ожидая оценки руководством компании в конце первого дня.
Раньше риски зачастую игнорировали или без разбора эскалировали на руководство (что делало его узким местом процесса). Визуализируя риски в порядке значимости, команды научились гораздо больше из них брать на себя и делегировать только те, с которыми им действительно нужна помощь. Иногда цена устранения риска велика и непропорциональна его потенциальным последствиям, поэтому такой риск проще просто принять. Осознание и принятие рисков дает командам душевное спокойствие, так что они могут сфокусироваться на работе вместо переживаний.
Доска зависимостей
Вскоре вы замечаете ОЧЕНЬ большую доску, занимающую одну из стен. Похоже, здесь какой-то центр притяжения, потому что перед доской всегда шумно и стоят люди. Вначале она пустая, но к концу первого дня она превращается в запутанный клубок стикеров, соединенных… эм… красной нитью?! Стикеры, ножницы, нитки… да что ЭТО вообще такое?
Мы называем ее «доской зависимостей» (иногда «доской программы»). Она показывает, кто, что, от кого и когда ждет. Давайте посмотрим поближе…
Каждый столбец — это команда, каждая строка — спринт (2 недели). Стикеры представляют зависимости, от синих к розовым. «Для того чтобы поставить ЭТО (синий стикер), нам нужно получить от вас вот ЭТО (розовый стикер)». Вы замечаете множество обсуждений и споров о том, что кому должно быть поставлено и в каком спринте.
Кажется, что у доски зависимостей нет владельца. Изначально ее запускают ведущие, но затем команды собираются вокруг нее самостоятельно, визуализируют взаимные зависимости и используют доску, чтобы понять, кому и с кем требуется поговорить. Доска — централизованный инструмент для децентрализованного взаимодействия.
— Так команды помещают туда весь функционал, который планируют реализовать?
— Нет, только тот, который имеет зависимости. Раньше мы помещали туда все, но получалось такое нагромождение, что никто не мог в нем разобраться. Позже мы пришли к тому, что самое главное для нас — увидеть зависимости, и сконцентрировались только на них. Функционал, не имеющий зависимостей, можно увидеть на досках соответствующих команд, но не здесь.
Вы замечаете очевидное узкое место (столбец CIT, корпоративное ИТ) и оживленную дискуссию о том, как преодолеть это узкое место наиболее эффективно, а также еще несколько обсуждений того, как снизить фактор «бутылочного горлышка» в долгосрочной перспективе.
— О чем это они? — спрашиваете вы у ведущего.
— Ну, CIT — это независимое от DS подразделение, поэтому изначально они вообще не участвовали в планировании. Но после первой пары PI-планирований стало очевидно, что CIT является нашей самой важной зависимостью. Люди много жаловались на это. Поэтому мы добавили на доску зависимостей отдельную колонку для них и начали приглашать их представителей на наши PI-планирования.
— И как, помогло?
— Да, произошли колоссальные изменения! Стало меньше взаимных обвинений и больше совместной работы, меньше «мы и они» и больше «мы и мы».
Представители CIT и DS общаются у доски лицом к лицу и обсуждают, как лучше всего обойти ограничения, к которым приводит такое число зависимостей (и, конечно, как со временем снизить фактор их влияния). Обсуждение продвигается не слишком здорово, но люди у доски говорят вам: «Раньше было ГОРАЗДО хуже! Если бы вы знали, что нам уже удалось улучшить! Например, мы уже частично задействовали облачные сервисы, чтобы снизить зависимости. На все нужно время».
Нижняя строка доски зависимостей пустует по очевидной причине. Она называется IP («Innovation & Planning» — «Инновации и Планирование»). Этот спринт оставлен под незапланированные инновации, на все, что не успели сделать за первые три спринта и прочие активности очередное PI-планирование, тренинги и все, что может неожиданно всплыть.
Один из инженеров отмечает:
— Теперь мы стали гораздо успешнее в выполнении своих обязательств. У нас есть данные о нашей производительности (story points и прочее), поэтому мы реже даем несбыточные обещания. Кроме того, IP-спринт служит буфером, поэтому если что-то взрывается, у нас есть время это починить. Но самое важное, что мы берем обязательства после обсуждения и согласования, теперь они уже не просто прилетают к нам сверху.
— Хорошо, а что с инновациями? Буква I в аббревиатуре IP-спринта означает это, так?
Он смеется:
— Эта часть обычно выпадает. Но сейчас все равно гораздо лучше, чем было раньше. В последнем PI во время IP-спринта мы провели хакатон и получили немало крутых и полезных результатов! У какой-нибудь команды всегда получается выкроить время на инновации во время IP-спринта на зависть другим командам, у которых на этот раз не вышло.
Еще одна вещь, которую вам не терпится узнать:
— А что происходит с доской зависимостей после мероприятия?
— Мы сворачиваем ее, забираем в офис и вывешиваем там на стене.
— А потом что?
— Раз в две недели мы проводим Scrum of Scrums. Скрам-мастера всех команд собираются у доски, обсуждают препятствия и зависимости, и вычеркивают их по мере решения.
Он показывает вам фото:
— А что с командами в Индии, как они получают доступ к доске, если физически она на стене в Биллунде?
— Мы все еще пытаемся что-нибудь придумать…
— А как насчет следующего PI-планирования? Что будет с этой доской?
— Ничего, эту доску мы забросим. На каждом PI-планировании мы создаем новую доску зависимостей — это дает нам свежее видение и заодно позволяет экспериментировать с форматом и структурой доски, не погрязая в истории.
Выставка черновиков планов
После нескольких часов кажущегося хаосом раздельного планирования ведущий поднимается на сцену и объявляет о том, что наступило время презентации черновиков планов. Гул стихает, пока он вкратце напоминает о формате (уже ставшем привычным для большинства участников).
— У нас будет четыре сессии по 7.5 минут, следующие одна за другой. Во время каждой сессии один участник команды остается у доски команды, чтобы презентовать план, в то время как остальные могут идти слушать выступления других команд.
Он запускает большой таймер на 7.5 минут, и презентации начинаются. Небольшие группы скапливаются вокруг каждой доски планирования, чтобы услышать и обсудить план команды – что и зачем они собираются реализовать.
Риски и зависимости также обсуждаются, зачастую вскрывая новые проблемы. Никакой паники, завтра у нас будет время разобраться с проблемами.
— Почему 7.5 минут? Почему 4 сессии?
— Мы немало экспериментировали с разными периодами, и это сочетание показало себя лучше всего. Как раз достаточно времени, чтобы узнать что-то новое, но при этом не заскучать и не погрязнуть в деталях.
Через 7.5 минут раздается звонок и начинается вторая сессия. Люди переходят к другой команде, чтобы послушать их презентацию. И так далее, в сумме четыре сессии, или 30 минут.
— Хорошо, то есть каждый человек может посетить сессии четырех команд и услышать про их планы?
— Точно.
— А как же видение общей картины? Не будет ли полезнее услышать презентации всех команд?
— Нескольким людям – да, но большинству – нет. Поэтому вы можете выбрать четыре, которые для вас наиболее критичны. Если хотите знать больше – можете посетить остальные команды в ходе секционных обсуждений завтра.
— И вы придерживались такого формата с самого начала?
— Нет. Раньше мы делились черновиками планов в формате карусели. Все сидели на своих местах, и в каждый момент времени одна команда представляла свой план всей аудитории, а ведущие направляли камеру на их доску и транслировали изображение на большой экран. После того как мы подобрали технические инструменты, все стало проходить довольно гладко, но даже в условиях жестких временных рамок требовалось не меньше часа, чтобы услышать все 20 или около того команд.
— Ой.
— Ага. Несмотря на все наши старания сделать эту часть интересной, это было просто сонное царство! Несколько людей внимательно слушали, но большинство сидели, уткнувшись в свои телефоны, или потихоньку засыпали за столами в ожидании, когда же это, наконец, закончится. Людей, конечно, волнует то, чем занимаются остальные команды, особенно те, от которых они зависят. Но это 3 или 4 команды — им необязательно знать, что делают ВСЕ. Поэтому мы решили прекратить попытки впихнуть весь план во всех и организовали вместо этого вытягивающую систему. Формат выставки заработал ГОРАЗДО лучше!
Вы бродите по залу, прислушиваясь к презентациям. Участники обсуждают свои планы, зависимости, технологии, риски и прочее. Это действительно похоже на какую-то выставку!
Ведущий проходит мимо и обращает ваше внимание:
— Чувствуете, какая активная энергетика в зале? Это самая главная обратная связь, говорящая, что мы все делаем правильно. Если энергетика слабая и люди начинают выключаться из процесса, то неважно, что мы делаем — это неправильно и нужно менять формат. Таким образом, мы оставляем те части, которые производят энергию, и убираем те, от которых участников тянет в сон.
Вы замечаете, что вообще-то ведущих двое, они работают в паре и подменяют друг друга на сцене. Он продолжает:
— Мы всегда фасилитируем это мероприятие в паре. Так один может вести, в то время как второй, отступив на шаг и наблюдая со стороны, может следить за уровнем энергетики и думать об улучшениях. Наличие пары также обеспечивает небольшую избыточность на случай если кто-нибудь из нас заболеет — так проще вводить в курс дела нового ведущего.
Рецензирование руководством и решение проблем
В конце первого дня большинство участников расходятся, но менеджерский состав остается. Время для рецензирования руководством!
Доски рисков собираются в ряд с доской зависимостей, а менеджеры выстраиваются полукругом перед ними.
Все зависят от платформы, поэтому начинают с нее. Владелец продукта резюмирует план и поднимает вопрос, требующий непростого решения:
— Плохие новости. У нас нет ресурсов, чтобы реализовать как A, так и B в ближайшем PI.
Обе инициативы действительно важны, невыполнение любой из них будет иметь серьезные последствия, поэтому разгорается жаркая дискуссия. Ведущие направляют обсуждение и помогают ему оставаться вежливым. Руководители обсуждают возможные варианты, плюсы и минусы каждого, и в итоге решают поднять приоритет A, а B — отложить. Нескольким командам завтра нужно будет скорректировать свои планы в соответствии с этим решением.
Далее они просматривают все доски рисков. Вопросы, оставшиеся на досках — это те риски, которые команды не смогли решить самостоятельно, поскольку они затрагивают разные департаменты или находятся вне зоны их контроля. Сейчас группе менеджеров необходимо взять ответственность на себя и решить, что делать с каждым из таких вопросов, и они крайне заинтересованы сделать это быстро, так как это единственное, что их удерживает от того, чтобы пойти домой…
Вы замечаете колонки на доске рисков. Один из менеджеров объясняет:
— Фреймворк ROAM очень помогает нам в такого рода обсуждениях. Мы по очереди берем каждый из рисков, обсуждаем, принимаем решение и переносим его в одну из четырех колонок: Resolved (проблема больше не актуальна), Owned (вопрос не может быть решен на мероприятии, но кто-то согласился продвигать его решение далее), Accepted (риск является фактом или потенциальным событием, которое просто должно быть всеми понято и учтено в дальнейшей работе) или Mitigated (есть план по устранению последствий данного риска). Таким образом, у нас есть довольно четкий критерий для нашего ухода домой — все риски на доске должны быть обсуждены и «зароумены» (ROAM’ed)!
После этого они договариваются о том, кто резюмирует принятые решения и расскажет о них завтра утром.
Вы припоминаете прочитанную вами ранее книгу о концепции служащего лидера и понимаете, что подобная организация работы автоматически подталкивает менеджеров к следованию этой концепции. Команды видят, что руководство не боится ответственности и помогает решать проблемы, что укрепляет доверие.
Ведущий подтверждает вашу догадку.
— Раньше рецензия руководством была весьма хаотичным и изматывающим мероприятием. Изначально у нас вообще не было досок рисков, поэтому обсуждения были неструктурированными и занимали кучу времени, а принятые решения нередко терялись или забывались. Потом, когда мы ввели доски рисков, стали эскалировать слишком много проблем. Но постепенно команды научились брать ответственность на себя (не без поддержки руководства, конечно) и, поскольку число рисков, доходящих до руководства, снизилось, они стали с большей готовностью брать на себя их решение.
