Безпечний шлях. Що таке SAFe і як його впровадити

Всім привіт, я — Віталій Бараш, Project Manager і Agilist до мозку кісток у Luxoft. А конкретніше — в Excelian Financial Services.

За роки в ролі менеджера я побачив багато різних шлюпок, капітанів, матросів, веселий. Роль менеджера — це досягти максимуму при заданих обмеженнях. Максимуму в чому? В очікуваннях всіх стейкхолдерів: команди сервісної компанії, команди замовника, самого замовника, кінцевого користувача, безпосереднього керівництва і т. д. Обмеження — зарплати, домени, технологічний стек, ринок праці в локаціях, міжкультурні особливості, регулятори та інше. Хочеться, щоб все це запрацювало разом, як одне ціле. Для цього існує багато підходів, технік, методологій, фреймворків, whatever.

Сьогодні ми підемо безпечним шляхом — шляхом SAFe. Я спробую на пальцях пояснити фундамент, на якому будується цей фреймворк. Перед початком додам, що мене тішить інтерес до цієї теми української аудиторії. Трохи раніше мій тренер по SAFe Олена Любчак вже встигла опублікувати витяги по SAFe Essentials . Ця стаття буде про інше — про те, на чому все це тримається, і як ми почали впровадження цього фреймворку у себе.

Ефективність і використання

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

Безкоштовно і вичерпна вікі

За посиланням ви можете знайти все необхідне для роботи з SAFe: блоги, форуми, статті, енциклопедії, словника, кейси і т. д. Саме там слід шукати відповідь, як краще провести трансформацію бізнесу, продукту, проекту. Незважаючи на можливий скепсис, для вас немає кращого інструменту і союзника, ніж наявність такого безкоштовного освітнього порталу або вікі для ваших колег. Хороша база, щоб бути on the same page — розуміння того, що ми робимо, і що «same» означає одне і теж для вас і колег.

Кейси успішних трансформацій в різних доменах

ОК, вікі, енциклопедія і натхнення — це добре. А це взагалі хоча б один раз заробило? Так, багато великих організацій вже працюють, застосовуючи SAFe, а деякі — в процесі трансформації. Безліч кейсів доступний для ознайомлення на все тому ж порталі. Там ви побачите таких лідерів, як Nordea, Capital One, Deutsche Bank, Standard Bank, Westpac у фінансовому світі, а також Sony, Intel, Dell, Motorola, McAfee та інших з різних доменів.

Roadmap з проведення трансформації

Як би нам не хотілося, але трансформація сама по собі не відбудеться. Потрібно з чогось починати.

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

Навчання та сертифікати

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

І так, згідно з 12-го щорічного звіту від Version One, SAFe є найбільш популярним фреймворком для масштабування. +100 до впевненості ?

Конфігурації

«Чиста» реалізація по книзі зустрічається дуже рідко, і на практиці ми бачимо якісь комбінації з Scrum + Kanban (Scrumban), де-то RUP + ATDD, або навіть Crystal Clear + SAFe та інші. Тим не менш SAFe спробував максимально продумати «унікальності», з якими можуть зіткнутися агенти трансформації. Як результат, SAFe декларує наведені нижче конфігурації.

Essential

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

Масштаб: підходить організаціям, які працюють над одним потоком бізнес-цінностей і втягують у роботу близько 150 осіб.

Іншими словами: організації, які працюють виключно над одним продуктом середньої або високої складності.

Portfolio

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

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

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

Large Solution

Ця конфігурація призначена для розробки великих і складних рішень, які розробляються кількома ART (Agile Release Train) з можливим залученням вендорів, але при цьому немає необхідності в управлінні портфелем.

Масштаб: підходить організаціям, які працюють над одним комплексним і складним рішенням і роблять ставку тільки на це рішення. Втягують у процес понад 150 осіб. Наприклад, створення нового зорельоту однозначно вимагає розробки software (SW), hardware (HW), firmware (FW) та інших речей, при тому, що над кожною може працювати до або понад 150 осіб одночасно.

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

Full

Це найбільш вичерпна конфігурація фреймворка. Призначена для підтримки організацій, які розробляють кілька комплексних і складних рішень одночасно, де залучаються всі рівні SAFe: team, program, large solution і portfolio. В такого роду організаціях можуть бути реалізованими кілька різних конфігурацій SAFe.

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

