Як спростити SAFe (Scaled Agile Framework)?

Вже кілька років Scaled Agile Framework (SAFe) вважається найбільш використовуваним фахівцями фреймворком, і його популярність стрімко зростає. Це підтверджують дослідження State of Agile: в період між 2015-м та 2022-м показник використання SAFe збільшився на 16%.

Чому ж SAFe привертає стільки уваги професіоналів? Для того, щоб з цим розібратися, спершу визначимо поняття у класичному розумінні.

SAFe – це збір найкращих наявних практик, інтегрованих принципів та компетенцій з різних напрямків з питань організації робочих процесів та програмного забезпечення під час масштабування.

Метою SAFe є досягнення гнучкості у бізнесі шляхом впровадження та інтеграції сильних сторін:

• Lean (а саме: ощадного виробництва);
• Agile (а саме: гнучкості підходів та методології у розробленні);
• DevOps (а саме: культури загалом).

Якщо ви думаєте, що SAFe – це страшно чи складно, ми розкажемо, як спростити SAFe-підхід та про концепції, на які слід зважати у процесі його впровадження в вашій компанії.

В матеріалі ми розглянемо:

• Які основні характеристики SAFe.
• Як ідея PDCA-циклу працює в фреймворку.
• За допомогою яких способів можна спростити SAFe:
  • на рівні команди;
  • на рівні програми;
  • на рівні портфоліо.

Основні конфігурації SAFe

З одного боку, SAFe, як і будь-яка база знань, характеризується впорядкованістю цих знань за певними рівнями – Team (команда), Program (програма), Portfolio (портфоліо).

З іншого боку – цей фреймворк нагадує конструктор, де ви можете обрати ту конфігурацію, яка підходить для вашої компанії найбільше, з огляду на масштаби застосування. На сьогодні таких конфігурацій всього чотири:

1. Full (повна конфігурація).
2. Large Solution (конфігурація великого рішення).
3. Portfolio (конфігурація портфоліо).
4. Essential (основна конфігурація).

Essential Configuration – базова конфігурація, яка може охопити від 50 людей. Ми ж радимо звернути увагу на SAFe Essential, навіть якщо у вас чотири та більше команди, тобто від 30-35 людей. Якщо ж менше, то Essential буде недоцільним, адже це виходить процес заради процесу та невигідно з економічної точки зору.

Цінність SAFe ми вбачаємо в тому, що він здатний працювати з різною кількістю людей, залучених до проєктів – від 30 до 20 тисяч. І навіть ці цифри орієнтовні, тож у будь-якому разі розглядати SAFe як основний фреймворк варто. Головне – обрати потрібну конфігурацію.

Дійсно, стандартна схема SAFe 5.1 може здаватися достатньо об’ємною, комплексною та важкою, тобто такою, яку хочеться спростити. Проте вона є повністю інтерактивною: на кожен її елемент можна клікнути та ознайомитися зі статтями, що розкривають певні питання, пов’язані з цим елементом.

Звертаємо увагу, що з весни 2023 року вийшла версія SAFe 6.0 з просунутими практиками та оновленою термінологією. Попри це, версія 5.1 залишається актуальною для тих, хто вже успішно працює за нею і наразі не планує оперативно переходити на оновлення.

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

PDCA-цикл як основа SAFe

Спрощенню конфігурацій SAFe чудово сприяє ідея PDCA-циклу, що лежить в основі SAFe, як і Scrum:

• Plan – планування;
• Do – впровадження;
• Check – перевірка;
• Adjust – адаптація.

Дотримуючись циклу, ви зможете максимально гнучко й швидко створювати, впроваджувати плани, перевіряти на відповідність бажаному та адаптувати. В умовах динамічних змін на ринку та розширення диджитал-складової будь-якого бізнесу реагування на ці зміни є необхідним для конкурентоспроможності та успіху компанії.

Застосування швидких циклів навчання покращує його ефективність, зменшуючи час між дією та ефектом та мінімізує витрати на прийняття ризику за допомогою оперативного скорочення невдалих шляхів. До того ж завдяки PDCA воно полегшується малими розмірами партій – чим коротші цикли, тим менше часу займає навчання.

Застосування швидких циклів на різних рівнях

Ідея PDCA-циклу працює і в підходах SAFe.

На Team level із класичним стандартним Scrum, яким все ж таки користується більшість команд, зокрема IT, цикл працює так:
планування та виконання спринту (від 3 до 4 тижнів);
моніторинг на щоденних стендапах (Daily Stand Up) з усуненням перешкод;

