Второй такт начался весной 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-культура, которую несут команды, пускает щупальца по всему банку. А вот если решить не получилось, то команда должна сделать две вещи: на ретро обсудить проблему, подумать, у каких других команд она может проявиться, проконсультироваться у них – вдруг там нашли решение. Если убедились, что проблема – системная и мешает нескольким командам – то они вывешивают тикет на стену плача. Стену плача раз в месяц разбирают топы из команды поддержки. Менеджер, который не оказал поддержки и не эскалировал получает желтую карточку за саботаж трансформации, и как в футболе – за три карточки может быть уволен.