Nexus чи SAFe? Як масштабувати скрам

Масштабований скрам (Scaled Scrum) — це такий скрам, де багато скрам-команд працюють над однією системою або продуктом. Мета скраму, незалежно від його масштабу, така: створювати високоякісні, готові до релізу версії продукту до кінця кожного спринту.

Для цього існує безліч фреймворків. Найрозповсюдженіші — SAFe, Less і Nexus, є й інші. Між іншим, ось статистичні дані використання різних фреймворків масштабування великими організаціями зі звіту Scrum Master Trends 2019.

А зараз поговоримо про два популярні фреймворки масштабування скраму — SAFe і Nexus — і про те, чим вони схожі і чим відрізняються між собою.

Що таке Nexus і що таке SAFe

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

У команд, що працюють за SAFe, беклоги різні, та є і один спільний — програмний беклог.

Це було коротко, а тепер пірнемо глибше.

Що подібного в Nexus і SAFe

Nexus — ART

Група команд в Nexus дуже схожа за складом із Agile Release Train (ART). І в SAFe, і в Scrum/Nexus вона по суті є самокерованою командою самоорганізованих команд 😂 з кількома ключовими ролями на рівні команди команд.

Слідування принципам емпіризму, самоуправління в рамках, організація довкола цінностей і потоку

Теорія Scrum підкреслює емпіризм і самоуправління у поєднанні з Flow. Теоретична база SAFe ширша, та за змістом подібна.

Lean/Agile-лідерство

І SAFe, і Scrum/Nexus підкреслюють необхідність у зміні стилю лідерства — у формуванні лідерів, які служать своїм командам, володіють мисленням росту, подають приклад, живуть і дихають принципами й практиками Lean і Agile і прагнуть до постійного самовдосконалення.

Спринт — ітерація

SAFe обирає термін «ітерація», який більше нагадує екстремальне програмування (XP), та, якщо поглянути на деталі, спринти й ітерації цілком взаємозамінні.

Беклог одного продукту — програмний беклог

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

Група інтеграції Nexus (NIT) — системна група

Обидві мають подібну ціль — включення інтегрованого інкременту вкінці кожної ітерації/спринту для всіх команд. Коли ж доходить до того, ЯК працюють ці команди, Nexus спирається на коучингову/допоміжну роль, тоді як SAFe приділяє трохи більше уваги фактичній роботі з інтеграцією. Підхід NIT може бути вкрай цікавим для системної групи SAFe ART.

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

Скрам-майстер в NIT — RTE

Скрам-майстер в NIT виконує роль, аналогічну Release Train Engineer (інженеру підготовки релізів), — координує і сприяє ефективному використанню Scrum/SAFe в Nexus/ART із метою забезпечення жорсткого циклу перевірки й адаптації з використанням інкрементів робочого продукту.

Емпіризм через інтегровані робочі інкременти кожного спринту — демо системи та огляд спринту Nexus, що відповідають загальному визначенню готового

І SAFe, і Scrum дають зрозуміти, що часті перевірки й адаптація робочих інтегрованих інкрементів є ключем до управління невизначеністю/мінливістю, властивим для розробки продукту у складному середовищі. Огляд спринту в Nexus і демонстрація системи — подібні події, що мають однакову частоту — щокілька тижнів (щоспринту/ітерації).

Ціль спринту Nexus — цілі програмного PI, лише з різною частотою

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

Не масштабуйте лайно. Масштабування вимагає технічної досконалості

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

Чим різняться Nexus і SAFe

Nexus — ART

Чи ж ми не писали вище, що Nexus та ART схожі? Що ж, Господь в деталях.

Nexus — це 3-9 Scrum-команд, що працюють разом. ART — це 5-12 команд. Ця, здавалося б, незначна зміна дає уявлення про деякі варіантах дизайну двох фреймворків. Для Nexus меншого розміру простіше може бути надати право власності на продукт, що робить єдиного власника продукту більш життєздатним. Події рівня Nexus організувати легше, ніж заходи, присвячені всьому ART, і це дає деяке уявлення про те, чому SAFe об’єднує всі ART лише для кожного PI, а не для кожного спринту.

Для більшої кількості команд, що працюють над одним продуктом, є Nexus+, що складається з кількох Nexus. Складність організації довкола цінності як для Nexus+, так і для SAFe ART полягає в тому, щоб виявити, який набір команд має тісно співпрацювати між собою.

Один власник продукту — група власників продукту (PO) чи менеджерів (PM)

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

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

Як ми підкреслюємо в тренінгу Scrum.org з володіння продуктом, переваги Scrum обмежені, якщо ваші власники продуктів є писцями (Scribes) чи довіреними особами (Proxies). Можливо, простіше перекоординувати зустрічі та звільнити час власника продукту, але тоді складніше добитися максимальної віддачі. Вигода зростає, коли власники продуктів є реальними представниками бізнесу, спонсорами чи, в ідеалі, підприємцями щодо свого продукту.

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