• перевірка;
• підсумовування;
• проведення рев’ю спринту;
• організація системної демонстрації – System Demo;
• проведення ретроспективи, тобто надання можливості командам створити план покращень для наступного спринту;
• процес адаптації, який реалізується з точки зору продукту (що зміниться за результатами перевірки) і точки зору процесу (що ми можемо покращити).

Не забувайте, що такі цикли необхідно проводити регулярно, щоб намагатися якнайточніше потрапити в потреби ринку.

Поняття «‎Program level» вводиться тоді, коли команда вже не одна, а, припустімо, 4-5 як мінімум. Ця так звана віртуальна команда команд називатиметься Agile Release Train (ART). У цьому випадку PDCA-цикл такий самий, як і на Team level, однак тривалість спринту слід збільшити (з 8 до 12 тижнів). Рекомендуємо вибрати двомісячний термін, якщо вашій компанії притаманна часта зміна пріоритетів, а бізнесу тяжко витримати квартал, не змінюючи їх. Якщо ж ваша компанія більш традиційна, яка не один рік на ринку та має сильне фінансове планування, доречнішим буде квартальне планування.

На Portfolio level PDCA-цикл відбувається аналогічно – ми щось плануємо, виконуємо, працюємо в режимі експерименту, впроваджуємо цикл Lean Startup (ощадного стартапу), але на рівні ідеї, ініціативи та працюючи з концептами MVP (мінімально життєздатних продуктів).

Portfolio level може відповісти на запитання «що ми робимо?», «куди інвестуємо наші гроші?», тоді як рівні Team та Program – на запитання «як ми це робимо?», «як ми організовуємо нашу роботу?».

Тож бачимо, що на всіх трьох рівнях стандартної схеми варіанту SAFe Portfolio успішно вмонтований PDCA-цикл.

Рівні SAFe: способи їх спрощення

Team level (Рівень команди)

Часто команди думають, що різні комунікації у роботі за SAFe забирають багато часу, який вони могли б витратити на виконання кількох задач. Однак, на думку С-level, який відповідає за стратегію компанії, кількість виконаних задач є менш важливою, ніж цінність, яку ви принесете. Крім того, SAFe не пропонує багато змін у разі, якщо команда вже працює за гнучким фреймворком типу Scrum, Kanban, XP або FDD.

Особливості змін на рівні команди у роботі за SAFe:

1. Потрібно синхронізувати каденції, щоб усі команди починали спринти в один момент зі спільними точками для синхронізації. Це дозволить спростити координацію залежностей між командами, створити ефективну комунікацію під час планування, забезпечити оперативність домовленостей з приводу вирішення залежностей та пропрацьовування ризиків.
2. Залучити команди до безпосередньої фізичної участі у спільних івентах, церемоніях, котрі стануть на Program level.

Додатковими спільними церемоніями можуть бути:

• Program Increment (PI) Planning (участь команди у плануванні збільшення програми), що покриває кілька рівнів комунікацій:
  • рівень «зверху вниз»: C-level ставить високорівневі цілі → Product-команда та архітектори аналізують їх та обговорюють певні особливості → команди вирішують, чи вкладуться у спринт, за що візьмуть командну відповідальність;
  • рівень «знизу вверх»: команди → Product-команда та архітектори → C-level.
• System Demo, що відбувається в усіх командах після кожного спринту. Щоб вимірювання прогресу було більш наочним, рекомендуємо вам проводити демонстрацію уже зінтегрованих разом частин системи, а не окремих елементів. Це виключить ситуації, коли система у командному середовищі працює, а все разом – ні.
• Inspect and Adapt workshop (підбиття підсумків) з фінальною демонстрацією, ретроспективою, метриками.

Відповідно, на Team level революційних змін не відбувається, проте від цього найнижчого рівня залежить ефективність інших.

Program level (Рівень програми)

Компанія, яка доросла до певних масштабів, але не використовує якийсь конкретний фреймворк, а, наприклад обходиться зустрічами Scrum of Scrums, у будь-якому разі не здатна забезпечити синхронізацію процесів. У найкращому випадку врятувати ситуацію може особиста проактивність Project Manager (менеджер проєктів), який володітиме навичками рівня senior. Він зможе вдало контролювати та вирішувати залежності між командами й кризові ситуації.

Проте такі кейси не відрізняються цілісністю, без чого не працює система і, відповідно, зупиняються процеси, що підриває ту командну відповідальність, встановлену на попередньому рівні – відбувається пошук винних і перекладання провини на інших.

На Program level спрощення спостерігаємо у PDCA-циклі з виділенням обов’язкових додаткових ролей:

• Product Manager (продакт-менеджер);
• Release Train Engineer, або RTE (машиніст потяга SAFe);
• System Architect (системний архітектор).