Іншими словами: Мета організації — кілька комплексних і складних рішень. Повертається необхідність у розподілі грошей та вирішенні інших важливих питань за допомогою рівня портфеля.

Разом

У нас є 4 конфігурації для підтримки будь-якого роду організацій: від одного продукту середньої-високої складності до декількох комплексних і складних рішень одночасно. Сам же SAFe при цьому досить великий і ґрунтується на принципах Lean і Agile. А що ж лежить в основі SAFe?

Фундамент SAFe

Давайте почнемо з базових речей, а саме з цінностей і принципів.

Цінності

Впровадити Scrum на рівні команд — завдання деколи не з простих. Можете уявити, що таке провести трансформацію організації?

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

Alignment

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

Звучить знайомо? Я не раз спостерігав брак комунікації — в одній команді, між декількома командами, організаціями, постачальниками і третіми сторонами. І якщо ми все ж плануємо проводити трансформацію, необхідно переконатися, що комунікацією легко керувати, і вона досить швидка і проста, інакше ми втратимо багато грошей. 1 день 150 висококваліфікованих професіоналів робили неправильні речі. Стало сумно вже від самої фрази ?

Build-in Quality

SAFe стверджує: «You can't scale crappy code». Я додам — «You can't scale crappy agility». Ті ж 150 висококваліфікованих професіоналів витратили на сумнівну архітектуру 2 місяці. Результат той же, тільки масштаб більше. В кінцевому підсумку ми просто позбудемося напрацювань і почнемо з початку. Ми не можемо дозволити собі сумнівний дизайн і архітектуру, коли через кілька місяців ми побачимо, що наше рішення вже непідтримувану. Минув час, гроші витрачені, продукт... продукт, можливо, закритий.

Крім того, що ми не хочемо, щоб це сталося, нам ще б і зберегти необхідні гнучкість і маневреність при розробці, яка веде до технічного боргу. Основна мета цієї цінності — це зберегти варіаційність. Це дозволить швидко розширювати архітектуру, щоб можна було задовольнити бізнес-потреби. Потрібно продовжувати поліпшуватися» за допомогою реалізації PoC, підтримувати рівень технологічної інноваційності, навчитися передбачати розвиток продукту і формувати для цього фундамент як можна раніше. Не може бути ніякої неточності та невизначеності в цінності built-in-quality для великих рішень. Це просто must have.

Transparency

Ніхто не може пофіксити таємницю. Та й ми не читаємо думки. Розробка рішень складна, іноді навіть болюча. На жаль, щоб таки досягти успіху, ми не можемо робити все самостійно (так-так, хочеш щось зробити, зроби це сам). Як наслідок, ми маємо в значній мірі покластися на колег, відділи, підрозділи і при цьому працювати як одне ціле з передбачуваним результатом. Механізм не буде працювати без довіри, де прозорість — це всього лише важіль включення довіри. Кожен знає, що він робить, чому ми це робимо зараз, коли чекати кінцевого результату, що ми будемо робити далі, яка у нас пропускна здатність і багато іншого. Процеси мають бути прозорими для кожної з команд: розробка, операційка, бізнес, акаунт, відділ продажів та інших.

Program execution

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

Принципи SAFe

Перейдемо до «безпечних» принципам.

Завжди тримати в голові економічну складову (Take an economic view).

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

Деливерить якомога раніше і частіше (Deliver Early and Often). Досить очевидна (привіт, айджалисты!) річ для нас. «Водоспади» проти гнучких підходів — просто залишу картинку.

Розуміти економічні компромісні параметри (Understand Economic Trade-off parameters). Виділю 5 таких: час циклу (і ось той же Kanban зі своїм lead time), костовая складова продукту, витрати на розробку, цінність і, звичайно ж, ризики. Успіх або провал рішень і буде визначатися ефективністю управління цими параметрами.

Системне мислення (Apply system thinking).

«Моя хата скраю — нічого не знаю» ? На жаль, люди прагнуть ізолювати себе від усього навколо, щоб спростити існування. Програмісти, ООП, абстракції.... Беремо найважливіше і про решту не думаємо. При створенні великих рішень це призведе до того, що ми не зможемо заинтегрироваться в кінці і отримаємо напівживе рішення. Тому використовуємо цей принцип — фіксуємо картину в цілому, а не частково. Залучаємо всі касти при планерці. Малюємо залежності на Program Board.

