Напишите нам
Кейс внедрения Kanban уровня предприятия в TBC банке
КОНТЕКСТ ТРАНСФОРМАЦИИ

TBC банк (Грузия), занимает лидирующие позиции в регионе, имеет статус Банка №1 во многих сегментах экономики страны. По мере развития бизнеса, спрос на внутреннюю IT разработку рос в геометрической прогрессии.

Главными направления развития банка в 2017 году стали:
  • наращивание собственной IT разработки;
  • трансформация компании путем создания масштабируемой оргструктуры, которая бы отвечала текущим потребностям команд и инфраструктуры;
  • внедрение уровней Портфеля и Программы.

Основная цель трансформации - сократить time to market путем создания масштабируемых и предсказуемых процессов поставки, для удовлетворения запроса бизнеса на IT ресурс.

Сопутствующие цели:
  • создать систему метрик для Agile команд, способную объединить и выровнять бизнес и IT;
  • выработка подхода по взаимодействию с IT вендорами;
  • повышении прозрачности и предсказуемости поставки ценности, непрерывности функционирования бизнеса.
Проблемы, которые существовали в банке на старте трансформации:
  • Банк начал процесс Agile трансформации и организовал Agile остров для 3 команд. Непонятно, что делать дальше.
  • Тяжелый переход от централизованного стиля управления к децентрализованному.
  • Сложности в применение Scrum у существующих Agile команд.
  • Большая часть IT разработки отдана на аутсорс. Контроль за вендорами слабый.
  • Часть IT вендоров “не Agile” и требуют индивидуального подхода для включения работы с ними в бэклог трансформации.
  • На уровне компании сформирована команда трансформации, которой не хватает знаний.
  • Бизнес-анализ является узким бутылочным горлышком для всей системы поставки ценности.
  • Исполнительный орган банка принял решение внедрить Agile во всей организации целиком, везде, где это возможно. Не ясно, где это возможно и как это осуществить.
  • Agile на портфельном уровне банка еще не реализован.
  • Некоторые процессы внедрения изменений не прозрачны.
  • Непрозрачный срок поставки.
  • Бизнес и IT “говорят на разных языках”.
  • Бизнес не готовит полноценные требования на IT разработку.
Столкнувшись с препятствиями на пути Agile трансформации, TBC банк обратился к AgileLAB за поддержкой во внедрении изменений.
Первым этапом взаимодействия стало проведение Agile аудита.

Аудит помог подсветить следующие неочевидные препятствия для внедрения Agile:
  • Бизнес регулярно отправляет в IT разработку задачи вне очереди (каждую неделю или чаще появляются новые фичи или происходят изменения в приоритетах).
  • Планирования деятельности банка исходит из принципа “мы делаем строго то, что запланировали”. Планирование осуществляется горизонтом на год.
  • Выход в продакшн осуществляется каждый месяц, но почти вся поставка зависит от сервисных команд.
  • Ориентировочное время поставки фичи (lead time) составляет 6 месяцев.
  • Вендоры работают в нескольких стримах одновременно, отсутствует механизм распределения их ресурса.
  • Существует зависимость на некоторых сотрудников: они обладают исключительными компетенциями, которые не масштабированы.
  • IT не измеряет скорость поставки и свою пропускную способность.
Также в банке была проведена серия корпоративных тренингов по Agile для команд.

В качестве фреймворка масштабирования Agile был выбран SAFe в кастомной конфигурации. Внутри фреймворка SAFe на всех уровнях организации принято решение использовать Kanban метод.
Были проделаны шаги по построению Kanban системы. С учетом дизайна Kanban системы на уровне всей организации было проведено первое квартальное планирование (Program Increment Planning).

результаты

Успехи трансформации, с учетом проведенного квартального планирования, которые повлияли на сокращение Time to Market:
  • Стратегия банка доработана и стала доступной всей организации.
  • Участниками планирования отмечено, что бизнес и IT начали взаимодействовать.
  • Выявлено и разрешено огромное количество зависимостей.
  • Все стримы получили четкую рабочую картину на квартал.
  • Каждый стрим получил понимание, чем заняты остальные стримы.
  • Рабочая нагрузка сервисных команд стала прозрачной и прогнозируемой.
  • Часть фич, подготовленных бизнесом к планированию, перенесены на следующий квартал из-за нехватки ресурса IT. Перенос визуализирован и принят бизнесом.
  • Риски отмечены командами и подсвечены стейкхолдерам.
“Доска зависимостей с квартального планирования. Выявлено и разрешено огромное количество зависимостей”.
Точки роста, которые удалось подсветить благодаря проведенной работе:
Недостаточное участие бизнеса в процессе подготовки и планирования.
В исходном бэклоге элементы без установленного владельца и с неопределенными бизнес-целями.
В исходном бэклоге чаще всего отсутствуют бизнес-приоритеты.
В некоторых случаях бизнес-аналитики, а не представители бизнеса, принимают решение о датах выхода в прод, скоупе выпуска, а также о других важных вещах.
Большим организациям лучше выбирать Kanban метод, который позволяет упорядочить любые процессы, Scrum же лучше применять для небольших IT-компаний или команд.

Kanban метод отлично работает во фреймворк SAFe.
Kanban метод отлично подходит для управления работой вендоров.
ДАЛЬНЕЙШЕЕ РАЗВИТИЕ ТРАНСФОРМАЦИИ:

  • Применение формул расчета стоимости задержки поставки и приоритизации WSJF.
  • Формализация ролей Service Delivery Manager и Demand Manager.
  • Пересмотр WIP лимитов для портфельного уровня и стримов.
  • Введение WIP лимитов для уровня Программы.
  • Обучение руководства Kanban методу .
  • Дальнейшее следование практике “Совместное введение улучшений, развитие с помощью экспериментов”.
Возможно будет интересно