Кейс внедрения Kanban уровня предприятия в TBC банке
Кейс внедрения Kanban уровня предприятия в TBC банке
Контекст трансформации
TBC банк (Грузия), занимает лидирующие позиции в регионе, имеет статус Банка №1 во многих сегментах экономики страны. По мере развития бизнеса, спрос на внутреннюю IT разработку рос в геометрической прогрессии.
Главными направления развития банка в 2017 году стали:
Основная цель трансформации - сократить time to market путем создания масштабируемых и предсказуемых процессов поставки, для удовлетворения запроса бизнеса на IT ресурс.
Сопутствующие цели:
Главными направления развития банка в 2017 году стали:
- наращивание собственной IT разработки;
- трансформация компании путем создания масштабируемой оргструктуры, которая бы отвечала текущим потребностям команд и инфраструктуры;
- внедрение уровней Портфеля и Программы.
Основная цель трансформации - сократить time to market путем создания масштабируемых и предсказуемых процессов поставки, для удовлетворения запроса бизнеса на IT ресурс.
Сопутствующие цели:
- создать систему метрик для Agile команд, способную объединить и выровнять бизнес и IT;
- выработка подхода по взаимодействию с IT вендорами;
- повышении прозрачности и предсказуемости поставки ценности, непрерывности функционирования бизнеса.
Проблемы, которые существовали в банке на старте трансформации:
- Банк начал процесс Agile трансформации и организовал Agile остров для 3 команд. Непонятно, что делать дальше.
- Тяжелый переход от централизованного стиля управления к децентрализованному.
- На уровне компании сформирована команда трансформации, которой не хватает знаний.
- Сложности в применение Scrum у существующих Agile команд.
- Большая часть IT разработки отдана на аутсорс. Контроль за вендорами слабый.
- Исполнительный орган банка принял решение внедрить Agile во всей организации целиком, везде, где это возможно. Не ясно, где это возможно и как это осуществить.
- Agile на портфельном уровне банка еще не реализован.
- Некоторые процессы внедрения изменений не прозрачны.
- Часть IT вендоров “не Agile” и требуют индивидуального подхода для включения работы с ними в бэклог трансформации.
- Бизнес и IT “говорят на разных языках”.
- Бизнес-анализ является узким бутылочным горлышком для всей системы поставки ценности.
- Бизнес не готовит полноценные требования на IT разработку.
- Непрозрачный срок поставки.
Столкнувшись с препятствиями на пути Agile трансформации, TBC банк обратился к AgileLAB за поддержкой во внедрении изменений.
Первым этапом взаимодействия стало проведение Agile аудита.
Аудит помог подсветить следующие неочевидные препятствия для внедрения Agile:
В качестве фреймворка масштабирования Agile был выбран SAFe в кастомной конфигурации. Внутри фреймворка SAFe на всех уровнях организации принято решение использовать Kanban метод.
Аудит помог подсветить следующие неочевидные препятствия для внедрения Agile:
- Бизнес регулярно отправляет в IT разработку задачи вне очереди (каждую неделю или чаще появляются новые фичи или происходят изменения в приоритетах).
- Планирования деятельности банка исходит из принципа “мы делаем строго то, что запланировали”. Планирование осуществляется горизонтом на год.
- Выход в продакшн осуществляется каждый месяц, но почти вся поставка зависит от сервисных команд.
- Ориентировочное время поставки фичи (lead time) составляет 6 месяцев.
- IT не измеряет скорость поставки и свою пропускную способность.
- Существует зависимость на некоторых сотрудников: они обладают исключительными компетенциями, которые не масштабированы.
- Вендоры работают в нескольких стримах одновременно, отсутствует механизм распределения их ресурса.
В качестве фреймворка масштабирования Agile был выбран SAFe в кастомной конфигурации. Внутри фреймворка SAFe на всех уровнях организации принято решение использовать Kanban метод.
Были проделаны шаги по построению Kanban системы.
С учетом дизайна Kanban системы на уровне всей организации было проведено первое квартальное планирование (Program Increment Planning).
С учетом дизайна Kanban системы на уровне всей организации было проведено первое квартальное планирование (Program Increment Planning).
Результаты
Успехи трансформации, с учетом проведенного квартального планирования, которые повлияли на сокращение Time to Market:
- Стратегия банка доработана и стала доступной всей организации.
- Участниками планирования отмечено, что бизнес и IT начали взаимодействовать.
- Часть фич, подготовленных бизнесом к планированию, перенесены на следующий квартал из-за нехватки ресурса IT. Перенос визуализирован и принят бизнесом.
- Выявлено и разрешено огромное количество зависимостей.
- Все стримы получили четкую рабочую картину на квартал.
- Каждый стрим получил понимание, чем заняты остальные стримы.
- Рабочая нагрузка сервисных команд стала прозрачной и прогнозируемой.
- Риски отмечены командами и подсвечены стейкхолдерам.
“Доска зависимостей с квартального планирования.
Выявлено и разрешено огромное количество зависимостей”.
Выявлено и разрешено огромное количество зависимостей”.
Точки роста, которые удалось подсветить благодаря проведенной работе:
Инсайты трансформации:
Дальнейшее развитие трансформации:
- Недостаточное участие бизнеса в процессе подготовки и планирования.
- В исходном бэклоге элементы без установленного владельца и с неопределенными бизнес-целями.
- В исходном бэклоге чаще всего отсутствуют бизнес-приоритеты.
- В некоторых случаях бизнес-аналитики, а не представители бизнеса, принимают решение о датах выхода в прод, скоупе выпуска, а также о других важных вещах.
- В квартальном планировании участвуют не все представители команд.
- Существуют трудности с описанием бизнес-целей, препятствий и зависимостей на бизнес-языке.
- Не создан официально Центр Lean Agile компетенций, который должен поддерживать обмен знаниями внутри банка.
Инсайты трансформации:
- Высшее руководство должно быть полностью вовлечено в трансформацию, в противном случае возникнут проблемы с участием и самоотдачей остальных сотрудников.
- Трансформация должна реализовываться одновременно “снизу вверх и снизу вверх”.
- Трансформация невозможна без сильных продуктовых компетенций. Не обойтись без постоянного обучения.
- Kanban метод отлично работает во фреймворк SAFe.
- Kanban метод отлично подходит для управления работой вендоров.
- Большим организациям лучше выбирать Kanban метод, который позволяет упорядочить любые процессы, Scrum же лучше применять для небольших IT-компаний или команд.
Дальнейшее развитие трансформации:
- Применение формул расчета стоимости задержки поставки и приоритизации WSJF.
- Формализация ролей Service Delivery Manager и Demand Manager.
- Пересмотр WIP лимитов для портфельного уровня и стримов.
- Введение WIP лимитов для уровня Программы.
- Обучение руководства Kanban методу .
- Дальнейшее следование практике “Совместное введение улучшений, развитие с помощью экспериментов”.
Подойдет ли кейс вам?
Напишите нам, мы с вами свяжемся и подскажем, насколько такой подход применим в вашей ситуации.
Возможно будет интересно
Понравился кейс?
Хотите узнать. можно ли сделать и у вас что-то подобное? Напишите нам, мы свяжемся с вами и расскажем.