Как бельгийский банк внедрял Agile — кейс про большую трансформацию

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

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

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

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

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

Например, для того чтобы понять, какую методологию управления проектами лучше выбрать, специалисты обычно рекомендуют опросить заинтересованные стороны: сотрудников компании, руководителей, заказчиков продукта и т.п. Специальные вопросы, которые можно найти в Agile Practice Guide, помогут выбрать оптимальный подход к управлению под определенный контекст, каждому из которых отведен отдельный сектор на графике:

Анализ ответов на этом графике в соответствии с их локализацией поможет выбрать наиболее подходящий метод управления. Скажу о каждом из них пару слов:

• Agile — ориентирован на команду (об этом я уже говорил выше)
• Гибрид — сочетание подходов (например, в некоторых случаях удобно использовать гибридную модель Agile и «Водопада» (Waterfall), где Agile обеспечивает быстрые итерации, частые релизы, постоянную обратную связь с пользователем. А преимуществом «Водопада» является детальное планирование и обеспечение качества на старте проекта)
• Предиктивный подход — подразумевает тщательное планирование, низкий уровень изменений требований проекта и регулярную поставку результата.

Что такое Agile-трансформация

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

Читайте также: Почему у одних получается, а у других — нет. Эксперт про опыт внедрения Agile

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

3 шага в Agile-трансформации компании

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

1. Первый шаг — это выбор методологии для масштабирования Agile. В случае, если в вашем проекте работает до десяти человек и вы хотите работать по Agile, я бы рекомендовал использовать фреймворк Scrum — подробнее о нем можно узнать по ссылке. Но для проектов с количеством участников 50+ он не подходит.

Например, в банке, который мы взяли в качестве примера, был выбран SAFe (Scaled Agile Framework) — это гибкий фреймворк, позволяющий использовать Agile-методологии в больших командах размером более 50 человек. По сути, SAFe напоминает слоеный пирог из различных методик Agile, где на нижнем уровне находится практически традиционный Scrum, с типичными 2/3-недельными спринтами, командами по 3−9 человек включая владельца продукта (Product Owner), а также все типичные ритуалы, начиная от ежедневной планерки — и заканчивая разбором полетов на ретроспективном совещании.

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

Спринты объединяются в Program Increments (это регулярные мероприятия по планированию), состоящие обычно из 5 спринтов. То есть если в классическом Scrum мы построили что-то не то — то коррекция курса проводится уже в следующем спринте. Но в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment, ожидая очередного мероприятия.

На следующем уровне находится Agile Release Train (так называемые поезда). Для управления всеми пятью спринтовыми отрезками появляются новые функции, например, системный архитектор. А последний спринт объявляется организационным, и во время него проводятся общие собрания, анализ технического долга, строятся планы по проработке архитектуры процесса и синхронизируется работа всех команд.

Над уровнем Agile Release Train находится координация между отделами, директорами, и клиентом — проводится анализ экономической целесообразности изменений, создаются планы работ на 12−36 месяцев. Для компаний с годовым оборотом менее миллиарда долларов — это, как правило, последний этаж.

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

• Достаточно длительное время реагирования на изменения
• Большие затраты на коммуникацию и собрания.

С учетом этого банк использовал SAFe в качестве основы для построения собственной адаптированной Agile-модели (подробности банк, к сожалению, не раскрывает).

Альтернативой для SAFe в крупных компаниях могут быть около десятка подходов к масштабированию Agile на большие команды, но вторым по популярности после SAFe является LeSS, подробнее о нем можно узнать в Отчете об исследовании Agile в России за 2019.

2. Второй шаг — компания должна решить: стоит делать это своими силами или привлечь профессионалов на аутсорсе? Чтобы ответить на этот вопрос — нужно понять, что именно следует сделать на этом этапе:

• Провести вводные лекции и тренинги для сотрудников
• Отобрать подходящих по ценностям сотрудников для пилотных проектов
• Набрать в штат новых сотрудников, обладающих опытом работы по Agile
• Запустить пилотные проекты и довести их до успешного завершения.

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

3. Третий шаг — выбор программного продукта. Для автоматизированного управления проектами в мире используется около 500 программных продуктов. Подробнее о них можно прочесть в этой статье.

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

Каждый год аналитики из Gartner Inc., одной из ведущих аналитических компаний мира, публикуют свой анализ пространства управления проектами и портфелями (PPM) вместе с оценкой основных доступных решений. Результаты последнего рейтинга представлены на графике «Магический квадрант». Gartner называет «Магическим квадрантом» отчет с анализом какого-либо сегмента рынка, в который включает изображение с распределением поставщиков по указанным четвертям. Ежегодно компания выпускает несколько десятков магических квадрантов для каждого выбранного ею класса программного обеспечения.

На этом изображении мы видим названия решений для автоматизации управления портфелями проектов, которые Gartner разделил на 4 квадранта и для этого использовал две линейные прогрессивные экспертные шкалы — «полнота видения» (от англ. completeness of vision) и «способность реализации» (от англ. ability to execute).

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

• «Лидеры» (leaders) — поставщики с положительными оценками как по «полноте видения», так и по «способности реализации»
• «Претенденты» (сhallengers) — поставщики с положительными оценками только по «способности реализации»
• «Провидцы» (visionaries) — поставщики с положительными оценками только по «полноте видения»
• «Нишевые игроки» (niche players) — поставщики с отрицательными оценками по обоим критериям.

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

Однако это не единственный рейтинг компании Gartner для поставщиков софта по управлению проектами. У них также есть «Магический квадрант» на тему «Инструменты планирования Agile предприятия», где представлены продукты, которые поддерживают использование Agile. Он выглядит вот так:

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

На мой взгляд, выбор в пользу Targetprocess в данном случае обоснован, потому что софт позволяет автоматизировать как работу в отдельном проекте, использующем Scrum или Kanban, так и управление портфелем проектов компании, что является серьезным преимуществом. Например, софт поддерживает использование Jira (система отслеживания задач) для управления портфелями проектов. Есть возможность автоматизировать ведение журнала продукта, работу с приоритетами элементов журнала, планирование спринтов и т.д., что важно для Scrum. И в то же время поддерживаются kanban-доска с WIP-лимитами, специальные отчеты, важные для использования kanban.

При этом Targetprocess имеет интеграцию с другими продуктами для управления проектами (например, Trello) и может использоваться только для уровня управления портфелями, например, как это сделано в компании Wargaming. К недостаткам Targetprocess можно отнести стоимость этого продукта, его вряд ли может себе позволить малый и даже средний бизнес.

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

Чего можно добиться

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

Типичными целями для Agile-трансформации считаются результаты, которых удалось добиться и банку:

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

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

1. Выберите подходящую именно вашей компании модель управления.

2. Поставьте внятную цель (лучше использовать для этого методологии постановки целей SMART или OKR).

3. Определитесь, кто будет внедрять изменения в компании.

4. Выберите оптимальный программный продукт для автоматизации управления портфелями и проектами (желательно, чтобы это был один продукт).

Читайте также

• По Аgile реально работать не только айтишникам — Юрий Шиляев о том, как это доказал «ЮрСпектр»
• «Можем позволить себе работать на расслабоне» — как устроен бизнес с маржой 50%