Конференция Enterprise Agile Russia
Воркшоп по планированию портфелей и программ - SAFe® City
Масштабирование Agile по SAFe®
Блог >

Самостоятельное внедрение SAFe®: 5 кейсов российского рынка

Кейсы Scaled Agile Framework® в eLama, АвтоТрансИнфо, Лаборатория Касперского, Сбербанк и iiko.

Руководитель группы Agile-трансформации в компании-разработчике платформы по управлению интернет-рекламой eLama, руководитель отдела разработки биржи грузоперевозок АвтоТрансИнфо, руководитель отдела корпоративных продуктов и руководитель отдела тестирования корпоративных продуктов Лаборатории Касперского, директор дивизиона «Розничное взыскание и урегулирование» Сбербанка и CEO сервиса автоматизации процессов предприятий общественного питания iiko рассказывают о том, как они внедряли фреймворк SAFe® в своей компании, не прибегая к помощи внешних консультантов.

1. Почему вы решили внедрять SAFe? Какие цели преследовали?

Иван Лавров, руководитель группы Agile-трансформации eLama:

В какой-то момент возникла задача: соединить стратегические цели компании и направления, в которых двигались маркетинг и разработка. Следовательно, нужен был такой подход и набор практик, которые бы позволили командам вместе и планировать, и работать над проектами, и достигать квартальные цели. В SAFe мы нашли то, что нам нужно, — идеи, связанные с PI-планированием и System Demo (мы внедряли только эти элементы фреймворка).

Егор Попов, руководитель отдела разработки АвтоТрансИнфо:

С ростом отдела разработки возникла проблема — рассинхронизация восьми команд. Они работали по Scrum, но начинали спринты в разное время. Единственным, кто знал обо всех проектах, был собственник бизнеса. Всё это приводило к расфокусировке долгосрочных планов: планирования тянулись всю неделю, с каждой новой командой менялись приоритеты, реализация планов по запуску новых продуктовых элементов не превышала 50%.

Александр Колесников, руководитель отдела корпоративных продуктов и Антон Киселев, руководитель отдела тестирования корпоративных продуктов Лаборатории Касперского:

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

Денис Кузнецов, директор дивизиона «Розничное взыскание и урегулирование» Сбербанка:

После перехода на Agile мы столкнулись с рядом вопросов по целеполаганию, координации команд, оценке результатов. Изучали разные подходы, пытаясь подобрать такой, который бы подошёл нашим требованиям, масштабам и задачам. На учебных курсах познакомились с методологией масштабирования SAFe, после чего решили, что она частично удовлетворяет нашим запросам, и попытались внедрить у себя лучшие практики.

Роман Аврамов, CEO iiko:

Мы разрабатываем ERP-систему для автоматизации ресторанного бизнеса. Наш продукт используют более 30 000 клиентов в 35 странах мира. Это совершенно разные заведения: от крохотных кафе до международных ресторанных сетей, с различными концепциями. У них разные потребности в функционале. Кроме того, в каждой стран есть свои законы и стандарты, и они меняются. Нам необходимо быстро на это реагировать, отражая изменения в продукте.

Наш старый подход к разработке был близок к Agile, но все же не позволял нам выпускать новые решения с нужной скоростью. Мы выпускали новую версию раз в три месяца. В процессе изучения существующих фреймворков решили, что SAFe лучше подходит для наших нужд.

2. Как строилась работа по внедрению?

Иван Лавров (eLama):

Сформулировав стратегические цели компании и получив две недели на подготовку к общему планированию, мы создали команду волонтеров из топ-руководства: СТО, CPO, представителей HR. Поскольку само планирование — задача более простая, чем подготовка сотрудников (и с точки зрения мотивации, и чисто технически), — мы в первую очередь сосредоточились на подготовке сотрудников.

Что мы сделали:

  • Составили подробный список мероприятий.
  • Встретились с командой разработки, продуктовыми менеджерами, командой продуктового маркетинга. Ответили на их вопросы.
  • Подготовили шаблоны и пояснения.
  • Рассказали о пользе планирования внутренним заказчикам.

В процессе у нас появлялись идеи адаптации предложенного по умолчанию варианта планирования под нашу компанию. Очень полезным было изучение кейса компании Lego, где процесс планирования внедрял Хенрик Книберг (прим. ред. — этот кейс описан в книге Совместное планирование).

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

Егор Попов (АвтоТрансИнфо):

