Ускорение трансформации с использованием SAFe® Agile Release Train

Вольный перевод статьи Running the transformation using a SAFe Agile Release Train.

Эта статья о том, как с помощью SAFe ART (Agile Release Train) удалось объединить специалистов, не связанных с IT. А ещё – о том, как изменялся формат и размер центра компетенции Lean-Agile (Lean-Agile Center of Excellence, LACE) во время запуска пятнадцати ART, каждый из которых достигал бизнес-целей. И как повлияло объединение не-IT специалистов из разных функций на организацию.

Контекст

Путем слияния и поглощения транснациональная корпорация выросла до 3000 сотрудников по всему миру. Большинство из них поставляли B2B-продукты для индустрии путешествий. В какой-то момент пришло понимание, что компания стала технологической, а значит пришло время думать и действовать по-другому. Компания была далека от продуктового подхода – в разработке стратегии и целеполагании участвовали только топ-менеджмент и отдел продаж.

Напряжение началось после успешного запуска первых трёх ART. Сотрудниками других подразделений трансформация воспринималась исключительно как новая активность инженеров, которая не влияет на остальную организацию. Если бы так и продолжилось, организация не смогла бы достичь желаемого уровня бизнес-гибкости.

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

Так и родилась сумасшедшая идея – трансформировать сам LACE в отдельный SAFe ART для управления зависимостями.

Действия

Процесс трансформации LACE в ART начался с локального уровня, через неформальную группу лидеров, недавних выпускников девятимесячного тренинга по развитию лидерских качеств.

Всего за один Инкремент Программы (Program Increment, PI) LACE превратился из одной Agile-команды в команду команд из 70 человек. Все участники были менеджерами среднего звена, готовые к изменениям. Были и сотрудники маркетинга, продаж, коммуникаций, HR, аккаунт-менеджеров и других функций. Амбициозные планы – продемонстрировать, что эти функции, которые обычно не вовлечены в Agile-процессы и не имеют необходимость плотно взаимодействовать, могут и должны это делать – для трансформации всей компании. С такой поддержкой на локальном уровне, стало понятно, что необходимо заручиться и поддержкой топ-менеджмента.

Некоторые функции, например, HR, вовлекались охотно, стремясь сделать организацию лучше. Вероятно, они даже не подозревали, на что подписываются!

Однако, не все соглашались так быстро. Для вовлечения людей требовалось много разговоров за чашечкой кофе с параллельной демонстрацией сайта SAFe и рисования на маркерных досках. Часто звучали вопросы: «Почему мы должны в этом участвовать? Какую пользу я из этого извлеку?».

Например, команда управления инфраструктурой организации. Сотрудники видели происходящее вокруг, включая регулярные крупные мероприятия вроде PI-планирования, но не понимали, что происходит. Команде объяснили, с какими вызовами сталкивается организация и связь этих проблем с возможностью быстрой поставки ценности на рынок. Они не были уверены до конца, но согласились попробовать присоединиться к ART, чтобы быть ближе к месту событий и хотя бы видеть, что делают остальные.

После сбора всех людей, нужно было запустить ART. Несмотря на то, что ART не-IT, шаги для его запуска были такими же. В процессе запуска SPC (SAFe Program Consultant) помогал с обучением, руководством и формированием команд, а также проведением PI-планирования.

Все запущенные ART работали по общим каденциям и синхронно, так что было решено масштабировать этот ритм на весь портфель. Тем более, что команде нужно было взаимодействовать с другими ART. Таким образом получилось синхронизировать наши дорожные карты, что позволяло другим поездам предсказывать и планировать влияние наших задач и активностей на них. Например, для 2 команд коучей и других 7 команд, это разрешило один из конфликтов, возникающих во время церемоний, так как коуч-сессии часто конфликтовали с календарями команд, с которыми они работали. Команды смогли адаптировать свои рабочие ритмы под потребности друг друга за счёт синхронизации.

Все команды нового ART имели Владельцев Продукта (Product Onwer, PO) и Scrum-мастеров (Scrum Master, SM). Однако, они могли совмещать эту роль с какой-то другой и имели мало представления о своих новых ролях в целом. Появилась потребность в дополнительном коучинге.

Миссией ART было побудить к изменению рабочих процессов во всей организации для уменьшения Time To Market и фокуса на работе, которая приносит наибольшую ценность. Для того, чтобы измерить эффективность ART и ценности PI, было решено обратиться к опережающим показателям, так как успех на долгосрочной перспективе ART был связан с запаздывающими показателями бизнес-результатов.

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

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

Три PI спустя поезд трансформации добился большого прогресса. Было запущено 15 поездов, стали видны измеримые результаты для бизнеса, включая предсказуемость на уровне 85% и сокращение Lead Time на 50-90%.

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

На этой фазе ценность LACE была куда выше, чем 15 поездов, которые были запущены. Начав с выпускников программы развития лидерских качеств, центр разросся до крупной сети агентов изменений. Помимо этого, команды научились взаимодействовать друг с другом вне зависимости от функциональных и географических границ.

Воодушевляло то, что за счет успеха ART трансформации и других поездов, возрастало количество отделов, которые задавались вопросом: «Можно ли и здесь работать по Agile?» Произошло это за счет того, что выросло и количество SPC внутри компании. Например команда go-to-market, которая до этого сидела на периферии и замедляла разработку новых продуктов. При поддержке SPC они стали Agile-командой – начали работать по тем же каденциям и синхронизироваться вместе с другими командами, что привело к сокращению Lead Time.

Трансформации порождают сопротивление. Кто-то был бы рад, если бы ART трансформации провалился. Было мнение, что изменение структуры поезда означало, что была допущена ошибка в дизайне и на этапе его внедрения. На самом же деле изменение структуры – проявление гибкости организации.

Сейчас компании не нужна отдельная команда трансформации. Использование Agile-практик на уровне всей организации стало нормой для них.

Выводы

1. Делитесь историями успеха внедрения вне IT.

Каждому, кто скажет, что Agile работает только в IT-среде, ответьте, что функция – не показатель. Если у вас есть LACE – возможно, эта команда сможет стать примером. Если примеры сложно найти – воспользуйтесь примером из статьи или другими, которые получится найти.

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

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

3. Избегайте закапывания в детали, когда рассказываете идею.

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

4. Помогайте командам в декомпозиции работы на небольшие кусочки ценности.

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

5. Оцените, какую пользу может принести даже неполное вовлечение.

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

6. Создайте место для рутинных задач.

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

7. Дизайн и размер Agile-команд и команды команд будет меняться в соответствии с потребностью.

Как было разобрано в примере, по мере адаптации LACE, Agile-команды или ART будут со временем меняться в размере и составе в зависимости от нужд организации. И это нормально.

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