Ваші команди залишаються незмінними та, вірогідно, за умови органічного розвитку компанії ці ролі вже кимось виконуються, просто роль (посада) звучить інакше. Наприклад, у вас вже є людина, яка ставить задачі десяти командам, що створилися, та управляє їх беклогами; отже, вона закриває роль Product Manager. У цьому разі варто зафіксувати, хто і які ролі закриває, та визначити, кого не вистачає. Зазвичай на фінальній стадії такої ревізії у вас відкриється декілька вакансій.

Крім цього, спростити SAFe на цьому рівні можна через церемонії:

1. PI Planning. Ідеальною формою проведення буде збір людей в одному конференц-румі чи у режимі онлайн у віртуальній кімнаті платформи ZOOM. Робота за планом принципово важлива, бо без цього ви не працюєте за SAFe. Ми пропонуємо такий варіант PI Planning на 2 дні.

2. Program board (дошка залежності). Здебільшого, якщо у вас багато команд, то ви робите складний продукт, часто з великою BI-складовою. Тоді стає необхідним відстеження роботи кожної команди на конкретному часовому проміжку, наприклад, що робить п’ята команда на першому тижні або що відбудеться на другому тижні (виставка, вихід на ринок тощо).

З цією метою радимо використовувати Program board – таблицю із зазначеними подіями, епіками, часом та виконавцями, деякі з яких можуть поєднуватись «‎нитками» (лініями), тобто бути залежними. Причому епік, який не поєднаний «‎нитками», означає, що його можна завершити без участі інших команд.

Важливо, щоб інструменти відстеження не обтяжували процес, тому їхній добір залежить від чинних умов та особливостей ваших задач у компанії.

3. System Demo, що проводиться в кінці кожного спринту і становить собою 10-15-хвилинну презентацію команди проробленої роботи. Загалом System Demo не перевищує за часом двох годин. Таким чином відбувається надання зворотного зв’язку кожній команді та шерінг на усі ваші команди.

4. Scrum of Scrums (SoS) є церемонією, що має на меті об’єднати команди, на яких чекає спільна робота. SoS відбувається в процесі спринтів і триває максимум до години. Доречними будуть такі питання для обговорення: Чого досягла ваша команда з часу останньої зустрічі? Що ваша команда зробить від сьогодні до наступної зустрічі? Чи є проблеми, непорозуміння у команді?

5. Inspect and Adapt workshop – це важливий захід наприкінці кожного етапу програми, де демонструється та оцінюється поточний стан рішення, фінальне System Demo, метрики, проводиться ретроспектива по PI. Фінально команди обмірковують і виявляють невиконані питання покращення за допомогою структурованого семінару з розв’язання проблем.

6. За необхідності можна використовувати ще одну техніку SAFe – Problem Solving workshop (воркшоп з розв’язання проблем), що є подією в рамках Inspect and Adapt workshop та призначена для пропрацювання загальних болючих тем для компанії. Ви вносите ці теми на обговорення, а люди в режимі спільного розгляду питання шукають способи усунення хронічних проблем компанії.

Без названих ключових церемоній неможливо буде впровадити SAFe як такий. Якщо ваш бізнес стрімко розвивається, але ви не розумієте, яким чином тепер нормалізувати роботу, саме церемонії дозволять вам її структурувати, упорядкувати та відновити організацію в компанії.

Portfolio level (Рівень портфоліо)

Portfolio level є найвищим рівнем SAFe і може дати відповіді з питань ваших дій здебільшого з боку бюджету й ініціатив.

Цей рівень напряму впливає на єдність стратегії компанії та конкретних кроків до її максимального досягнення. Тому, якщо ви помічаєте розрив між тим, що С-level хоче, що вважає важливим, і беклогами конкретної команди, це свідчить про або відсутність Program level, або недостатню добудову Portfolio level.

На Portfolio level для спрощення SAFe радимо дотримуватись таких рекомендацій:

1. Команда Lean portfolio management (LPM), тобто ощадливого управління портфоліо, є найголовнішою командою та включає тих людей, які прийматимуть важливі рішення та нестимуть відповідальність за стратегію і фінансування інвестицій. Не радимо вам брати в команду більш як 5-7 людей, адже управління великими групами здійснюватиметься складніше, а прийняття рішень розтягуватиметься в часі.
Кандидатами в LPM можуть бути представники бізнесу, наприклад:

