Большой Голландский Банк | Наш путь к масштабируемой гибкости

Авторы:

Cезарио Рамос, г-н А, г-жа Б и г-н В

ПО ПРИЧИНАМ ПРАВОВОГО ХАРАКТЕРА Я НЕ МОГУ НАЗВАТЬ РЕАЛЬНЫХ ИМЕН КОМПАНИЙ И УЧАСТНИКОВ

Введение

В этой статье мы расскажем о том, как мы улучшили модель на базе Spotify в трайбе Голландского Банка.

Над нашим продуктом кредитования бизнеса работают более 20 команд.

Мы разрабатываем наш продукт в трех локациях со смешанными командами. Участники каждой из команд владеют навыками бизнеса, ИТ и операционными навыками. При такой схеме работы мы поставляем нашим клиентам ценный продукт каждые две недели. Мы достигли этого, помимо прочего, благодаря внедрению принципов LeSS для оптимизации нашего способа работы в стиле Spotify.

Итак, что мы изменили?

В этой статье мы расскажем нашу историю с четырех различных точек зрения.

С точки зрения:

лидера трайба,
консультанта,
главы ИТ-отдела,
Владельца Продукта для части продукта, связанной со всеми циклами взаимодействия с клиентом.

Наблюдения: зачем мы это делали?

Около полутора лет назад я (рассказывает руководитель) начал руководить трайбом ― группой из 500 человек, в которой представители бизнеса и ИТ работали совместно в скводах, создавая продукт кредитования бизнеса и взаимодействуя с командами, отвечающими за лояльность клиентов. До этого я занимался созданием розничного банка с нуля и развитием решений для ипотечного кредитования. Во время моей предыдущей деятельности я интенсивно работал над превращением работы по Аджайлу в модель, подходящую для эффективной организации.

В первые несколько недель я решил понаблюдать за группой.

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

Казалось, все шло хорошо, пока мы не подошли к первому большому релизу продукта.

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

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

Я предложил новичкам (тем, кто проработал в нашем трайбе менее 6 месяцев) поделиться со мной своим видением, и они также отметили отсутствие взаимопонимания между представителями бизнеса и ИТ. Кроме того, они выразили сомнение в том, что функции, над которыми работали скводы (команды), действительно были самыми важными для клиента и клана, а не только для самих этих скводов.

В то же время, при создании целевой платформы для Бельгии и Нидерландов, я столкнулся с проблемами, связанными с отсутствием требований к ее возможностям, необходимым каждой из этих стран, а также образом мышления в стиле «они и мы». Как же свести все это воедино…

Линия поддержки: однажды…

Я не знал, что делать, поэтому начал искать помощи. К счастью, примерно в это время на нашу обучающую сессию зашел ИТ-директор, и я рассказал ему о нашей ситуации. Он сказал, что знает кое-кого, кто мог бы мне помочь и даже когда-то проводил Go See (сессии выявления проблем) для моих команд ― он представил меня Сезарио.

Я (рассказывает консультант) познакомился с представителями Голландского Банка, когда выступал с докладом на встрече. Моя лекция была о программистах в условиях крупномасштабной разработки. После лекции ко мне подошел один джентльмен и рассказал о проблемах, которые он наблюдал в своей группе. Позже он представился как ИТ-директор из Голландского Банка в Нидерландах.

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

Я не был в этом особенно заинтересован, так что сказал, что отправлю ему свое предложение позже на этой неделе. Он ответил: «Хм-м… Я думал, что Аджайл подразумевает, что сотрудничество с клиентами важнее условий контракта?»… Его ответ заинтриговал меня, и я решил съездить в Голландский Банк и посмотреть, что же там происходит.

Итак, пару недель спустя я поехал туда, чтобы провести там сессию Go See в течение пары дней.

Понимание динамики системы

Я часто начинаю совместную работу с сессии Go See. Я провожу такие сессии, чтобы выразить свое уважение команде и ее руководству, а также понять, как выглядит работа команд.

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

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

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

На основе всей этой информации я сформировал у себя понимание того, как происходит работа, и использовал это для составления рекомендаций.

Далее я расскажу о своих наблюдениях, имеющих отношение к теме этой статьи.

Модель Голландского банка на базе Spotify

Продуктовая группа называется трайб. Ее директор ― представитель бизнеса и эксперт в области рынка кредитования бизнеса. Его называют лидером трайба. Команды называют скводами. В сквод входят носители бизнес-знаний (CJE), навыков ИТ и разработки, а также DevOps. В каждом скводе есть Владелец Продукта, который управляет Бэклогом сквода. За развитие навыков и компетенций людей отвечает чаптер лид. Они есть как в ИТ, так и в бизнесе.

