Як підійти до переходу від Scrum до SAFe

Масштабування Agile: Від Scrum до SAFe

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

Часто трапляється так, що команди перетворюються на “силоси” – автономні одиниці, які працюють над локальними цілями, не маючи повного уявлення про загальну мету. Саме тут на допомогу приходить Scaled Agile Framework (SAFe).

Що таке SAFe?

Джерело: scaledagileframework.com

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

SAFe базується на кількох ключових цінностях:

Узгодження

• Кожна scrum-команда повинна чітко розуміти загальне бачення, стратегію та кінцеву мету, до якої вона прагне.
• Необхідно узгодити стратегії між командами, щоб усі працювали в одному напрямку.
• Спілкування має відбуватися зрозумілою для всіх мовою.
• Постійно перевіряйте, чи всі команди розуміють цілі та бачення.
• Команди повинні орієнтуватися на клієнта, розуміти його потреби та відповідно коригувати стратегію.

Прозорість

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

Повага до людей

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

Безперервне вдосконалення

• Створіть середовище, де розв’язання проблем мотивує команди.
• Регулярно аналізуйте роботу за минулий тиждень та виявляйте, що можна зробити краще.
• Використовуйте факти як основний аргумент для покращення.
• Забезпечте час і простір для інновацій. Дайте командам можливість експериментувати та пробувати різні підходи.

SAFe забезпечує високий рівень співпраці та комунікації у великих Agile-системах, не замінюючи при цьому індивідуальні Scrum-спринти.

Ключовим елементом SAFe є Agile Release Train (ART) – стабільна команда, що складається з декількох Scrum-команд (зазвичай до 12), яка регулярно надає нові функціональні можливості після кожного спринту. Вони розробляють, поставляють та підтримують одне або кілька рішень у рамках робочого процесу.

Джерело: scaledagileframework.com

Ролі в SAFe

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

#1. Agile-команда

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

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

Agile-команда є важливим учасником сеансів планування Program Increment (PI), де створюються історії та планується їхнє виконання у спринтах. Наприкінці, вони беруть на себе зобов’язання щодо досягнення власних цілей PI.

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

Product Owner (PO) є ще одним ключовим учасником команди. PO є представником замовника, впливаючи на пріоритезацію історій. PO спілкується з іншими PO для узгодження та визначення пріоритетів історій у резерві команд.

#2. Менеджмент продукту

Менеджмент продукту знаходиться над scrum-командами, забезпечуючи узгодженість їхньої роботи. Їхні обов’язки включають:

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

#3. Системний архітектор / Інженерія

Команда інженерів аналізує та розробляє узгоджений контент для незавершених історій. Вони є експертами команди та виконують такі обов’язки:

• Створення та підтримка Architectural Runway, щоб нові функції могли використовувати технологічні механізми.
• Активна участь у плануванні збільшення програми (PI) та демонстрації системи в кінці кожного етапу.
• Співпраця з Agile-командами для впровадження нових засобів підтримки архітектури.
• Допомога Agile-командам у визначенні дизайнерських рішень.
• Створення архітектурної злітної смуги, що визначає технологічні засоби, готові для використання командами.

#4. Власники бізнесу / Зацікавлені сторони

Це зовнішні команди відносно Scrum-команд, але вони відіграють важливу роль у структурі SAFe на кожному етапі виконання.

Перед плануванням PI:

• Надання вхідних даних для уточнення резервів.
• За потреби участь у плануванні до PI.
• Забезпечення розуміння бізнес-цілей та їх узгодження з ключовими зацікавленими сторонами поїзда.

Під час планування PI:

• Надання бізнес-контексту та бачення майбутнього PI.
• Участь у перегляді проекту плану та призначення бізнес-цінності цілям PI команди.
• Участь у управлінському аналізі та допомога у вирішенні проблем.

Після планування PI:

• Активна участь у підтримці узгодженості між бізнесом і розробкою.
• Допомога у визначенні мінімальних життєздатних продуктів (MVP) для Program Epics та керування рішеннями щодо їх реалізації.
• Відвідування демонстрацій системи для огляду прогресу та надання зворотного зв’язку.
• За потреби відвідування заходів Agile Team Sprint Planning і Sprint Retrospective.
• Участь в управлінні випусками, зосереджуючись на масштабі, якості та інших важливих аспектах.

#5. Інженер випуску поїздів (RTE)

RTE організовує роботу людей і команд в рамках ART. Це аналог Scrum Master для всієї програми. Основні обов’язки:

• Керування та оптимізація потоку цінностей через ART.
• Створення та повідомлення річного календаря спринтів і PI.
• Модерація нарад з планування PI.
• Організація команд та допомога їм у створенні короткого викладу їхніх цілей PI.
• Збирання команд для обговорення та вирішення ризиків і залежностей.
• Об’єднання менеджменту продукту, Product Owner та інших зацікавлених сторін для узгодження спільної стратегії.
• Організація семінарів з огляду та адаптації для постійного вдосконалення процесів.
• Оцінка рівня зрілості Agile в командах та визначення дій для подальшого розвитку.

#6. Лідерство

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

• Подавати приклад.
• Приймати мислення зростання.
• Підкреслювати цінності та принципи SAFe.
• Розвивати людей.
• Керувати змінами.
• Створювати психологічну безпеку.

Планування збільшення програми (PI)

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

Керівництво продукту визначає пріоритети функцій, а Agile-команди планують свій потенціал, створюють історії, оцінюють їх та зобов’язуються досягти цілей PI.

Планування PI є ключовим для SAFe. Відмова від нього означає відмову від використання SAFe.

Процес PI

Джерело: scaledagileframework.com

PI Planning починається з вхідних даних. Кожен робочий напрямок збирає свої потреби та ідеї щодо того, що необхідно створити для продуктів. Ці вхідні дані передаються в PI:

• Топ-10 функцій для реалізації.
• ART Backlog з готовими епосами або функціями.
• Бачення Product Owner.

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

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

PI Покрокове керівництво

Планування PI зазвичай розбивається на кілька днів (два-три). Порядок денний може виглядати так:

День 1

• Обговорення бізнес-цілей та загальної стратегії.
• Розміщення всіх функцій на столі та їх пріоритезація.
• Обговорення архітектурних рішень та технічних питань.

День 2

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

День 3

• Коригування планування на основі попереднього дня.
• Розробка остаточних планів та уточнення ризиків.
• Власники бізнесу призначають бізнес-цінність цілям команди.
• Презентація командами фінальних планів.
• Обговорення ризиків на рівні програми.
• Голосування команд за довіру до результатів планування.
• Планування ретроспективи.

Результат PI

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

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

Команди документують усі ризики програми та мають план дій для їх вирішення.

Команди записують ретроспективні ідеї та визначають їх як уроки для майбутніх планувань PI.

Зокрема, очікування від команд полягають у наступному:

• Команди прагнуть досягти цілей з бізнес-цінностями.
• Команди розраховують свою потужність на спринт.
• Команди враховують фактичне навантаження на кожен спринт.
• Історії переносяться до конкретних спринтів кожного робочого потоку.
• Команди голосують за довіру до плану PI та контенту.

Висновок

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

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

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

Перед впровадженням SAFe переконайтеся, що ви опанували Agile. Дайте командам можливість висловити свою чесну думку. Результати можуть вас здивувати.

Далі вивчіть хороші навчальні ресурси для сертифікації Agile.

Чи була ця стаття корисною?

Дякуємо за ваш відгук!