Тематические исследования SAFe: заметки о трансформации с мест

Эта статья является третьей частью серии статей Toptal по Agile-масштабированию, предназначенной для руководителей проектов в их усилиях по расширению команды. Обязательно прочитайте первую часть «Сравнение 5 Agile Scaling Frameworks: какую из них следует использовать?» и часть вторая, «Agile Scaling: передовые практики SAFe для Scrum Masters».

По данным 15th Annual State of Agile Report , 94% компаний так или иначе практикуют Agile. Но исследования также показывают, что 90% организаций испытывают трудности с внедрением Agile в масштабах предприятия. Как правило, это работа Agile-коучей, Scrum-мастеров и других специалистов по управлению проектами, которые возглавят и организуют эти усилия. Часто они работают с командами или отделами, сопротивляющимися изменениям, в корпоративной культуре, которую трудно понять.

На этом круглом столе три менеджера проектов Toptal обсуждают проблемы ведущих трансформаций Agile. Поскольку их решения совместимы с Scaled Agile Framework (SAFe), мы также поговорили с Дином Леффингуэллом, создателем SAFe. Их коллективные идеи иллюстрируют необходимость для практиков SAFe подготовить четкое видение того, что такое гибкость, и план лидерства, который может привлечь непокорные команды.

Разговор о безопасности с создателем фреймворка

SAFe, фреймворк, формализованный Scaled Agile, восходит к 2014 году. Но для Леффингвелла работа началась, когда он впервые столкнулся с Agile-командами в начале 2000-х. Как методолог по разработке программного обеспечения, он был впечатлен результатами Agile-методов в командах разработчиков и сразу же начал изучать, как этот образ мышления можно применить во всей компании. Если Agile-команда может давать результаты, то что может дать слаженная Agile-команда? Как можно использовать Agile-практики для полномасштабных трансформационных проектов в национальных или международных компаниях? Как говорит Леффингвелл: «Я люблю разработку программного обеспечения. Я люблю аджайл. Я просто хочу, чтобы он был большим ».

С тех пор компании признали преимущества SAFe, в том числе более короткие сроки поставки, более высокое качество продукции, более высокую эффективность и более вовлеченных сотрудников. По состоянию на 2021 год более трети организаций по всему миру использовали SAFe, и среди его наиболее важных аспектов — общие процессы и унифицированный язык, которые он предоставляет. Например, если одна команда считает, что спринт длится две недели, а другая — 30 дней, это создает то, что Леффингуэлл называет «проблемой Вавилонской башни». Команде трудно обсуждать, какие функции добавить, если они не могут даже договориться о том, что означает «функция». «Вам [нужны] люди, работающие общим образом, если вы хотите создавать большие решения», — говорит он. «В нашей отрасли нет такого термина, который не был бы перегружен, например, «итерация», «спринт» или «незавершенная работа». Это бесполезно, если вы пытаетесь работать вне командных и региональных границ».

Истории успеха Agile

Привлечь всех в компании к единому способу говорить о работе и выполнять ее — непростая задача, даже когда существует острая потребность в переменах. В устоявшихся корпорациях это может быть сложнее. Леффингуэлл уточняет: «Вы смотрите на крупнейшие компании в мире, которые зарабатывают много денег, преуспевают и конкурируют друг с другом — и они должны меняться. Ну, вопрос для них: зачем им это?» Руководители проектов Toptal, представленные здесь, каждый сталкивался с подобными вопросами во время своих собственных действий по масштабированию, и каждый нашел свой собственный способ работы с Agile-преобразованиями с использованием SAFe.

Демонстрация ценности

Альваро Вильена, менеджер проекта Toptal в Сантьяго, Чили, недавно завершил переход на SAFe для портфолио разработки кросс-бизнес-платформы. «Первой вехой в моем переходе было проведение семинара по потоку создания ценности, — говорит он. Проще говоря, семинар по потоку создания ценности — это стартовая встреча, на которой определяется весь бизнес-процесс от концепции до реализации, а также все этапы, пользователи, системы и болевые точки между ними.

Привлечение представителей всего предприятия на семинар помогло Виллене понять культуру компании и понять, какие препятствия могут возникнуть. «До того, как мы провели семинар, существовала структура, в которой у одного бизнеса была своя команда, у другого бизнеса была своя команда, а у следующего бизнеса была своя команда — все трое не разговаривали друг с другом».

Виллена обнаружил, что, несмотря на то, что у всех команд были схожие проблемы, совместной работы над решениями не было. Например, несмотря на то, что каждая компания в портфолио поставляла продукты, только одна из них разработала систему отслеживания. Не было никаких причин, по которым они все не могли бы использовать его, за исключением того, что никто не поделился знаниями. Как только семинар заставил их заговорить, между командами, предприятиями и владельцами продуктов потекли знания. «Такой разговор был очень, очень мощным для программы. Это была хорошая отправная точка», — говорит Виллена. Когда DevOps, дизайнеры и специалисты по продукту знают, чем занимаются другие команды, они видят, что в компании есть решения, которые они могут использовать. «Они начинают спрашивать: «Как я могу это получить?» И вот здесь вы вступаете и говорите: «Следуйте этому процессу».