Аджайл-коуч поддерживает работу клана в соответствии со стандартом Аджайла Голландского Банка. Владелец Продукта, чаптер лид и Аджайл-коуч объединены в тройку, называемую POCLAC. Участники POCLAC регулярно встречаются, чтобы обсудить проблемы и решения возможных проблем скводов.

Ниже изображена схема такой организационной структуры.

Локальная оптимизация скводов

Трайб состоял из 24 скводов. Некоторые скводы были территориально распределены. И большинство скводов было тем, что в терминологии LeSS мы называем компонентными командами.

Я также заметил, что в них было 24 командных «Владельца Продукта». Они были постоянно заняты уточнением требований, управлением бэклога, координацией работы команд и управлением командами.

Изменения, которые проводили командные «Владельцы Продукта», были локальными. Я нашел множество примеров, которые это подтверждают. Вот один из них: Скводу 3 требовались изменения в API, а Сквод 6 планировал выполнить эти изменения. Позже в Скводе 6 решили не выполнять этих изменений, и Сквод 3 не смог завершить свою работу. Этим отрядам было очень трудно согласовать свою работу с целями трайба и продукта в целом.

Хотя у каждого сквода была четкая цель, зачастую эта цель не была значимой для конечных пользователей. Из этого факта явно следовало, что большинство отрядов были не в состоянии доставить ценность конечным пользователям самостоятельно. По отдельности эти отряды могли только выполнять часть всей фичи. Большинство скводов зависели друг от друга, и степень этой зависимости составляла от 30 % до 80 %. Зависимости замедляют разработку фич, удлиняют очереди задач различных скводов, увеличивают петлю обратной связи на рынке, а также снижают гибкость на уровне трайба и предсказуемость на уровне продукта. Это большая проблема, которая при добавлении новых компонентных команд может вырасти экспоненциально.

Я подумал, что этот способ работы ― идеальный пример реализации принципа Copy-Paste масштабирования [1]. Это распространенная ментальная модель для масштабирования Аджайл-подходов, которая не дает хороших результатов.

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

Проанализируйте работу и оптимизируйте самое важное

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

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

Выяснилось, что отряды с синими кругами (1, 2, 3, 4, 5, 7, 8, 18 и 21) должны вместе работать над одним продуктом, потому что эти отряды нужны практически для каждой фичи.

Монофункциональные менеджеры и POCLAC

Чаптер лидеры вели себя как монофункциональные менеджеры. Например, для каждой конкретной технологии (Pega или Java) был свой ИТ-лид чаптера. Монофункциональные менеджеры предлагают своим сотрудникам карьерный рост лишь в области одного конкретного навыка. Они не могут предложить им расти в области нескольких навыков, хотя именно это требуется для создания адаптивной команды.

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

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

Непрерывная интеграция

Семнадцать скводов работали в фиче-бранчах. Это означало, что они неделями, а иногда даже месяцами, работали изолированно, без интеграции своего кода с кодом других скводов. Я выяснил, что особой причины наличия такого большого количества веток не было, кроме той «здесь так принято работать».

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

Неудивительно, что в таких условиях релизы постоянно проходили болезненно и прогнозы были непредсказуемыми.[2]

Разработка через выдаваемые решения

Последнее наблюдение, которым я хотел бы поделиться, связано с разработкой через выдаваемые решения. Раз в квартал проводились сессии квартального уточнения бэклога (QBR), где отрядам выдавались задачи Epic, состоящие из нескольких историй, которые необходимо было выполнить. Производительность измерялась по мере выполнения задач Epic и входящих в них историй. Целью отрядов было выдать все истории в начале следующего квартала, как и планировалось. Чем более вы предсказуемы, тем лучше результат.

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

То есть целью было доставить определенный набор задач или решений Epic. Вместо достижения определенного значимого результата. Командам выдавалась работа для выполнения, а не проблемы для решения.

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

Проблемы руководства и организационный дизайн

Мы применили двойственный подход. Во-первых, руководство занялось согласованием целей. Какие проблемы необходимо было решить? Во-вторых, мы стали выяснять, какой организационный дизайн необходим для решения этих проблем.

Нам предстояло получить ответы на следующие вопросы:

Как повысить надежность трайба?
Как повысить фокус и соответствие цели внутри трайба?
Как быть с разработкой в нескольких локациях?