Темп/частота об’єднання всього Nexus/ART для планування й ретроспективи

Огляди, ретроспективи, плани й уточнення Nexus доступні для всіх на кожному спринті. Зазвичай огляд спринту відвідує широке коло людей, у тому числі стейкхолдери Nexus. На уточненні, плануванні й ретроспективі присутні відповідні представники Scrum-команд. Доречність, звісно ж, залежить від контексту.

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

Формальна міжкомандна ретроспектива/каденція планування в SAFe — це етап програми, що охоплює всю подію АRТ.

Немає огляду спринту на рівні команди

В Nexus є тільки огляд спринту між командами. “На папері” в SAFe також є як ітерації на рівні команди, так і системна демонстрація на рівні ART. Насправді ж багато ART пропускають огляди ітерацій і отримують достатній аналіз та адаптацію з системної демонстрації.

Об’єм – команда команд і організаційний рівень

Nexus фокусується лише на команді команд, яка вважається необхідною конфігурацією в SAFe. SAFe також охоплює інші компетенції, необхідні для гнучкості бізнесу, – бережливе управління портфелем (Lean Portfolio Management) і крупні рішення (Large Solutions). Деякі організації, що використовують Nexus, зрештою звертаються до компетенцій SAFe на рівні портфоліо чи до портфельних канбанів на додаток до Nexus.

Інтегрований беклог спринту Nexus – різні беклоги командних ітерацій

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

Програмний Kanban

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

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

Інші потенційно корисні елементи SAFe, яких немає в Nexus

Оскільки Nexus спроєктований як полегшений фреймворк з більш обмеженими можливостями, ніж SAFe, не дивно, що в SAFe значно більше елементів, про які не згадується в Nexus. Одні з них можуть знадобитися у вашому контексті, інші – не обов’язково. Згадайте хоча б Architectural Runway, ітерації інновацій і планування, Kanbans на рівні команди, DevOps, конвеєр безперервного постачання, системну архітектуру, власників бізнесу, фічі/енейблери, епіки.

І взагалі, по деталі завжди краще звертатися до мануалів:

• Nexus Guide
• SAFe whitepaper

Декілька пропозицій, як покращити один фреймворк за допомогою іншого

Як покращити SAFe за допомогою Nexus

• Аналізуйте і плануйте разом кожен спринт/ітерацію в ART

Звичайного спільного огляду спринтів недостатньо. Робіть ретроспективи, плануйте разом. І це не означає, що потрібно об’єднати весь ART. Спочатку потрібно досягти певної узгодженості, аби потім відділитися і спланувати ітерації всім окремо, а тоді знову об’єднатися. Патерн за принципом того, який використовують Solution Trains при PI Planning.

• Користуйтеся беклогом спринту рівня ART

Подібно до програм-борда для PI, використовуйте інтегрований беклог спринту Nexus для перегляду залежностей на більш детальному рівні спринту/ітерацій. Це артефакт, який може підтримувати планування ітерацій на рівні ART.

Як покращити Nexus за допомогою SAFe

• Використовуйте Big Room Planning (планування великої кімнати) щовісім-дванадцять тижнів

Час від часу в Nexus можна використовувати SAFe PI Planning для високорівневих узгоджень/уточнень.

• Відрегулюйте каденції й рівень участі

Виявіть, який рівень «великої кімнати» в усьому Nexus потрібен в кожному спринті, а який може відповідати менш частій каденції (наприклад, PI). Перегляньте, як ви виконуєте планування спринту Nexus, зокрема ретроспективу.

• Надихайтеся принципами й компетенціями SAFe Lean/Agile

Розгляньте принципи SAFe і додаткові компетенції Lean/Agile, такі як Lean Portfolio Management, як спосіб підтримки Nexus у рамках традиційної екосистеми в організації. Можна використовувати перегляд оцінок гнучкості бізнесу «Measure&Grow». У його контексті кожна категорія чи елемент може бути:

• чимось, що ви вже робите (чудово!)
• чимось, що ви ще не робите, але бачите сенс розглянути (також чудово!)
• чимось, що немає змісту робити в вашій ситуації (достатньо справедливо)
• чи тим, із чим ви категорично не погоджуєтеся (цілком прийнятно, якщо ви глибоко розглядаєте кожен принцип/метод).

Ця вправа допоможе вам розробити беклог/дорожну карту покращень.

Багато варіантів – завжди добре. Тунельний зір – завжди зле

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

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

“Приймайте мінливість, зберігайте варіативність”

Вивчайте нові фреймворки масштабування, пробуйте різні техніки. Зрештою, і скрам, і сейф говорять про те, що головне – практика 😉