Все статьи
Совместное планирование #4
Дата: 22.11.2017
Перевод книги Хенрика Книберга и Тирстеда Брэндсгарда про масштабирование Agile в компании LEGO, часть 4.
Оглавление
Что изменилось, кроме совместного планирования?
Немало! И хотя PI-планирование является центром притяжения для проведенных нами изменений, они выходят далеко за его рамки. «Настоящая» работа — вот то, что происходит между PI-планированиями.
В течение PI команды следуют Scrum и работают 2-недельными спринтами, с такими обычными Scrum-церемониями как планирование спринта, ежедневные стендапы, уточнение бэклога, обзор спринта и ретроспектива по итогам спринта. Еще у нас есть общие демонстрация и ретроспектива по итогам PI. Но сейчас мы не будем глубоко погружаться в их детали, так как задача этой статьи — рассказать о PI-планировании, поскольку именно оно иллюстрирует децентрализованную координацию по принципу «снизу-вверх», которой мы стараемся добиться. PI-планирование, как зеркало, отражает наш общий процесс и культуру.
Но есть одна активность, о которой стоит упомянуть отдельно — это предварительное планирование PI, когда владельцы продуктов собираются вместе, чтобы обсудить и приоритизировать функционал для предстоящего PI. Мы проводим три такие сессии перед каждым PI-планированием. В ходе этих сессий требования эволюционируют от просто заголовка до детально проработанного функционала, приоритизированного по ценности, времени, важности и затратам. Советую почитать про Cost of Delay или WSJF (Weighted Shortest Job First), если хотите узнать больше. Если же вы хотите погрузиться действительно глубоко, то возьмите книгу «The Principles of Product Development Flow» Дона Рейнертсена.
Что является истинной целью PI-планирования?
Одним словом — Скоординированность.
PI-планирование — это общее совместное мероприятие по планированию, и его цель — скоординировать команды друг с другом.
Ценность, которую приносит совместное планирование, напрямую определяется количеством зависимостей, которые у вас есть. Конечно, лучше всего проектировать архитектуру и создавать структуру команд таким образом, чтобы минимизировать число зависимостей и избежать необходимости в мероприятиях вроде совместного планирования. Но если у вас несколько команд, работающих над одним продуктом или, как в нашем случае, над тесно связанными продуктами с общими технологиями — совместное планирование крайне полезно.
Работая в рамках спринтов, каждая команда имеет двухнедельный горизонт планирования. PI-планирование расширяет этот горизонт и дает командам возможность совместно заглянуть в будущее (на 2 месяца, или один «инкремент продукта»), но с меньшей детализацией.
Сложность заключается в том, чтобы не поддаваться соблазну создавать точные и детальные планы — лучше быть примерно правым, чем точно ошибаться.
Еще заметьте, что инкремент продукта, как бы это ни звучало — это не один релиз, равносильный «большому взрыву». Это точка синхронизации, время и место, где команды собираются вместе с целью выровнять понимание друг с другом. И это полностью отделено от релизных циклов. Периодичность релизов в разных командах отличается и зависит от природы их работы, поэтому планируем мы регулярно, а релизы проводим по запросу.
PI-планирование решает проблему несогласованности команд и убирает фрустрацию и потери, которые она создает. Оно является платформой, дающей людям поддержку на пути к общей цели, а еще оно, как поется в песне, задает наш общий «Big Heart Beat» — ритм жизни для группы достаточно автономных команд.
Ничто не сравнится с общением лицом к лицу. Реальный объем информации, которым обмениваются участники, и число принимаемых в ходе PI-планирования решений реально впечатляют. Это возможно благодаря тому, что весь мозговой фонд и полномочия собраны вместе в одной комнате. Все, с кем вам нужно поговорить, присутствуют здесь и сейчас и нет необходимости посылать приглашение через календарь или ждать подходящего времени для организации встречи — просто иди и говори.
Без такого мероприятия по планированию для достижения той же цели нам потребовалось бы несколько отдельных координационных совещаний, с соответствующими письмами и таблицами, и все это добавляло бы время ожидания и разногласий. Более тонкие детали работы обсуждаются уже после PI-планирования, в рамках спринтов, но костяк создается в ходе совместного мероприятия по планированию.
Еще один бонус от PI-планирования состоит в том, что оно создает корневую прозрачность, раскрывая сложность, присущую масштабной разработке ПО. Оно может немного пугать сторонних ключевых лиц, но в результате они получают лучшее понимание происходящего и, когда они видят, как команды пытаются приручить этого сложнейшего монстра, их уважение к ним растет.
Но что же тогда является недостатком? Хочется сказать «затраты», но на самом деле это не такая уж большая проблема. Людям платится их же зарплата, независимо от того, находятся ли они на PI-планировании или нет. Единственными накладными расходами являются площадка и еда, что является небольшой платой за ценность, которую мы получаем.
С точки зрения психологии, одним из недостатков является то, что, если вы помешаны на тотальном контроле, вы не выйдете с мероприятия со спокойной душой и кристально четким планом. И общая организация может ощущаться весьма хаотичной и неструктурированной.
Однако, когда вы привыкнете к формату, то обнаружите, что мероприятие дает достаточно хороший обзор, чтобы вы были достаточно уверены, что цели будут выполнены, в то же время оставляя возможность углубиться в конкретную область, которая важна конкретно для вас. В остальном вы можете положиться на добросовестность команд — в конце концов, они все умные люди и специалисты, иначе зачем их было нанимать? 
К чему все это привело?
Ничто не совершенно, но в целом последствия были неожиданно позитивными и никто как будто даже не захотел вернуть все как было.
- Меньше двойной работы. Команды лучше настроены друг на друга, поэтому они тратят меньше времени на лишнюю работу.
- Меньше проблем с зависимостями. Команды тратят меньше времени на ожидание, будучи заблокированными друг другом. Командам легче взаимодействовать с другими департаментами и ключевыми лицами.
- Руководство может управлять приоритетами и решать проблемы быстрее, потому что гораздо лучше понимает, что происходит.
- Возрастает доверие клиентов, потому что они знают, над чем работают команды и почему.
- Планирование упрощается и обязательства выполняются чаще, потому что команды и те, кто отвечает за планирование портфеля, понимают, сколько работы они могут на себя взять и какова их реальная производительность.
Еще важнее то, что это подняло мотивацию всех участников команд. Ходить на работу гораздо веселее, если там меньше неразберихи и бесполезных трат. А еще мотивированные люди делают свою работу лучше, так что получается позитивный цикл!
Еще одно последствие, которое мы заметили: люди из других департаментов LEGO, посещающие наши мероприятия, очень вдохновляются и начинают исследовать, как внедрить хотя бы часть принципов и практик в своем департаменте. В действительности, Agile распространяется по компании, как вирус, и PI-планирование, очевидно, является катализатором этого процесса.
Однако, это все еще остается запутанной и непростой работой («трудное удовольствие», как мы любим его называть), и нам есть куда улучшаться. Но, фокусируясь на общих целях, получая более уверенные в своих силах команды, учась лучше определять зависимости, мы чувствуем, что стали делать правильные вещи правильным способом.
Как все начиналось
Вы все еще тут? Хотите знать, как все начиналось? Хорошо, вот вам предыстория.
В конце девяностых жизнь была хороша: горстка людей (кросс-функциональная команда, как мы бы назвали их сейчас) делала всю онлайновую часть LEGO, состоящую из нескольких GIF и HTML. Но по мере того как цифровые технологии развивались и инструменты разработки становились все более сложными, росла потребность в людях, поставляющих цифровые решения. На отметке около 15 команд мы реально наступали друг другу на ноги и тянули в разные стороны.
Сначала мы попробовали бросить на решение проблемы нескольких менеджеров проектов, но это не сильно помогло — они всегда были как будто на шаг позади. Типичным симптомом были непрерывно обновляющиеся планы, запросы дополнительного бюджета на управляющих комитетах и откладываемые даты запуска.
Мы все еще верили в Agile-принципы, которые мы запустили на уровне команд еще в 2008, но мы понятия не имели, как их масштабировать. Один из проектных менеджеров где-то слышал про штуку, которая называется «Scaled Agile Framework» и решил изучить ее глубже. Он поделился полученными знаниями с нами, и мы ушли их переваривать их…, на пару лет.
Но затем все неожиданно закрутилось. Обсудив с несколькими командами, руководители проектов уверились в том, что этот фреймворк сможет нам помочь, после чего все менеджеры департамента были приглашены на вводный тренинг по фреймворку. И хотя это не убедило их на 100%, у них сложилось впечатление, что это МОЖЕТ помочь и еще, что оно вряд ли навредит, поэтому, черт побери, почему бы не попробовать? Один из топ-менеджеров компании поддержал идею и обеспечил финансирование обучения для всех 120 человек в департаменте.
Далее мы прошли трехдневный тренинг, включающий симуляцию, и на следующий день совершили прыжок в неизведанное, создали бэклог программы и организовали наше первое PI-планирование. Это было шумное, судорожное и хаотичное начало, но, к нашему удивлению, мы сразу же приступили к работе и мероприятие сработало лучше, чем мы опасались.
Вот некоторые моменты, которые помогли нам стартовать успешно:
- Команды хотели, чтобы оно заработало. Если бы команды не были заинтересованы в успехе, мы бы с треском провалились. Несмотря на скептицизм относительно некоторых частей фреймворка, они действительно включились в игру и сделали все возможное, чтобы привести ее к успеху.
- Существующий опыт Agile. Команды уже практиковали Agile годами и существенная часть организации понимала его принципы. Это была действительно хорошая база для дальнейшего масштабирования.
- Поддержка со стороны руководства. Руководство верило в нас и обеспечивало нам достаточную поддержку, чтобы инициатива стала успешной. И хотя всего несколько топ-менеджеров были вовлечены напрямую, они приняли возможные риски, дали нам возможность развернуться и обеспечили нам достаточное финансирование, чтобы обучить всех вовлеченных людей.
- Подход без фанатизма. Хотя мы использовали Scaled Agile Framework в качестве базы, мы не следовали принципам фреймворка с религиозной фанатичностью. Фреймворк содержит слишком много ненужных нам деталей, плюс он оптимизирован под группу команд, работающих над одним продуктом, в то время как наши команды работают над разными продуктами и сервисами. Поэтому для каждого нового PI мы меняли процесс и подстраивали его под себя, добавляя нужные нам элементы и убирая те, что не приносили нам ценности. Это дало участникам ощущение причастности: они видят, что процесс и структура работают на них, а не наоборот.
А что сейчас? В чем ваши текущие сложности?
Мы продолжаем экспериментировать. Каждое изменение может принести улучшения, может сделать хуже, а может вообще не дать результата. Но мы сохраняем то, что работает, и выбрасываем то, что не приносит пользы, поэтому с течением времени процесс постепенно улучшается.
Самые значимые улучшения происходили на начальных этапах, сейчас же изменения гораздо мельче, и мы, похоже, пришли к устоявшемуся процессу. С таким количеством участников мы не можем сделать каждого супер-счастливым, но мы можем сделать так, чтобы никто не был супер-несчастлив.
Наша самая большая сложность состоит в том, что мы работаем над несколькими разнородными вещами и, хоть мы и составляем один департамент, использующий в основном единые инструменты и технологии, мы не создаем единственный цельный продукт. В идеале мы хотим реорганизоваться в меньшие группы команд, основываясь на более специфических продуктах или потоках ценности — в этом состоит наша Великая Теория Универсальной организационной структуры. Тогда мы могли бы ограничиваться несколькими небольшими PI-планированиями вместо одного большого монстроподобного мероприятия. Но пока мы не придумали, как это лучше сделать, а собирать всех вместе в одном зале для планирования чертовски удобно и мы уже очень к этому привыкли.
В результате, нам сложно сфокусировать PI-планирование на всего одной или двух темах с последовательной их проработкой. Вместо этого мы работаем с целым набором разных целей, актуальных для разных команд и заинтересованных лиц. Это приводит к неудовлетворенности со стороны руководства, так как они хотят получить четкое видение того, над чем команды будут работать. И, с другой стороны, это также приводит к неудовлетворенности со стороны команд, потому что они хотят четкого понимания контекста и сквозных приоритетов. В результате получается что-то наподобие проблемы яйца и курицы.
И хотя эксперименты и изменения процесса кажутся успешными, мы нередко задаемся мета-вопросом: а нужную ли переменную мы оптимизируем? Или мы проводим изменения только ради самих изменений? Например, если PI-планирование больше не является нашим самым большим ограничением, должны ли мы продолжать его улучшать? Пока что мы продолжаем искренне считать, что оптимизируем правильные вещи, но неплохо хоть иногда это проверять.
Еще одна сложность — это динамика. Вначале все были взволнованы (или встревожены) происходящими изменениями, поэтому энергетика была активной, а атмосфера — хорошей. Но иногда мы сваливаемся в удобное для ума состояние «business as usual» и теряем динамику. Небольшие изменения и сюрпризы, происходящие в ходе PI-планирования, могут стать стать неплохой мотивацией, чтобы участники не переставали думать. Пространство для улучшения есть ВСЕГДА — нам только нужно напоминать себе об этом время от времени.
Заключение
Надеюсь, эта статья была полезной для вас! Она несомненно стала полезной для нас, так как дала нам повод поразмышлять над тем, что мы сделали и чему научились. :o)
Но помните, что наш подход — это не универсальный ответ на вопрос о масштабировании Agile, это просто пример, мгновенный снимок нашего незавершенного путешествия. Agile — это вообще про непрерывные улучшения, это направление движения, а не его цель.
Хотя одну вещь можно сказать с уверенностью: если бы мы попытались спланировать все эти изменения с самого начала, мы бы точно никуда не пришли. Если вы хотите, чтобы изменения произошли, вместо этого начните с той точки, где вы находитесь сейчас, поставьте какую-нибудь цель и начинайте экспериментировать. Дальше все зависит от людей: если они готовы к изменениям и поддерживают идею, вы добьетесь прогресса. В противном случае — нет.
И не стесняйтесь пользоваться существующими процессными фреймворками или заимствовать идеи у других компаний или из конкретных тематических исследований (как это). Нет необходимости изобретать колесо! Только не забывайте адаптировать все это под свой контекст: вы вряд ли найдете полностью готовое решение под ваши нужны, но вы, возможно, найдете что-то, что заставит процесс двигаться (или кубики летать) в правильном направлении.
Удачи!
Благодарность: множество очень умных, увлеченных и дружных людей были вовлечены в реализацию этих изменений! Мы не будем даже пытаться перечислить их всех. Наша же роль состояла по большей части в поддержке этих изменений и раздувании пламени :o)
Henrik Kniberg: henrik.kniberg@crisp.se
- http://www.crisp.se/henrik.kniberg
- https://twitter.com/henrikkniberg
- http://blog.crisp.se/author/henrikkniberg
Eik Thyrsted Brandsgård: eik.thyrsted.brandsgaard@lego.com.
