Agile в крупной компании: фреймворк SAFe и его конфигурации

Нетрудно применять гибкие методологии в одной команде. Но, когда в компании появляется три и более команд, возникает вопрос, как им между собой коммуницировать. В этом случае подходят фреймворки масштабирования Scrum, например, Scrum@Scale, LeSS и Nexus.

А теперь представьте ситуации:

1. Компания готова работать по гибким методологиям, но ее команды используют не Scrum, а Kanban или что-то другое.
2. Некоторые команды в компании не готовы использовать гибкий подход, но масштабироваться всё равно нужно, чтобы создавать большие и сложные решения.

Для таких ситуаций фреймворки масштабирования Scrum не подходят. А вот SAFe предлагает решение.

Поговорим о конфигурациях и особенностях Scaled Agile Framework.

Анатолий Санько помог нам разобраться в SAFe. Он уже более 30 лет в IT. Начинал как разработчик, то есть о том, как создавать софт, знает не понаслышке. В 2000-х годах работал с различными государственными организациями, а позже начал карьеру в ЕПАМе — крупной международной корпорации, входящей в Fortune 1000. Работая с большими проектами, Анатолий часто сталкивался с тем, что практически с нуля нужно создать коммуникативные связи и скоординировать представителей разных команд и организаций. В 2006 году Анатолий начал работать в ЕПАМ, где вплотную занялся управлением продуктовыми командами. В 2007 году он познакомился с Agile и Scrum, а в 2011 году получил свою первую сертификацию CSM и затем PSM. Позже в 2014 году получил первую сертификацию SAFe и в 2018 стал SAFe Program Consultants. С того времени продолжает изучать и практиковать SAFe.

Сейчас Анатолий тренер и консультант по Kanban Method и Scaled Agile Framework. Совместно с партнером развивает компанию Pragmatic Management. SAFe — это фреймворк, который включает в себя большой набор инструментов и вмещает в себя разные методики, поэтому, прежде чем погружаться в него, необходимо разобраться в Scrum и Kanban. Этому и учит Pragmatic Management, а также подробно рассказывает о самом SAFe.

Что такое Scaled Agile Framework

Scaled Agile Framework (SAFe) — это фреймворк, в котором есть набор принципов, практик и методологий, предназначенных для масштабирования Agile-подходов и синхронизации команд. SAFe дает структуру и руководство по внедрению гибких методов разработки и управления сложными решениями в крупных масштабах. Он позволяет координировать работу множества Agile- и не Agile-команд, управлять сложными продуктами, а также интегрировать Lean-Agile подходы на уровне портфеля.

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

SAFe изобрел много нового в сфере управления бизнесом, но еще больше он объединил. Теперь лучшие практики Agile есть в одном месте. Создатели SAFe попытались организовать весь накопленный Agile-опыт в понятную структуру.

Этот фреймворк появился в 2011 году и сейчас активно развивается. На момент выхода статьи существует шестая версия Scaled Agile Framework.

Анатолий подробно рассказал про историю изменений на своем вебинаре. Если вам интересно, как развивался фреймворк и менялись термины, рекомендуем посмотреть.

SAFe framework строит работу вокруг потока доставки ценностей. То есть планируется ценность, которую надо создать, и все ресурсы команд направляются на ее создание. Задача команд — в рамках удобного метода разработки создавать ценности, следуя определенному ритму.

Конфигурации Scaled Agile Framework

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

1. Essential

Включает в себя базовый набор ролей, артефактов и мероприятий. Он предназначен для организаций, в которых от 5 до 12 команд (50–125 человек), где уже выстроены базовые рабочие процессы и есть роли, необходимые для использования Agile-подходов, например, скрам-мастер или владелец продукта.

Ключевые элементы SAFe — ART (Agile Release Train), PI (Planning Interval) и System Demo.

ART — это команда, состоящая из Agile-команд, которые работают для достижения общей цели — создание ценности, сложной киберфизической системы.

Пример. На заводе разные команды производят отдельные элементы велосипеда. Одна делает колеса, вторая — цепи, третья — сиденья и т. д. Работая сообща, они создают новую ценность — целый велосипед. Вместе эти команды образуют ART.

PI (интервал планирования) — временной интервал, в течение которого ART создает ценность. Продолжительность PI обычно составляет от 8 до 12 недель.

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

Другие элементы:

