SAFe® в России
Дата: 27.02.2021
Статистика распространенности Scaled Agile Framework® на российском рынке, а также компании, применяющие этот лидирующий в мире подход обеспечения Business Agility для крупных компаний.
Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.
Сегодня у меня отчетная история о том, что происходит в России со Scaled Agile Framework® (SAFe®). Это лидирующий в мире подход к обеспечению Business Agility, то есть бизнес-гибкости, умения компании разворачивать себя от изменений, волатильности рынка и потребителей. Лидирующий в мире, а что с ним происходит в России? Кто меня еще не знает, я — продюсер этой конференции. Кроме этой конференции, весной мы проводим конференцию OKR Russia. Это очень связанная тема с SAFe. А также проводим исследование «Agile в России», чтобы вы могли ориентироваться на свою отрасль: что делают другие игроки в этой отрасли, что уже пробуют с точки зрения Business Agility — чтобы вы могли ориентироваться, куда двигаться дальше.
Бизнес-гибкость — это способность конкурировать и процветать в цифровую эпоху, быстро реагируя на рыночные изменения и возникающие возможности с помощью инновационных, цифровых бизнес-решений.
Исследование Agile в России
Я из компании ScrumTrek. Мы большие. Ровно поэтому мы уже четвертый год проводим исследование Agile в России. В этом году исследование завершилось и отчет будет опубликован через месяц, мы его вам принесем под новогоднюю елку (отчет уже опубликован: https://agilesurvey.ru). Исследование является крупнейшим во всем мире. Мы можем это гарантированно утверждать, потому что мы смотрим, что делается во всем мире. Самый известный мировой отчет State of Agile делает компания Digital.ai (ранее назывались CollabNet, VersionOne). По количеству респондентов мы и в прошлом году, и в этом году рулим. Зачем нам нужно большое количество участников? Потому что тогда мы можем делать статистические выборки. Например, что если взять все крупные компании профиля Large Enterprise (1000+ сотрудников) среди финансов и посмотреть, что у них взлетает, что не взлетает, чтобы рассказать другим игрокам такого же профиля.
Масштабирование Agile
Что такое масштабирование Agile? Мы иногда шутим, что многие занимаются лоскутной аджайлизацией: «Давайте вот в этом проекте запустим Agile! И вот в том тоже». Это вместо того, чтобы понять, что отдельные Agile-команды стоят на цепочке поставки ценности для клиента, которую многие называют Customer Journey Map, а SAFe называет Operational Value Stream. Это шаги бизнеса по привлечению клиента в каналы продажи решения его проблем, шаги получения услуги, шаги обслуживания клиента при каких-то проблемах в использовании продукта. Нужно начинать отстраивать Agile-команды вдоль таких цепочек улучшения жизни клиентов, формировать то, что чаще всего называют стримами, а в Сбербанке называют трайбами. Идея в том, чтобы нацелить совокупность команд на клиента в целом, на всю цепочку его бед или, может быть, успехов при взаимодействии с компанией.
В прошлом году очень сильно выросла популярность SAFe. Мы это диагностировали по количеству практиков, которые ответили, что начали применять эту штуку. Таким образом, популярность подхода: «Давайте сразу придумаем свой собственный подход, напишем свой CookBook и полетели» — начинает падать. Кажется, народ уже понимает, что проще стартовать с того, что накопило хоть какой-то мировой опыт, а только потом уже адаптировать его постепенно.
Operational Value Stream (OVS), Поток Поставки Ценности – это последовательность действий, необходимых для поставки продукта или услуги клиенту.
Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Кто применяет?
Какие отрасли? Конечно же, айтишники прежде всего, как и всегда, потому что изменчивость их отрасли, в целом рынка и клиентов максимальна. Финансы — это вторая волна аджайлизации. Ждем третьей большой волны в телекоме и даже тяжелой промышленности (рекомендую сегодня сходить на доклад компании Северсталь, именно они, скорее всего, попали в эту статистику, они тоже начинают эксперименты с этим подходом).
Что происходит с точки зрения размера компаний, какие компании пробуют этот подход? Конечно, сам подход ориентирован на профиль Large Enterprises, то есть более 1000 сотрудников. Но больше практиков оказалось именно в компаниях Small and Medium Enterprises (SME), то есть от 200 до 500 сотрудников. При таком размере уровень хаоса, который вы привносите при экспериментировании с такими подходами, более контролируемый, то есть там проще стартовать.
Сколько лет компании применяют Agile и в какой момент они приходят к вопросу того, что давайте уже систематизируем то, как у нас работает Agile на уровне команд и начнем всю компанию отстраивать, чтобы вся компания в целом была ориентирована на клиента, а не отдельные клеточки нашего организма хаотично пытались как-то улучшить, при этом толкаясь, завися друг от друга, мешая друг другу. В целом, минимум 1 год у вас уйдет, если вы реально крупная компания, на то, чтобы у вас сотрудники на уровне команд научились и поняли смысл работы Agile, то есть по сути, четырех ценностей: взаимодействие людей все-таки чуть-чуть важнее, чем процессы и инструменты и так далее — то есть чтобы вы отстроили уровень команд. Только через год возникает вопрос: как нам сделать так, чтобы все команды не толкались, а были связаны единой целью, в идеале с метриками. Это происходит где-то на втором году. Как раз здесь столбик и повышается. На втором году кто-то до этого еще не доходит, догоняется на третьем.
Проблемы масштабирования Agile
С какими проблемами компании сталкиваются при масштабировании Agile, когда поднимаются выше команд, чтобы все команды были нацелены на свой сегмент клиента, понимали его, а также умели внутри компании между собой договариваться.
- Все и всегда, конечно же, говорят, что топ-менеджмент не вовлечен в трансформацию, именно поэтому все и не работает. В принципе, это классика жанра. В крупной компании низы на самом старте пока не готовы брать ответственность за вещи, за которые классически отвечал менеджмент, а топ-менеджмент пока еще боится делегировать большую ответственность вниз.
- Внедрение общих инструментов между командами. На старте на большом масштабе потребуется какой-то стандартный подход, большая книжка, в которой написаны решения на максимальное количество популярных проблем с масштабированием Agile. Ровно поэтому мы и рекомендуем стартовать с классических стандартных подходов, потому что такие книжки уже выверены: огромное количество леммингов по всему миру уже пробовали это — и минимальное их количество столкнулось с проблемами. Соответственно, становятся важны IT-инструменты, которые могут автоматизировать следование этим регламентам, отображать необходимые отчеты и так далее.
- Третий пункт – это поддержка этого начинания большинством сотрудников. Самое интересное. По статистике с ростом количества лет вступления на путь масштабирования Agile этот третий параметр постепенно поднимается до первого, то есть становится самым важным. Наконец-то начинает работать вовлечение сотрудников в улучшение процессов, которые изначально взяли из книжки и настроили как готовые. Готовьтесь к тому, что на старте будет тяжело. На большом масштабе вам нужно дать готовый рецепт. Вам, как менеджменту, нужно поддержать своих сотрудников сверху. Но готовьтесь постепенно отдавать полномочия, постепенно напрягать специалистов: ребята, вы должны сами работать над улучшением своих процессов.
Ожидания и реальность
Какие цели себе ставили компании, которые пробовали SAFe, чего они по факту добивались?
Обратите внимание на топ-5 результатов.
Мотивацию никто не ставил себе в цель. Никто не ожидал, что этот подход приведет к мотивации сотрудников. Оказывается, это вы получаете бесплатно, потому что сотрудники наконец-то понимают, например, через квартальное планирование, что происходит с бизнесом, что думают о нем клиенты, на чем все должны сфокусироваться в этом квартале, почему нужно взаимодействовать с другими командами. Раньше казалось, что Agile-команда самобытная. Нет, необходимо взаимодействовать с другими командами, потому что только вместе с ними совместно можно улучшить соответствующий шаг клиента при получении услуги, где он испытывает ключевые проблемы.
Колоссально повышается прозрачность, потому что SAFe дает вертикальный набор встреч на каждом из уровней:
- Портфельный уровень, уровень синхронизации ваших бизнес-направлений между собой, да еще и с вендорами.
- И синхронизация на уровне команд между собой, чтобы все понимали, почему связаны, как зависимости отражаются на улучшении жизни клиента.
Портфель — это набор потоков ценности, который обеспечивает непрерывный поток ценных решений для клиентов в рамках общей модели финансирования и управления.
Кейсы российских компаний
В прошлом году мы провели первую российскую конференцию по теме Enterprise Agility. Тогда контента было примерно в 4 раза меньше, чем сегодня. Сегодня у нас на конференции присутствует 24 практика SAFe, из них 6 – мировые эксперты. Также в этом году нас заметили авторы SAFe, компания Scaled Agile Inc., и стали генеральным спонсором этой конференции.
Благодаря конференции мы знаем практически все примеры применения SAFe в России. Вообще очень сложно незаметно применить такую масштабную штуку как SAFe, чтобы рынок или мы, как организаторы таких конференций, этого не заметили.
Это публичные кейсы: ребята согласились, чтобы мы рассказали о них — здесь есть IT, финансы, ритейл.
В параметрах кейсов показано:
- ARTs – это количество поездов (Agile Release Trains), то есть стримов или трайбов, которые сфокусированы максимально на всю цепочку поставки от и до на конкретный сегмент клиентов компании.
- Дальше цифра FTE – это количество сотрудников, вовлеченных в эти изменения. К примеру, в Kaspersky 400 человек, а в Технологическом Центре Дойче Банка в России аж 1,5 тысячи сотрудников.
- А также сколько лет назад компания встала на этот путь — это показывает уровень зрелости этого кейса.
Agile Release Train (ART) — это долгосрочная команда Agile-команд, которая инкрементально разрабатывает, внедряет и часто эксплуатирует одно или несколько решений в рамках потока разработки ценности.