Кейсы agile-трансформации, часть первая: банки

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

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

Поэтому в этой, девятнадцатой статье серии «Менеджмент цифрового мира» (оглавление) я начинаю рассказ о кейсах, чтобы в совокупности дать многовариантную картину. Я думал, что статья будет одна, но материала – много, и будет продолжение. В этой статье речь пойдет о трансформации банков, при чем не IT-подразделений, многие из которых применяют Agile-методы уже 7+ лет, а работы бизнеса в целом.

Мои источники – доклады на профильных конференциях – AgileDays, Agile Business и других, а также разговоры в кулуарах конференций и другие частные разговоры. Там, где это возможно, в статье будут ссылки на конкретные доклады. По конференциям я публикую отчеты, они есть на моем сайте, и конспекты большинства упомянутых здесь докладов есть в отчетах с соответствующих конференций.

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

Итак, начну я с истории Agile-трансформации Сбербанка. Публичным началом этой истории является выступление Германа Грефа на Гайдаровском форуме-2016 (ссылка на запись 28 минут, в сети есть другие), которое существенно повлияло на распространение Agile-методов в России и заслуживает отдельного анализа. В большинстве выступления изложений в СМИ фокус был на то, что «Греф назвал Россию страной-дауншифтером», в то время как реальным сообщением была необходимость перестройки госсистем и, особенно образования, если Россия не хочет оказаться в числе стран-дауншифтеров (07:40-12:00). Это как раз к вопросу о том, почему полезно смотреть первоисточники, а не изложения СМИ. Но в контексте этой статьи интересно то, что говорится дальше.

Несколько лет Сбербанк вел централизацию своей IT-разработки, сосредоточив ее в отдельной структуре Сбертеха. Отдельные команды могли работать по-разному, в том числе по agile, но в целом применялось классическое проектное управление. И из него было выжато все, что возможно, при этом получилось достичь квартальных релизов для всего комплекса систем Сбербанка. Это – очень часто по тем временам, Microsoft примерно тогда говорил о переходе к квартальным релизам Visual Studio как о супердостижении.

При этом весь цикл реализации запроса на разработку, если он требует изменений в нескольких основных системах, получилось сократить от нескольких лет до 9 месяцев. Но вот меньше – не получалось. По сравнению с крупными глобальными банками это все равно достойный результат, и Греф в своем докладе говорит о том, как они гордились своими достижениями. Но при этом оказалось, что по сравнению с Google, Amazon и другими лидерами цифрового мира это – совсем не достижения (14:00-15:00).

И вот в 15:40-16:40 Греф говорит про ставку на Agile и Scrum: «Все будет построено на Agile», «Те, кто не освоят Agile в текущих бизнес-процессах, будят лузерами завтра». А дальше, с 17:20 он говорит про горизонтальную культуру. Незадолго до этого Герман Греф прочитал Джеффа Сазерленда «Scrum» и Фредерика Лалу «Открывая организации будущего», и эти книги были рекомендованы для прочтения всему Сбербанку. И на Гайдаровском форуме он публично объявил о ставке на эти технологии управления.

На мой взгляд, это вовсе не было пиаром или данью какой-то моде, про Agile в широких кругах в то время вообще почти никто не говорил, хотя AgileKitchen в Аппарате правительства по применению Agile в госпроетах и была раньше, в конце 2015 (мой отчет). Да и достижения Сбера были реальными, если кто помнит разницу между его отделениями конце нулевых и в 2016, то изменения разительны. А позиции Сбера в стране – устойчивы.

Моя гипотеза в том, что Грефу поставили задачу сделать Сбербанк глобальным банком. Он начал готовить IT-инфраструктуру классическим образом, достиг сопоставимого с глобальными банками уровня. А потом обнаружил, что на западные рынки Сбербанк не пускают административно, а на восточных надо конкурировать не с банками, а с Телекомом и Али-бабой, а у тех развитие идет гораздо быстрее. Это, конечно, лишь гипотеза. В любом случае, ставка на Agile была публично объявлена.

Теперь о том, что было дальше. Первый такт развития Agile в Сбербанке – 2016 год. Трансформацию консультировали McKinsey и ScrumTrek, McKinsey обеспечивал политику в большой корпорации и референс-визиты по всему миру, а ScrumTrek – собственно Agile-процесс на основе SAFe. Основная задача – максимально расширить Agile-сообщество, начали они с 16 команд в мае, осенью их было уже 75. При этом в Agile был вовлечен не только IT, но и бизнес, создавались совместные команды бизнеса и IT, нацеленные на вывод новых банковских продуктов, в них вместе работали сотрудники Сбербанка и Сбертеха. Команды были организованы в крупные племена, работали в общем пространстве и культурная трансформация относительно традиционной корпоративной культуры была очень сильной.

Точкой синхронизации является 8-недельный PI planning, и они учились его проводить в форме однодневной встречи на 80 человек на первой сессии до 260 осенью, с эффективной фасилитацией. Обо всем этом рассказывали Юлия Молостова вместе с Алексеем Пименовым в сентябре на AgileBusiness-2016 (мой конспект), процесс вовлечения новых команд развивался и далее, но до самой интересной инженерной части вовлечения архитекторов, ответственных за старые legacy-системы дело не дошло.