• ART Flow (поток ART) — описывает состояние, когда ART предоставляет клиенту непрерывный поток ценности.
• Team Flow (поток команды) — описывает состояние, в котором Agile-команды обеспечивают непрерывный поток ценности для клиента.
• Continuous Delivery Pipeline (непрерывный конвейер доставки) — описывает рабочие процессы и действия, которые обеспечивают постоянный выпуск ценностей для конечного пользователя.
• PI Planning (PI планирование) — регулярное и крупномасштабное мероприятие по планированию, которое объединяет команды и стейкхолдеров.
• Customer Centricity (ориентация на клиента) — образ мышления, при котором организация предлагает клиентам комплексное решение, основанное на глубоком понимании потребностей пользователей.
• Design Thinking (дизайн-мышление) — процесс разработки, позволяющий создавать желаемый для клиентов продукт, который к тому же стабильно приносит прибыль на протяжении всего своего жизненного цикла.
• Lean UX (бережливый UX) — это подход к созданию продукта, при котором меньше внимания уделяется теоретически идеальному дизайну, а больше — общению с пользователями и созданию удобного для них интерфейса. В конце концов продуктом пользуются именно клиенты.
• Iterations (итерации) — фиксированный временной интервал, за который Agile-команды и ART индивидуально и коллективно создают дополнительные ценности для клиентов. При этом одновременно они работают над созданием ценности всего PI. Рекомендуемая длительность итерации — 2 недели.

• IP Iteration (итерация инноваций и планирования) — специальная итерация, которая проводится в конце каждого PI. Это время для проведения исследований и работы над инновациями, а также планирования и обучения.
• SAFe Scrum — Agile-метод, который используется командами в рамках ART. Он обеспечивает поставку потребительской ценности в сжатые сроки. Команды SAFe Scrum используют итерации, системы Kanban и события Scrum для планирования, выполнения, демонстрации и анализа своей работы.
• SAFe Team Kanban — Agile-метод, который использует ART, чтобы непрерывно предоставлять ценности. Команды в своей ежедневной работе применяют процесс, основанный на потоке рабочих задач, и действуют в рамках итераций.  
• Built-In Quality (встроенное качество) — практики, которые обеспечивают качество каждого инкремента и проделанной работы на каждом этапе разработки.
• SAFe DevOps — это образ мышления, культура и набор технических практик, которые поддерживают интеграцию, автоматизацию и сотрудничество, необходимые для эффективной разработки и эксплуатации решений.

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

2. Large Solution

Конфигурации Large Solution — следующий уровень после Essential. То есть в нее входят все элементы Essential-конфигурации, а также добавляются новые. Эта конфигурация появилась в SAFe только в версии LSE/SAFe 3.5.

В какой момент компании нужно переходить на Large Solution? Для этого может быть два триггера:

1. Появилось много Agile-команд, которые формируют несколько ART. Вернемся к примеру с заводом, производящим велосипеды. Если компания захочет изменить направление бизнеса и выйти на новый более крупный рынок, например китайский, ей нужно будет очень сильно нарастить производство. То есть компания не будет работать в рамках 5–12 команд. Речь будет идти о тысячах сотрудников. Маленькая компания превратится в Enterprise (предприятие). В рамках Essential управлять такими ресурсами невозможно.
2. Появление внешних поставщиков, которые не готовы работать по Agile. Увеличить темпы производства можно за счет внешних помощников — новых поставщиков, других заводов, которые будут производить комплектующие и т. д. В этом случае возникает зависимость от производительности поставщиков. Конфигурация Large Solution учитывает работу с ними: в схеме появляется элемент Supplier (поставщики). Это внутренняя или внешняя организация, которая разрабатывает и поставляет компоненты для продукта или услуги для ART, что помогает увеличивать поток создания ценности. Supplier не обязаны работать по Agile. SAFe понимает, что вендорам это может быть неудобно. Чтобы выстроить долгосрочные деловые отношения и вовлечь их в разработку, Large Solution принимает любой рабочий процесс поставщиков и предлагает варианты взаимодействия.

Элементы, которые помогают взаимодействовать с Supplier и несколькими ART:

• Solution Train (поезд решений) — организационная конструкция, которая используется для создания крупных продуктов и решений, требующих координации нескольких ART и поставщиков.
• Pre-Plan (предварительное планирование) — мероприятие, на котором компания и поставщики согласовывают объем работы и скорость поставки ценностей. На основе этих договоренностей каждый ART может провести PI Planning.
• Solution Demo (демонстрация решения) — комплексное представление вклада различных ART и поставщиков в разработку ценности для клиента. Это время провести анализ работы. Благодаря этому все получают объективную оценку и обратную связь.

3. Portfolio

Конфигурация Portfolio тоже основывается на Essential. Однако она ориентирована на организации, которые управляют несколькими бизнесами и продуктами. Она помогает принимать эффективные инвестиционные решения, учитывая стратегические цели и рыночные условия.