Припускаємо варіаційність, зберігаємо опції (Assume variability, preserve options).

Цей принцип про наявність плану Б. Завжди і в будь-якій ситуації. І чим більше таких планів ми маємо про запас, тим вище наші шанси на успіх. Ми дуже часто обмежуємося спочатку тільки одним цільовим рішенням і на більш пізніх фазах залякуємо команду продукту фразами: «Потрібно переписати всі програми», «Це потім в фазі тестування просидить вічність» та іншими. З іншого ж боку, зайва варіаційність дуже ускладнює і так досить складний продукт і може призвести до негативних ефектів. Тому тримаємо баланс і пам'ятаємо про set-based design.

Розробляємо инкрементально з швидкими циклами навчання та інтеграції (Build incrementally with fast, integrated learning cycle).

«Plan-Do-Check-Act», — кажуть нам agilist'и. І правильно роблять. Про цикл Демінга знають багато, хто відвідував тренінги з гибкостям, хто читав TPS (!=PMS), хто застосовує SCRUM або щось SCRUM-подібне. Чим частіше цикли, тим швидше ми отримуємо фідбек та навчаємося, а кінцева наша мета — в кожній ітерації отримати робочу систему крос-модулів і компонентів, а також синтегрированные при необхідності soft і hardware-ві частини.

Засновувати майлстоны на об'єктивних оцінках працюючих систем (Base milestones on objective evaluation of working systems).

Замість того, щоб позначати наші майлстоны, базуючись на фазах (розробка, тестування), ми повинні думати про більш дрібних частинах системи і ставити цілі итерациям, над якими працюють команди. Це дає нам розуміння, де ми є і куди ми рухаємося.

Візуалізація та лімітування WIP, скорочення розміру пакетів і управління довжиною черг (Visualize and limit WIP (work-in-progress), reduce batch sizes, and manage queue lengths).

«You can't manage what you don't measure», — голосить нам Пітер Друкер. WIP, розміри пакетів, довжина черг — це лише деякі речі, за якими необхідно стежити, щоб підвищити наші шанси на успіх і переконатися, що наш роадмэп взагалі виконаємо. Як багато всього ми можемо зробити через 1-2 дні, 3 тижні, місяць? Коли які завдання будуть виконані, в якій ітерації? Коли ми повинні зробити запуск, щоб зменшити наші витрати на цю вправу? На жаль, але подібні питання мають переслідувати нас завжди.

Дотримання каденції, синхронізація з крос-доменних плануванням (Apply cadence, synchronize with cross-domain planning).

Уявімо роту солдатів, близько 150 осіб. Як виглядає в їх випадку стройовий крок? Всі солдати дотримуються синхронність кроків. Аналогічно і тут — близько 150 розробників, які рухаються командами ітераційно і синхронно (2 тижні — один крок). Наше завдання полягає у виборі цієї каденції і її проходженні крос-командно. Це «must have» для частих інтеграційних циклів. В іншому випадку — не бачити нам інтеграції та робочого продукту в кінці.

Розкрити внутрішню мотивацію співробітників (Unlock the intrinsic motivation of knowledge workers).

Autonomy, Purpose і Mastery — ті самі «золоті ключі» до мотивації співробітників, як стверджує Деніел Пінк. Зможемо розкрити потенціал наших команд, як тільки наб'ємо руку в правильному підході до творчим людям: прибрати мікроменеджмент і надати необхідну автономність, дати можливість розвиватися і розвивати інших, а також показувати, як їх робота впливає на загальний результат.

Децентралізоване прийняття рішень (Decentralized decision-making).
Як же зменшити час циклу? Один з варіантів — делегувати прийняття рішень. Звичайно ж, ми не можемо делегувати всі рішення — ми повинні тримати при собі стратегічні питання, а інше — турбота наших колег. Це ще і допоможе відкрити внутрішню мотивацію співробітників, а також збільшить їх залученість. Якщо у вас не практикується делегування, то для початку таку культуру вам необхідно впровадити. З цим вам може допомогти «Delegation Poker & Management 3.0» авторства Jurgen Appelo.

Як ми почали впровадження