Выводы, к которым мы пришли в результате сессий Go See, позволили нам выработать дальнейшее направление работы.

Как повысить надежность трайба?

Надежность наверняка была бы выше, если бы мы понимали, где находится наш трайб в любой момент времени относительно наших квартальных целей.

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

Поэтому мы решили:

Постараться ставить перед командами проблемы, а не говорить им, какое «решение» необходимо создать.
Постараться сделать так, чтобы скводы брали на себя ответственность за рабочий продукт в конце каждого Спринта. Вместо того, чтобы чувствовать ответственность лишь за свою часть продукта.
Постараться постепенно избавиться от веток. Все команды выполняют коммиты в основную ветку. Использовать ветки только для релиза продукта. Это повышает координацию, снижает задержки и ускоряет работу. (Сначала люди были очень удивлены, если не сказать больше. Выполнение непрерывной интеграции (CI) с имеющейся структурой и технологиями казалось невозможным.)

Как повысить фокус и соответствие цели внутри трайба?

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

Поэтому мы решили:

Постараться создать скводы («синего цвета») в области Предложения для клиентов. Эти отряды должны работать над одним и тем же бэклогом. Это должно повысить их скорость и адаптивность.
Попробовать создать новые области LeSS для других отрядов после того, как убедимся, что первая область работает.
Постараться проводить планирование через результат, а не через выдачу решений. Например, не надо просить команды доставить эти «пять Epic-задач». Вместо этого попросите их, к примеру, найти решение для сокращения времени на одобрение кредита.
Постараться интегрировать код всех скводов в основную ветку, как минимум, два раза в день. Это сокращает риск обнаружения ошибок в разработке или даже после поставки продукта.

Как быть с разработкой в разных локациях?

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

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

Поэтому мы решили:

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

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

Нарушение правил

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

Проблема в том, что обычно мы предпочитаем не делать того, что, по нашим ожиданиям, работать не должно.

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

То есть мы не придерживались общепринятых идей по поводу того, как должно происходить подобное внедрение. Мы разрушили множество «правил»:

Не обучали каждого или даже не обучали никого. Вместо этого люди учились новым способам работы, применяя их. Мы начинали каждую сессию с объяснения, почему мы это делаем, нашей цели и тактики. Мы проводили небольшие воркшопы, на которых люди могли обсудить настоящие проблемы, с которыми они сталкиваются в реальной жизни.
Не использовали волонтеров. Вместо этого людей приглашали в команду, и добровольная работа была возможна лишь после появления у них опыта работы в течение нескольких Спринтов.
Не ликвидировали роль Владельца Продукта на уровне команды. Вместо этого Владельцы Продукта в командах сами добровольно сняли с себя эту роль после первого Спринта.
Не подготавливали систему непрерывной интеграции перед изменениями. Вместо этого мы поместили непрерывную интеграцию в начало итогового бэклога на несколько месяцев. Это стало возможным, так как мы перешли к работе с одним Владельцем Продукта.
Не использовали колоцированные команды. Вместо этого мы использовали смешанные команды, состоящие из участников из Бельгии и Нидерландов, чтобы ускорить изучение ими систем, бизнес-процессов и клиентов из другой страны.
Не использовали роль Скрам-мастера для команд 1–3, а точнее, мы вообще не использовали эту роль. Вместо этого у нас было четыре постоянно работающих Аджайл-коуча, которые помогали нам во время мульти-командных событий.
Не использовали термин LeSS. Вместо этого мы сосредоточились на изменениях. Через несколько месяцев я сказал участникам — то, что мы делаем, называется LeSS, и они ответили: «Да, мы знаем это, мы не глупы».

Как мы работаем?

Мы (рассказывает Владелец Продукта) ставим перед собой следующие цели по улучшению процесса:

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

Первым шагом проекта кредитования бизнеса в Голландском Банке стала работа с семью скводами и одним Владельцем Продукта. Скводы работают в соответствии со стандартным процессом LeSS. Стоит отметить лишь один момент.

Все скводы участвуют в нескольких синхронных мульти-командных воркшопах по Уточнению Бэклога в каждом Спринте. Это способствует распространению знаний и снижает зависимость одной команды от другой. Люди добровольно делятся тем, что они знают, например, о разработке на Pega.

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

Типичная повестка дня на Обзоре Спринта включает в себя: Видение Продукта, Цели Спринта, несколько параллельных демонстраций, корректировку работы на основе обратной связи и обзор планов на следующие Спринты.