Мы не пользовались внешним консалтингом, но обучались. Было две волны. На первой, я лично присутствовал, проходя тренинг у Анны Обуховой в мае 2017. Вторая волна обучения проходила для двух других сотрудников компании уже после запуска SAFe. Выходя с обучения, я был уверен, что внедрить SAFe в полном объеме не удастся из-за нехватки квалифицированных и погруженных в данную методологию людей. Поэтому выбрал несколько инструментов, с которых началось построение нового процесса. Сделал вводный доклад в конце года на внутренней конференции, и с января 2018 запустили первый PI. На мой взгляд, успех трансформации зависит во многом от руководства, от его поддержки и доверия сотрудникам. С этим нам очень повезло — спасибо огромное Святославу Вильде.

Александр Колесников и Антон Киселев (Лаборатория Касперского):

За несколько месяцев до начала внедрения провели общий тренинг по SAFe для руководства, которое загорелось идеей. В нашем случае все произошло и просто, и сложно одновременно: буквально через две недели после реорганизации мы начали использовать элементы SAFe.

На подготовку первого PI отвели неделю, но быстро поняли, что за это время полноценную подготовку провести маловероятно, и решили ограничиться внедрением только элементов SAFe в одном из крупных проектов. PI назвали «Купе» — от QP, то есть Quarter Planning (квартальное планирование). Название к тому же перекликается с термином Agile Release Train. В общем, полноценный поезд не строили, а делали отдельные вагончики.

После этого перераспределили функциональные группы разработчиков и тестировщиков, добавили к ним аналитиков и архитекторов. Назвали каждую такую команду «фича-тим». Сделали подобие системных команд, которые назвали экспертными командами.

Для работы над самыми важными фичами приглашали ключевых заинтересованных лиц, с которыми впоследствии тесно взаимодействовали. Аналитики становились фича-оунерами, лиды команд — Scrum-мастерами, проектные и тест-менеджер — кем-то вроде RTE,  продуктовые менеджеры — остались продуктовыми менеджерами. В итоге мы провели два «Купе» со всеми необходимыми встречами и артефактами.

Денис Кузнецов (Сбербанк):

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

Роман Аврамов (iiko):

Все началось с обучения: курсы по SAFe прошли топ-менеджеры, в том числе и я, а также все проектные менеджеры. Мы шли в комфортном для себя темпе и не пытались внедрить весь SAFe сразу. Примерно через месяц после обучения у нас была очередная трехмесячная итерация. Мы провели её уже с применением некоторых методик SAFe, а именно PI-планирования и WSJF для приоритизации фич. В следующих итерациях выделили роли владельцев продукта и запустили метапроцесс: после каждой итерации проводили ретроспективу и оценивали, что можно улучшить. Так в ходе каждой итерации мы постепенно внедряли по 2-3 новых элемента SAFe.

3. Какие изменения произошли за прошедшее время? Можно ли подвести итоги внедрения?

Иван Лавров (eLama):

За год мы провели четыре планирования. Уровень подготовки к планированию, самих планов и участников существенно повысился. Планирование привело и к развитию компании в целом, и к тому, что команды стали работать эффективнее. Решение задач по улучшению процессов, которые перед нами стояли год назад, открыли возможность посмотреть на более глубокие и, возможно, более комплексные задачи.

Егор Попов (АвтоТрансИнфо):

Можно выделить два ключевых изменения:

  1. Средний уровень закрываемости задач вырос до 80%, у двух команд — до 100%.
  2. Каждую вторую пятницу проводим и записываем демо. Запись помогает, потому что к ней всегда можно вернуться и уточнить нужные моменты.

Александр Колесников и Антон Киселев (Лаборатория Касперского):

Положительные итоги:

  • Стали тратить меньше времени на мусорные требования: команды из модели push перешли в модель pull.
  • Work Time и Lead Time уменьшились в два раза: не из-за ускорения, а из-за ограничений каденции.
  • Впервые за многие годы выпустили релиз в срок, что отметили коллеги. Релиз проходил гораздо спокойнее.

Отрицательные итоги:

  • По неопытности допустили много ошибок.
  • Перегрели часть команды.
  • Стали тратить гораздо больше времени на коммуникации, иногда слишком много. В некоторых командах в этом отношении даже развился карго-культ.
  • Не смогли довести инфраструктуру до нужного уровня CI/CD.
  • SAFe в рамках одного изолированного проекта не работает: не удалось вовлечь коллег из соседних подразделений.
  • Не все смогли внутренне перестроиться на работу по новому подходу.
  • Учиться на RTE пошли в самом конце эксперимента.

Сейчас команда приходит в себя после перегрева, в следующем году будем пробовать запуститься еще раз.