«Никто не хочет перемен, пока не узнает почему. Поэтому вы начинаете с вопроса «почему» и даете им лучшее будущее». Дин Леффингуэлл, создатель SAFe

Леффингуэлл знает, что команды иногда сопротивляются. «Никто не хочет перемен, пока не узнает почему», — говорит он Toptal. «Итак, вы начинаете с вопроса «почему» и даете им лучшее будущее». Дать командам представление о том, насколько они могут быть эффективнее, — это мощный инструмент лидерства в области изменений.

Даже когда все полны энтузиазма, вы все равно должны ожидать каменистого старта. Команды, которые привыкли к традиционной разработке Waterfall и большим выпускам, например, могут столкнуться с трудностями при переходе на более итеративный и гибкий процесс разработки, даже если они видят в этом ценность. «Первое добавление программы, которое мы сделали, было своего рода катастрофой для команд», — говорит Виллена. «И мы знали, что это будет; мы сказали клиенту ожидать, что первые три месяца могут быть трудными». Чтобы компенсировать это, он встроил разовую недельную итерацию в конце первого шага программы (PI), в которой команды могли оценить свой прогресс. Он организовал спринт, посвященный исключительно улучшениям процессов и их оценке, которые выходят за рамки обычной проверки и адаптации. Он счел полезным применять Agile-мышление не только к продукту, но и к бизнес-переходу, уделяя время тому, чтобы сделать шаг назад, посмотреть, что сработало, а что нет, и внести соответствующие коррективы.

Создание маленьких побед

Важно быть готовым к неожиданным препятствиям при внедрении SAFe. Несколько лет назад руководитель проекта Toptal Мирослав Аницын из Белграда (Сербия) переводил телекоммуникационную компанию на SAFe. Компания передала всю разработку программного обеспечения на аутсорсинг. Включение удаленной команды не было особенно обременительной задачей — связанные с этим вопросы были в основном логистическими. Но эти усилия создали непредвиденные проблемы при преобразовании самой компании. «Я искал компетенции, которые нам нужны в поезде выпуска», — говорит он. «И все люди, из которых мне приходилось выбирать, были из маркетинга, юристов, продуктов, финансов — у них полностью отсутствовало мышление Agile или даже какой-либо опыт в Agile».

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

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

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

Удовлетворение потребностей ваших команд

Когда Имане Маруан, менеджер проекта Toptal из Парижа, руководила преобразованием крупного многонационального финансового учреждения, она попала в хаотичную среду, в которой отдельные команды выполняли серьезную работу, но не разделяли видение всей компании. «У каждой команды был свой приоритет. Каждый менеджер по продукту хотел, чтобы его продукт был доставлен первым».

Решение SAFe для этой проблемы можно найти в взвешенной модели «Сначала самая короткая работа» (WSJF). WSJF предоставляет стандарт для определения приоритетов работы, поэтому, когда приходит время решать, какой должна быть следующая задача, первый шаг не включает в себя споры о том, как ранжировать важность. В Agile-системе, основанной на потоке, вам не нужно беспокоиться о доставке всего сразу, потому что, как говорит Леффингуэлл, «самое важное — это то, какую работу делать дальше. И на этот вопрос гораздо проще ответить, чем на то, какая работа самая ценная». SAFe предоставляет способ устранения зависимостей между командами — для достижения этого результата необходима упорядоченность задач.

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

«Поскольку это была первая итерация, и команды не привыкли к такой работе, мы решили устроить дополнительную церемонию — еженедельную встречу для обсуждения прогресса в зависимостях», — говорит Маруан. «Один человек из каждой команды пришел, чтобы сообщить о ходе работы». Таким образом, если команда А заявила, что не может выполнить поставленные задачи, команда Б могла узнать об этом заранее и соответственно спланировать свои действия, вместо того чтобы ждать вкладов, которые не будут реализованы в начале их спринта.

Леффингуэлл проповедует осторожность при внесении подобных изменений в SAFe: «SAFe — это система ответственности. … Вы можете адаптировать его, но вы должны быть очень осторожны». Несмотря на то, что структура предназначена для адаптации, изменения, как правило, сохраняются, если их не переоценить. Конфигурация Essential SAFe существует для того, чтобы любые изменения соответствовали базовым критериям.

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

Адаптироваться к будущему

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

Scaled Agile также адаптируется к новым технологиям и меняющимся отраслевым стандартам, внедряя новые инструменты и возможности по мере необходимости. Всем нужно быть начеку и готовиться к неожиданностям. «У нас нет хрустального шара, — говорит Леффингуэлл. «Мы просто быстро бежим, усердно ведем и упорно следуем — и пишем так быстро, как только можем».