Кому потрібен, а кому ні — Scaled Agile Framework (SAFe)? У чому переваги й недоліки SAFe? Сергій Прохоренко відповідає на ці та інші запитання.
Сергій Прохоренко, провідний фахівець із запровадження SAFe, успішно реалізував проекти з масштабування Agile-розробки продуктів для банків, ІТ, телекомунікаційних, фармацевтичних та інших компаній в Україні та за кордоном.
Сергію, останнім часом стало модно асоціювати компанію з Agile-масштабуванням, зокрема, SAFe — Scaled Agile Framework. Чи всім потрібен SAFe?
— Все залежить від специфіки й розміру самої компанії.
Ідеться не тільки про ІТ. Автоматизації, гнучкості та прискорення процесів потребують банківський сектор, логістичні компанії, телекомунікації, виробничі підприємства. Як каже Дін Лефінгвелл, автор фреймворку SAFe: “В цифрову еру кожен бізнес – це бізнес програмного забезпечення”.
Та перш ніж говорити про масштабування, варто розуміти контекст, у якому опинився сучасний діловий світ.
Маєте на увазі бум цифрових технологій?
— Так. За останню декаду вони заполонили бізнес зі швидкістю ракети Ілона Маска, а пандемія здійняла нову хвилю діджиталізації — через гостру потребу в цифрових рішеннях, необхідність у посиленні кібербезпеки й нові потреби споживачів.
Що це означає для бізнесу?
— За останніми даними офіційних досліджень, таких як State of Agile Report, прийняття гнучких підходів до розробки продуктів світовим бізнесом можна вважати завершеним – більшість компаній, незалежно від розміру чи географії, вже використовують Agile в половині чи більше випадків, і цей відсоток щорічно зростає. Це стосується навіть компаній, чия головна діяльність не пов’язана з ІТ.
Щодо ІТ-компаній, звісно — зростання попиту на розробку продукту відкриває нові можливості. Але є одне “але”. Якщо це команди, які ще не функціонують у парадигмі Agile, то на них очікує серйозна конкуренція з боку тих, хто уже використовує гнучкий підхід. Адже agile-команди створюють більше цінності за коротший період, швидше виводять продукт на ринок і перевіряють продуктові гіпотези з мінімальними витратами, не вкладаючи великі кошти в розробку непотрібної функціональності. Сьогодні це вирішує все.
Тож компанії шукають можливості швидше виводити продукт на ринок, швидше задовольняти нові потреби споживачів, краще захищати дані. Тому керівники бізнесу приходять до нас і запитують: Як інтегрувати ІТ-розробку в нашу компанію, якщо наша галузь — банківська справа (логістика, телекомунікації тощо)? Як керувати одночасно багатьма командами? Як розподіляти бюджет між портфелем діджитал-продуктів? Як запровадити зміни (перехід на Agile) всієї компанії за один період?
Про яку кількість співробітників ідеться? Коли можна використовувати SAFe?
— Коли в компанії 1000 і більше співробітників, вона вже має внутрішню розробку з сотнями задіяних розробників і планує впроваджувати гнучкий підхід, то варто серйозно замислитися про SAFe.
Часто йдеться про компанії з десятками й навіть сотнями тисяч співробітників! Саме для організацій такого масштабу SAFe — ідеальне рішення.
Чому?
— Уявіть на хвилинку: вам потрібно поступово перевести кілька тисяч працівників на новий підхід до розробки продукту… Як таке можливо? Де взяти стільки компетентних фахівців, здатних реалізувати це завдання? Де взяти для цього кошти? Як бачимо, в ручному режимі це практично неможливо. Також навряд чи хтось знайде таку кількість консультантів з різних компаній, узгоджених між собою. Бюджетів на такі затії я теж поки що не бачив. Очевидно, мусить існувати інший шлях.
Ось тут приходить на допомогу SAFe, що уможливлює досить швидкий старт “аджайлізації” і зміни на системному рівні, не руйнуючи поточну операційну діяльність бізнесу.
Всі говорять про “системний рівень”, але що він означає?
— Саме це запитання ми ставимо кожному клієнту, перш ніж розпочати консалтинг. Яке значення компанія вкладає у термін “масштабування”, “впровадження SAFe”? Яких цілей хоче досягти?
Іноді доводиться відмовляти, коли SAFe — не зовсім те, що уявляє клієнт, або коли це не відповідає його запиту. Адже, хоча SAFe і дозволяє, на відміну від інших підходів до масштабування, не руйнувати традиційну управлінську ієрархію, він потребує впровадження “другої операційної системи”, де люди в командах формально підпорядковані лінійному менеджменту, але також організовані в самоврядні команди, що працюють над потоком створення цінності, а не в рамках функціонального підрозділу.
У контексті SAFe перед усім ідеться про рівні: Essensial, Large Solution і Portfolio. Зміни можуть відбуватися на рівні однієї програми, цілої низки пов’язаних програм чи керування портфелем, залежно від потреб компанії, але для сталого ефекту SAFe має поступово розширюватися на всю організацію.
Так просто?
— Це тільки на перший погляд. Тільки для того, щоб з’ясувати значення ключових понять SAFe, доведеться опрацювати посібник Діна Леффінгвелла (Dean Leffingwell) “SAFe Reference Guide” на 800 сторінок, або, як мінімум, пройти декілька тренінгів та опрацювати масив статей в базі знань Scaled Agile. Але справжнє розуміння, які практики підходять у конкретному випадку, приходить тільки з досвідом, що отримується через роботу з різними клієнтами.
Власне, тому експертів, здатних трансформувати компанії, що налічують десятки тисяч співробітників, не так багато. Тому до нас і звертаються по фахову допомогу.
Певна річ, розкрити всі нюанси SAFe під час інтерв’ю неможливо, але хочу наголосити на кількох особливостях SAFe порівняно з іншими підходами.
В чому вони полягають?
— По-перше, SAFe — найпоширеніший підхід у agileджава-розробці. 35% компаній-учасниць опитування 14th State of Agile Report використовують SAFe для масштабування. Це, до речі, на 5% більше, ніж попереднього року, і ми чекаємо, що в 15-му випуску звіту цей відсоток зросте знову. Тобто кількість і якість інструментарію SAFe підтверджена практикою.
Наступна особливість SAFe — диференціація практик, відповідно до масштабу, специфіки та потреб компанії.
На противагу SAFe, інші підходи (наприклад, Large Scale Scrum) зазвичай використовують одну й ту ж практику як для ста співробітників, так і для тисяч. Це, з одного боку, спонукає компанії до декомпозиції команд і зменшення їх взаємозалежності, з іншого – ставить дуже високі вимоги до зрілості продуктового управління, інженерних практик, хмарної інфраструктури тощо.
SAFe якраз відрізняється значно гнучкішими рішеннями. Кожен рівень (базовий, програмний чи керування портфелем) передбачає свій набір практик для управління взаємозалежностями команд. Звісно, це досягається ціною додаткових управлінських витрат на синхронізацію та спільне планування, але дозволяє швидше розпочати масштабування.
Які проблеми чи недоліки має SAFe?
— Є одна риса, яку вважаю і перевагою, і викликом водночас, — це детермінізм SAFe.
Ідеться про докладно прописані практики, що застосовуються для різних ситуацій (best practices). Ці “найкращі практики” справді корисні у багатьох випадках і їх можна застосовувати на різних рівнях. Це такий собі multi-tool.
Проте ми розуміємо, що для деяких компаній “заготовки”, досвід інших або запропоновані “готові рішення” не завжди найкращі. Особливо це стосується організацій, що формують власну навчальну базу. У процесі запровадження SAFe такі компанії мають низку власних, значно дієвіших, best practices.
Ще одним одночасно плюсом і мінусом SAFe є можливість створити “паралельну структуру” (“операційну систему” організації, в термінах SAFe), коли Agile delivery існує паралельно з ієрархією поточної організації. У такому разі існує ризик для SAFe так і залишиться “паралельною структурою” в межах старої парадигми.
В такому разі, це вже проблема не SAFe, а самої компанії. Якщо організація не буде змінюватися як цілісна система, то існує ризик виникнення “організації в організації”.
Це важливо, адже адже кінцева мета бізнесу — не створення секції інноваторів, а перебудова всієї організації — так, щоб вона не просто щось “розробляла”, а стала гнучкою (agile), придатною до нової кон’юнктури на ринку, до постійних змін, до жорсткої конкуренції та лідерства на світовому ринку.
Які в такому разі переваги SAFe?
— SAFe дозволяє швидко запроваджувати зміни. Завдяки SAFe налагодити agile-розробку можливо вже за рік. Звісно, все залежить від розмірів та специфіки кожної компанії, але збереження часу й прискорення переходу на agile — суттєва перевага SAFe.
До того ж, SAFe не ламає поточну організаційну структуру компанії. Це одна з найпринциповіших переваг, особливо на початку впровадження гнучкого підходу.
Наявність готових рішень для різних рівнів. Проблема деяких компаній полягає в тому, що вони намагаються самостійно винайти велосипед, у той час як SAFe уже давно крутить педалі. Стихійні безсистемні спроби перебудовувати великі компанії дорого коштують.
Наступна перевага SAFe — можливість працювати з початківцями завдяки дієвій системі, яка працює на них.
ПІДСУМКИ
В інтерв’ю з Сергієм Прохоренко, експертом із SAFe, ми обговорили такі питання й дійшли таких висновків:
Яким компаніям потрібно запроваджувати масштабований підхід SAFe?
- Підхід SAFe доречний для великих компаній, що налічують тисячі, десятки й навіть сотні тисяч співробітників;
- SAFe також доречний для організацій, що уже розпочали власну ІТ-розробку або планують це зробити, проте досі працюють за класичною проектною моделлю;
- SAFe гарантовано стане в нагоді компаніям, які прагнуть швидше виводити свій продукт на ринок;
- SAFe також допоможе у разі, коли компанія має фіксований бюджет, який треба спрямовувати на найважливіші для бізнесу рішення;
- SAFe економить бюджет Agile-трансформації завдяки перевіреній системі (безсистемні рухи дорого коштують компаніям);
- SAFe також може підійти компаніям, в яких є багато команд, а над одним продуктом працює не менше 50 осіб.
Яким компаніям SAFe не підійде?
- По-перше, SAFe не потрібен організаціям, які з самого початку існування працюють за принципами гнучкого підходу, вже створили власну аджайл-культуру і хочуть зберегти її при масштабуванні.
- Другий тип компаній, яким не потрібен SAFe, це ті, хто хочуть зекономити на реалізації продукту з фіксованою функціональністю. Хоча в такому випадку варто запитати, навіщо взагалі впроваджується Agile-підхід.
- Невеликі організації, незначна кількість команд, для яких накладні витрати на комунікацію і синхронізацію команд будуть неспівмірними з отриманою вигодою.
ДОЛУЧИТИСЯ ДО AGILE.LIVE
Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E)
Підписатися на сторінку у LinkedIn
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live