Більшість читачів подумає: «Які гарні слова... Ось тільки на практиці все інакше». Частково згоден, всі «унікальні» по-своєму. Трохи розповім про те, як ми стартували SAFe-трансформацію. Обмовлюся відразу, що це той самий випадок, коли «пролетаріат» ініціював трансформацію знизу.

Сама ідея зародилася давно, а ми як консалтинг-структура цю можливість втратити просто не могли. Чисте делівері добре, але ніхто не відміняв added value. Почали готувати ґрунт для нашого консервативного клієнта, де практично всі проекти ведуться ітеративне (спочатку Waterfall). Це означає чітко виділені стадії, мінливий скоуп по ходу релізу («це впихнем, але ось це теж поки залиш.... раптом проскочить»), періодичні демо, тривалість релізів залежить від вимог для імплементації (від 2 тижнів до кварталу). І не каскадна модель, але і не SCRUM або Kanban. Начебто, все працює, та ось тільки:

Change Management займає багато часу у лідерів;
багато команд, які живуть своїм життям, а залежності між командами досить сильні;
lead time завдань досить високий із-за відсутності автоматизації як такої (швидко викотити значуще value на ринок важко).

Почали робити обґрунтування, виходячи з вищесказаного. Переводили слова в долари:

CoD (cost of delay) нового функціоналу;
вартість викатки релізів;
вартість фікса багів, пов'язаних з невирішеними залежностями між командами;
кількість героїв-годин (це кількість годин, які люди проводили в режимі овертаймів, авралів і т. д.).

Були й інші, але ці статті — найбільш затратні. «Зараз ми точно почнемо трансформацію», — думав я. Однак, після подання цих даних клієнта, люди не перейнялися і нічого не зрушилося з місця, а при найменших спробах просунути обговорення далі, можна було почути: «У нас зараз дуже важливі релізи йдуть. Ми не можемо почати це робити прямо зараз». Зрозуміло, з плином часу релізи все ще залишалися важливими ?

Якщо гора не йде до Магомета, то Магомет йде до гори. Під час відрядження до Нью-Йорка ми з командою вирішили діяти проактивно і провели навчання та тренінги для різних рівнів: директора, тимлиды, розробники, продактовики. Побували ми з аналогічною програмою і в Індії, охопивши там широку аудиторію фахівців. Робота була виконана, та ось результатів було небагато, і нічого не завелося.

Поки ми обмірковували як бути далі, сарафанне радіо таки запустилося, дойшов до менеджменту. Через деякий час нас запросили в одну ініціативу для старту трансформації як консультантів, запропонувавши приміряти ролі RTE (Release Train Engineer). Тут трансформація і бере свій початок.

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

На сьогодні початок переходу на SAFe належить. У нас вже:

успішно стартував Architectural Runway разом з CTO та іншими технічними фахівцями;
команда продукту починає впроваджувати WSJF для пріоритезації;
команди почали реалізовувати SCRUM Framework з двотижневими спринтами і класичним набором зустрічей;
для старту використовували дворівневе планування і вже почали відмовлятися від валідації capacity, т. к. velocity команд вирівнявся;
команди визначили DoD і стандарти якості, грунтуючись на SonarQube, Burp Suite і Veracode.

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

Висновки

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

У цій статті ми розглянули, на чому ж базується SAFe:

4 конфігурації, які розраховані для різних організацій;
4 цінності (alignment, built-in-quality, transparency, program execution), на яких побудована культура (Culture eats strategy on the breakfast — Drucker);
9 принципів, якими ми оперуємо при прийнятті рішень кожен день.

Фактично ми подивилися на план впровадження, рекомендований SAFe, з якого видно, що ми починаємо з навчання колег. Якщо хто не читав Management 3.0 від Jurgen Apello , вкрай рекомендую. Книга розповідає про підходи до управління і пов'язаних з ними особливості: від примітивних конвеєрів до сучасних технологічних підприємств. В ній автор наводить 3 версії менеджменту:

1.0 — Doing wrong things;
2.0 — Doing the right things wrong;
3.0 — Doing the right things right.

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

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

Я збираюся більше фокусуватися на точкових моментах реалізації SAFe: економічних обгрунтуваннях, ролі DevOps, Built-in-Quality практиках та інших топіках. І, зрозуміло, розповісти, як проходить трансформація в особистому кейсі.

Опубліковано: 08/07/19 @ 07:00
Розділ Блоги

SEO Блог