• Head of Finance (керівник фінансового відділу), Head of Sales (керівник відділу продажів), Head Business Development (керівник відділу бізнес-розвитку). Вибір кандидатів насамперед залежить від специфіки вашого продукту чи проєкту, від того, хто саме є генератором суттєвих ідей, хто надає вхідну інформацію про те, куди рухається компанія.
• Якщо масштаби компанії невеликі (від 100 до 300 людей), до команди може входити Chief Executive Officer (CEO), тобто головний виконавчий директор, за умови успішного поєднання обов’язків директора та учасника команди LPM.
• Chief Technical Officer (CTO), тобто технічний директор, повинен бути сталим учасником у команді. В IT-компаніях технічна складова дуже вагома, тому без розуміння технологій та надання технічного зворотного зв’язку від СТО прийняття бізнес-рішень може бути проблемним.
• Chief Financial Officer (CFO чи FD), тобто фінансовий директор, буде корисним в команді, адже він відповідатиме за роботу з бюджетами та беклогами – визначення стратегічних тем, контроль великих запущених ініціатив у компанії тощо.

2. LPM Metrics (метрики / показники LPM), по суті, є статистикою на основі певних зібраних показників. Ефективна стратегія на Portfolio level полягає в умінні команд домовлятися про способи вимірювання успіху. Добір метрик залежатиме від вашого продукту, основної чи найближчої цілі, об’єкта концентрації уваги тощо. Якщо вам важко зорієнтуватись у процесі вибору показників за критерієм доцільності, ми надаємо приблизний перелік метрик, які ви можете використати для старту.

3. Робота з бюджетами на Portfolio level проходить усі етапи, а саме: розподіл, коригування і перепризначення коштів, а підходи до бюджетування принципово відрізняються від традиційних.

До прикладу, уявімо, що ви отримали від головного офісу бюджет на певний проєкт, і ваша основна задача полягає в освоєнні цього бюджету. Однак у вас може виникнути безліч проблем, пов’язаних із тим, що проєкт уже не актуальний або його цілі – не релевантні. Тоді навіть спроби опанування бюджету не принесуть ніякої користі.

Якщо ж ви працюєте за SAFe, то опинитися у такій ситуації буде вкрай важко. Адже бюджети за цим фреймворком виділяються не на конкретний епік чи ініціативу, а загалом на якийсь напрямок бізнесу, де умовно відбувається боротьба ідей за гроші. Тобто ви займаєтесь розробкою ініціативи доти, доки в ній є сенс, а як тільки вона себе вичерпала, припиняєте її розробку та ініціюєте запуск нової. І найцікавіше те, що питання бюджету в такому разі у вас закрито, оскільки завершення цієї ініціативи не впливає на ще інші активні проєкти у конкретному напрямку бізнесу.

4. Під егідою команди LPM за SAFe використовується Portfolio Kanban як життєвий цикл вашої ідеї, будь-якої ініціативи, яка зароджується в компанії. Kanban має бути вибудований на рівні процесу, адже він поетапно описує всі стадії процесу, через які проходить ініціатива від створення до закінчення.

Ба більше, ваш девелопер, Team level та Program level починають працювати лише з рівня Portfolio Backlog (беклог портфоліо), а до цього, на рівнях Funnel (воронка), Reviewing (рецензування) та Analyzing (аналіз), відбувається масштабна аналітична робота. Зазвичай її виконує Product-команда, яка може допомогти визначитися з тим, чи треба інвестувати в цю ідею, чи є в цьому економічний сенс.

Отож, це ключові моменти, на які варто звернути увагу, якщо хочете спростити SAFe на Portfolio level.

Підсумуємо

Перевага застосовування SAFe, у порівнянні з іншими гнучкими підходами, полягає у використанні однієї методології управління – від Team level до Program level та Portfolio level на основі PDCA-циклу.

Якщо ви тільки починаєте працювати за цим фреймворком, не намагайтесь застосувати все і відразу. Скористайтесь нашими порадами щодо способів спрощення на кожному рівні:

• Team: синхронізуйте каденції, залучіть команди до безпосередньої участі у спільних івентах та церемоніях.
• Program: виділіть обов’язкові додаткові ролі та церемонії.
• Portfolio: сформуйте команду LPM, виміряйте її показники, зважайте на специфіку бюджетування, використовуйте Portfolio Kanban.

Рекомендуємо запускати процес спрощення SAFe, починаючи з визначення актуальної проблеми компанії, а на цій основі додавати відповідний рівень. Тобто якщо у вас 5-7 команд просто потребують синхронізації, ви можете, залишивши за основу ваші Scrum-команди, додати Program level у спрощеному вигляді з PI Planning, проведенням, адаптацією, відповідними ролями. Якщо відсутній розрив між стратегією та задачами розробника, можна Portfolio level і не надбудовувати.

У процесі спрощення SAFe самостійно робіть це тільки тоді, коли ви чітко розумієте свої цілі та призначення кожного елемента системи.

Хочете глибше зануритися у тему SAFe, його спрощення та побудови процесу роботи за ним? Запрошуємо вас на сертифікаційний курс Leading SAFe 6.0 Online.