Денис Кузнецов (Сбербанк):

Рабочие процессы и результаты трайба в целом стали более прозрачными и прогнозируемыми. Проще стало учитывать взаимосвязи команд, планировать и приоритезировать задачи. Сократилось пересечение между командами, появилось планирование, начали работу с метриками.

Роман Аврамов (iiko):

Положительные результаты стали заметны уже после первой итерации с применением методик SAFe. Мы стали лучше попадать в сроки, а качество продукта стало выше. Раньше бывало так, что в релиз попадало не более 80% от запланированного функционала, а сроки выпуска сильно сдвигались: 3 месяца легко превращались в 4. То есть, сейчас мы стали делать быстрее и больше, чем раньше: теперь релиз на 90-95% соответствует плану.

Это происходит во многом потому, что в планировании, оценке задач, декомпозиции работы теперь участвуют не только проектные менеджеры, но и разработчики. Процесс планирования стал более прозрачным и чётким. У нас два офиса разработки, и мы привозим казанскую часть команды в Москву, где они совместно планируют задачи. В результате они чувствуют большую ответственность и нацелены на то, чтобы выполнить задачу в согласованные с ними сроки.

Кроме того, команда разработки стала работать более слаженно и сплоченно. Ушло дублирование — раньше две команды могли делать параллельно похожие задачи. Мы перешли к процессу, при котором сохраняется трёхмесячный цикл планирования, но релизы выпускаются каждые две недели. Это очень большое достижение, к которому мы пришли за шесть трёхмесячных циклов — то есть за полтора года.

4. Насколько легко внедрять SAFe самостоятельно?

Иван Лавров (eLama):

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

Егор Попов (АвтоТрансИнфо):

Самостоятельное внедрение — относительное понятие, так как у нас не было опытного наставника, который сказал бы: «…тут вы делаете не так, а здесь это не сработает». Но в целом, внедрять SAFe даже проще, чем Scrum, так как все практики описаны, структурированы и сведены до уровня «бери и делай»!

Александр Колесников и Антон Киселев (Лаборатория Касперского):

Сложно, особенно если нет предварительной подготовки как на уровне менеджмента, так и на уровне команд. Важно сначала внутренне перестроиться для работы на новый лад и выделить продолжительный период времени для подготовки.

Денис Кузнецов (Сбербанк):

Не могу судить о сложности самостоятельного внедрения SAFe как такового, потому что мы для себя взяли только те элементы, которые посчитали полезными и эффективными с учетом нашей среды. Реализованные изменения дались нашей команде относительно легко благодаря помощи коучей, общему обучению SAFe, а также реальной поддержке руководства и командной культуре готовности к изменениям.

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

Роман Аврамов (iiko):

Не могу сказать, что было очень сложно, но могу сформулировать несколько советов, которые точно облегчат жизнь тем, кто решится внедрять SAFe самостоятельно:

  1. Обучите ключевых сотрудников основам SAFe.
  2. Выявите основное ограничение в текущем процессе разработки. Если команда проводит ретроспективу — её результаты могут натолкнуть на нужные мысли, если нет — пройдите самостоятельную оценку по ScrumButt Test или подобной методике.
  3. Выберите не больше пяти элементов SAFe, которые могут помочь преодолеть это ограничение, и внедрите именно их в ближайшей итерации.
  4. Повторяйте пункты 2 и 3.

Кроме того, для успешного внедрения SAFe важны:

  • Корпоративная культура организации и внешняя среда, допускающие работу по Agile. Успешное внедрение SAFe вряд ли возможно, например, в «красных» организациях (по классификации Фредерика Лалу).
  • Чёткая и понятная цель предстоящих изменений в процессах.
  • Мотивированная команда, которая осознаёт несовершенство текущей методики и готова активно участвовать в изменениях.

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

20 дек 2019 , Сергей Рогачев
Другие статьи
25 фев 2020 , Иван Селеверстов
Играем в покерную оценку динамики на OKR Weekly Check-In

Данная статья посвящена разбору одного инструмента фасилитации, который хорошо работает на одной из OKR-встреч — Weekly Check-In.

13 янв 2020 , Дмитрий Кустов
Гайд по технике Jobs To Be Done (JTBD)

Что такое Jobs To Be Done (JTBD). Как начать использовать технику и сделать ваши продукты круче.

22 дек 2019 , Константин Хохрин
Как провести дизайн Agile Release Train: #1 — Концепция

Как определить правильную организационную структуру, объединяющую бизнес, команды и менеджмент? Часть первая — определяем общую цель.