Это было нелегко!

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

Ниже я приведу несколько проблем, которыми мы хотели бы поделиться:

Почему нам нужно меняться? Ведь я уже знаю, что нужно делать.

В течение первых нескольких Спринтов некоторые участники считали, что наши мульти-командные Уточнения Бэклога — всего лишь напрасная трата времени. Они утверждали, что и так хорошо знают, что нужно делать. Так почему они должны обсуждать все это заново с людьми, которые, возможно, даже не работали в таких условиях? Это неэффективно и кажется им нерациональным.

Я бы ответил им так: «Я понимаю, что вы все знаете об этом конкретном элементе Бэклога Продукта, но что вы знаете о других участниках своей команды?

Как вы можете знать все, если остальные этого не знают, тогда как наша цель — чтобы любой сквод мог взять в работу любой элемент Бэклога Продукта? Если вы эксперт в теме “А”, а все остальные участники команды — эксперты в теме “Б”, то что случится, если в нашем Бэклоге Продукта останется только тема “А”? Это не то, чего мы хотим».

Каков наш план?

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

Я бы сказал: «Мы даем оценку влияния на бизнес, но не можем оценить, какую функциональность (истории) мы доставим и когда. Конкретная функциональность изменяется по мере того, как мы получаем фидбек о нашей готовой функциональности и ее влиянию на бизнес».

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

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

Расставьте приоритеты, «почему я должен заниматься этим?»

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

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

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

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

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

Слишком много работы для Владельца Продукта

В ранних Спринтах я очень хотел достичь успеха и делал для этого все возможное. Это был период долгих дней и коротких ночей. Я отвечал на вопросы, разговаривал с многими пользователями и стейкхолдерами, писал истории и задачи Epic, организовывал встречи и так далее. Я был просто невыносим. Это не могло продолжаться долго. Как я мог быть Владельцем Продукта для семи скводов?

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

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

Владение продуктом и непрерывное совершенствование

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

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

Основные результаты

Мы проработали в такой конфигурации уже шесть месяцев и можем поделиться с вами некоторыми интересными результатами.

Завершение задач Epiс
Стремительное ускорение достижения запланированных результатов: c 55 % до 80 % за три квартала.
Поставка ценности в каждом Спринте
Более 50 согласований ценности поставляемой функциональности с нашими пользователями и клиентами. Раньше их было менее десяти.
Повышение удовлетворенности и расширение навыков участников команды
Незначительный рост показателей удовлетворенности сотрудников: с 5,85 до 6,04.

Основные выводы, которыми мы хотим поделиться

Основные наши выводы, которые мы считаем значительными, таковы:

Одно общее видение и одна цель — это очень полезно.
Совместное составление видения продукта со всеми участниками.
Регулярное повторение составления видения продукта.
Понимание цели повышает внутреннюю мотивацию.
Снижение зависимостей между отрядами
Наши скводы стали более автономны, так как они теперь меньше зависят друг от друга.
Работа скводов стала более значимой, потому что она вносит непосредственный вклад в ценность для клиента.
Создавайте владение продуктом: не говорите людям, что делать, а просите их решать проблемы.
Используйте все интеллектуальные ресурсы, доступные в вашей группе. Для этого ставьте амбициозные цели и позволяйте людям самим найти решение.
Вместо создания ложных предсказаний, сначала повышайте собственную надежность.
Когда люди владеют разными навыками и фиче-команды кросс-компонентны, надежность возрастает, так как скводы лучше приспособлены к решению различных задач. Метрики прогресса прозрачны, так как прогресс измеряется на уровне одной фичи.
Прогнозы делать сложно. Но чем надежнее качество продукта, тем меньше сюрпризов возникает на фазе стабилизации.
Непрерывная интеграция и автоматизированные тесты существенно повышают предсказуемость.
Работа в фиче-командах показала, что люди, которые раньше считались героями, на самом деле сдерживали развитие остальных.
Это не вопрос автономии, а вопрос приспособленности команд.
Совместная работа большого числа команд может создать впечатление, что у скводов меньше автономии. Но на самом деле это ложное предположение. Автономия ― это возможность выполнять работу без зависимостей от других. Наша конфигурация процесса снизила зависимости между скводами.
Главный вывод заключается в том, что автономия повышает приспособленность скводов к работе друг относительно друга. Повышение автономности скводов и движение их в одном направлении требуют от них постоянного повышения навыков и заботы о конечном продукте.

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