Например, у нас есть два бизнеса, которые работают по Essential. Один делает велосипеды, другой — резиновые галоши. С виду бизнесы не связаны, но принадлежат одному владельцу. Объединить разные бизнесы в один портфель и управлять ими совместно можно с помощью денег. То есть всё, что заработали все бизнесы, входящие в портфель, складывается в одну корзину и распределяется в зависимости от требований рынка. Здесь можно вспомнить Матрицу BCG, где есть дойные коровы и звезды, в которые нужно много инвестировать. То есть на уровне Portfolio идет разговор не только про процессы, но и про деньги и их грамотное инвестирование.

4. Full

Это полная конфигурация, где есть всё многообразие элементов. Включает в себя особенности Essential, Large Solution и Portfolio.

Подытожим:

• Начинать внедрение SAFe нужно всегда с конфигурации Essential.
• Если у вас не более 12 команд, которые совместно работают над одним крупным продуктом, вам подойдет конфигурация Essential.
• Если у вас более 12 команд или появляются внешние поставщики, необходимо переходить на Large Solution, чтобы выстраивать с ними коммуникацию.
• Как только вы хотите объединить производство нескольких разных продуктов, переходите на Portfolio.
• Full для тех, кто обладает большим количеством бизнесов и поставщиков.

Отличия от других фреймворков масштабирования

Сравним SAFe с LeSS, Nexus и Scrum@Scale.

1. LeSS, Nexus и Scrum@Scale масштабируют Scrum. То есть, чтобы использовать один из перечисленных фреймворков, нужно, чтобы ваши команды работали только по Scrum. SAFe не требует этого от команд. Вы можете выбрать для себя Kanban, Scrumban или практики XP-программирования. Если руководство не требует использования того или иного подхода к разработке, то команда вольна выбрать ту гибкую методологию, которая для нее удобна. При конфигурации Large Solution есть возможность интегрировать команды, которые не просто не готовы работать по Scrum, они вообще не хотят работать по Lean-Agile и любым другим гибким методологиям. Достаточно зафиксировать PI и сроки, когда команды должны предоставить результат.
2. Конфигурация Portfolio позволяет объединять не только разные команды, но и разные продукты и бизнесы. Nexus, LeSS и даже LeSS Huge работают только с одним продуктом. Они не дают ответа, как подружить несколько бизнесов одного владельца.
3. В SAFe не может существовать одна команда. Даже в самой минимальной конфигурации Essential есть ART — команда из команд.
4. SAFe внедряется сверху вниз. То есть владельцы бизнеса видят, что компания растет и она уже не может производить продукт старым методом, например Scrum. Как только топ-менеджеры принимают решение внедрять SAFe, тогда строится план по переходу на новые рельсы. На официальном сайте фреймворка есть рекомендация, как внедрять SAFe — SAFe Implementation Roadmap.

Недостатки SAFe

• Не устраняет зависимости. Scaled Agile Framework, как и Nexus, признает наличие зависимостей между командами. Однако он активно выявляет и минимизирует зависимости, что помогает организациям справляться с этим недостатком.
• Не соответствует всем заповедям Agile-манифеста. SAFe — это микс разных методологий и он не обязан полностью соответствовать Agile. Он вобрал в себя лучшие практики из гибких методологий и адаптировал их под требования большого бизнеса. В целом хочется отметить, что не нужно превращать гибкие методологии в религию, а пункты Agile-манифеста принимать за догму. Главное правило Agile — будьте гибкими. Когда вы начинаете слепо следовать всем требованиям, то теряете гибкость.

Канбан тоже не гарантирует полное исполнение всех правил Agile, но в сущности он ему не противоречит.

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

• SAFe придумывает новые термины, когда есть уже устоявшиеся. Например, в шестой версии можно встретить давно известный Lead Time, который в SAFe называется Flow Time.

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

• Часто меняются термины. Привычный элемент в SAFe в новой версии может переименоваться, при этом его суть не меняется. Это приводит к путаницам и усложняет процесс обучения. Например, до пятой версии SAFe PI расшифровывался как Program Increment, но позже он превратился в Planning Interval. Также в 2023 году из фреймворка полностью убрали термин «Program».

Где получить необходимые сведения о SAFe

Все схемы и описания каждого элемента можно найти на официальном сайте SAFe. Смело кликайте на все элементы инфографики и подробно читайте о них и возможностях организации работы.

А также изучайте фреймворк и другие методы современного менеджмента вместе с Анатолием Санько и его коллегами в компании Pragmatic Management.