Второй такт начался весной 2017 с приходом в феврале Барта Шлатмана. На AgileDays-2017 делал доклад уже он, хотя рассказывал о том, что сделано ранее. Барт пришел из нидерландского банка ING, в котором для организации работ применялась собственная версия Agile, и он ставил в банке именно ее, отчасти отказываясь от того, что было раньше, например, от роли Scrum Master. Что-то пошло не так, и ожидания не оправдались, потому что через год, в феврале 2018 Барт покинул Сбербанк. Скорее всего при бурном росте все-таки была потеряна прозрачная результативность. И начался третий такт.

Трансформация не свернута, она продолжается, и не только потому, что процесс развития самоорганизующихся команд, в общем-то, можно остановить только вместе с увольнением сотрудников. Главное – те вызовы, для ответа которым была сделана ставка на Agile, по-прежнему актуальны, а альтернативных вариантов не существует. Насколько я знаю, Scrum Master снова появился, в некоторых племенах пророс LeSS, идет разнообразная активность. А на верхнем уровне Банк силами собственных сотрудников пробует обеспечить прозрачность потока ценности через Kanban и работу с метриками, и вроде продвигается в этом направлении успешно. Впрочем, публичных выступлений по дальнейшему развитию Сберджайл я в последние два года не слышал.

В любом случае, на старте все эксперты предупреждали, что трансформация займет не меньше 5-7 лет, а результат на таком масштабе не гарантирован. Так что ждем продолжения. А здесь я хочу отметить, что мы имеем весьма характерный кейс, когда проводят Agile-трансформацию для того, чтобы стать быстрыми, но сам проект трансформации разворачивают в старом стиле медленных многолетних проектов. И хотя привлекают консультантов и коучей, которые понимают как быстро вести изменения, условия разворачивания проекта и сама культура его проведения – медленная и неспешная.

А главное – без внимания к ценности результата. Именно это отличает классическое проектное управление, в нем главное – выполнить запланированный объем работ, а не получить ценность на выходе. И это зафиксировано в методологии: вопрос использования созданного в проекте вынесен за его рамки, на уровень программы, несколько лет назад я писал об этой проблеме статью «Проекты — для достижения результата, а не для освоения бюджета» для профильного журнала «Управление проектами». И потому результатом такой трансформации будет выполненная перестройка организации, а вопрос о результативности перестроенной организации для тех, кто ведет проект, будет вторичен. Этим кейс Сбербанка отличается от следующего кейса трансформации Альфа-банка.

Альфа-банк пошел по принципиально другому пути. Крупными мазками об этом на той же AgileBusiness-2016 рассказывали Алексей Марей (главный управляющий директор Альфа-Банк) и Сергей Дмитриев (Unusual Concept) (видео, мой конспект). Когда было принято решение об Agile-трансформации, то на добровольной была собрана команда топ-менеджеров, ответственных за ее проведение, проведены тренинги и другая подготовка. А дальше выбрано два пилотных сегмента – обслуживание среднего и мелкого бизнеса и обслуживание VIP- физ.лиц, и в них начали запускать смешанные команды бизнеса и IT в том темпе, в котором получалось обучать и запускать команды при ограниченном ресурсе коучей.

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

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

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

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

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

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

Из других кейсов Agile-трансформации банков очень интересным, на мой взгляд, является банк Агророс. Это небольшой региональный банк, в нем 350 сотрудников, есть региональные отделения. Трансформации подверглось операционная деятельность банка. Об этом на AgileDays-2019 рассказывал председатель правления банка Дмитрий Кондрацков, а доклад так и назывался «550 дней Agile в операционном управлении!» (мой конспект).

Неожиданно то, что применялся Scrum в чистом виде. Он был выбран потому, что хорошо работает с запутанной системой по Кеневин (подробности есть в моей статье «Место Agile-команд в компании»), а именно к таким системам относится банк: надо экспериментировать и отрабатывать варианты для новых продуктов и решения для проблемных точек.

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

Параллельно - трансформация центрального офиса, отделы по Scrum. Стратегия в офисе - идти от проблемных отделов: кредитный отдел, просрочки, информационная безопасность и далее. Если отдел работает неплохо - не надо менять. Стабильный поток задач хорошо обрабатывает Kanban. Продуктовые команды тоже работают по Scrum. Взаимодействие идет через демо, на нем возникает вовлеченность и сопричастность, а текущее взаимодействие обеспечивают Product Owner. На уровне банка в целом все это синхронизировано через по OKR (Objectives and Key Results).

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

Естественно, успешная трансформация не гарантирована. И тут важно относиться к изменениям как к эксперименту и регулярно оценивать успешность и уместность продолжения. Думаю, достаточно интересным примером является один из банков в Петербурге. Несколько лет назад они начинали трансформацию, провели пилот. Потом оценили полученные выигрыши, посмотрели на слабую совместимость новой структуры с более консервативным менеджментом, в котором основная масса менеджеров умеет работать – и отказались от продолжения, вернулись к привычным подходам. И это, на мой взгляд, очень конструктивный кейс: мы провели эксперимент и признали неудачным. Очень часто люди не готовы к такой оценке и продолжают изменения, даже когда понятно, что не просто первоначальные цели достигнуты не будут, а сомнителен выигрыш в целом.

Если говорить про другие известные кейсы Agile в банках, то сразу вспоминаешь Райффайзен и Тинькофф. Я не буду много говорить, хотя каждый из них типичен по-своему. Райффайзен – это организация, открытая ко всему новому и активно экспериментирующая с этим. Agile в нем имеет свою историю с успехами и отступлениями. Можно посмотреть выступления на Agile Business-2017, на Agile Days-2018 и другие.

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

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

На этом я завершаю первую часть рассказа про кейсы Agile-трансформации. Продолжение следует…