Scrum@Scale

Два цикли, повторені фрактально

Scrum@Scale розділяє роботу з управління організацією на два окремі цикли. Цикл Scrum Master відповідає за те, як робота виконується: перешкоди, вдосконалення, координація між командами, доведення до продакшену. Цикл Product Owner відповідає за те, що робиться: бачення, порядок беклогу, декомпозиція, рішення про реліз.

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

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

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

Цикл Scrum Master: «як»

На цьому циклі три компоненти. Кожен — це спроможність, яку організація або має, або ні; окремі назви для них і дозволяють сказати «наша проблема — третій», замість «нам треба більше аджайлу».

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

  Виявляти перешкоди й реально їх усувати, зокрема ті, яких команда не усуне сама. Вимірюваний тест — чи з’являється та сама перешкода у двох ретроспективах поспіль.

• Міжкомандна координація

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

• Поставка

  Довести інтегрований, готовий до релізу продукт до користувачів: пайплайн, середовища, механіка релізу. У ранніх редакціях гайду цей компонент називається Deployment.

Центр цього циклу — Executive Action Team, або EAT. Це справжня Scrum-команда з лідерів, які мають повноваження змінювати організацію, а її беклог — це перешкоди організації. Вимога щодо повноважень і є суттю: перешкоду на кшталт «закупівлі шість тижнів погоджують тестове середовище» Scrum Master не усуне, і якщо нею не володіє хтось із бюджетними повноваженнями, її порушуватимуть щоспринту вічно.

Роль на цьому циклі — Scrum of Scrums Master, або SoSM. Він відповідає за реліз спільної роботи своєї групи команд так само, як Scrum Master відповідає за процес своєї команди. Масштабовані події — це Scaled Daily Scrum (коротка щоденна зустріч, де представники підіймають міжкомандні блокери, після щоденних зустрічей команд) і масштабована ретроспектива, де група оглядає себе як одне ціле.

Цикл Product Owner: «що»

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

Центр цього циклу — Executive MetaScrum, або EMS: форум, де всі конкурентні пріоритети стейкхолдерів зводяться в один упорядкований беклог людьми з повноваженнями вирішувати. Він збирається з регулярною каденцією, зазвичай щонайменше раз на спринт, у форматі події під назвою MetaScrum. Роль, що веде цей цикл, — Chief Product Owner, який володіє порядком усього беклогу продукту так само, як Product Owner володіє беклогом однієї команди.

Де цикли стикаються

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

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

Scrum@Scale проти SAFe

Практичний компроміс — у тому, звідки береться судження. SAFe несе судження всередині фреймворку: конфігурація каже, що саме запускати. Scrum@Scale очікує, що судження дасть організація, — це дешевше й легше, коли діагноз правильний, і дає напівзбудований набір зустрічей, коли ні.

Як це виявляється в реальній поставці

Модульність Scrum@Scale — це і сила, і ризик. За вдалого впровадження організація діагностує, що її вузьке місце — пріоритизація, запускає Executive MetaScrum і виправляє це, не чіпаючи більше нічого. За невдалого «модульність» стає дозволом узяти зустрічі й пропустити відповідальність: Scrum of Scrums, який звітує нагору й не усуває жодних перешкод.

Де він вироджується

• Scrum of Scrums як статус-зустріч, а не як команда з власним беклогом перешкод.
• Немає Executive Action Team, тож перешкоди рівня організації порушують вічно й ніколи не усувають.
• Пропуск Executive MetaScrum лишає пріоритизацію на відкуп ескалаціям.
• Групи значно більші за п’ять команд, де координаційна зустріч перестає бути розмовою.
• Executive Action Team із делегатів без бюджетних повноважень, які можуть назвати перешкоди, але не усунути їх.
• Два цикли, злиті в один управлінський форум, після чого бік «як» починає вирішувати «що».

Коли це застосовувати

Пов’язані сторінки

• МенеджментSAFeSAFe (Scaled Agile Framework) координує десятки команд, ставлячи їх на спільний ритм планування. Це найбільш приписовий із фреймворків масштабування і найпоширеніший у великих компаніях — саме тому, що дає наявній управлінській структурі визначене місце. На цій сторінці ми розберемо всі чотири конфігурації, ролі над рівнем команди, десять принципів під ним і чесні аргументи проти.
• МенеджментNexusNexus — це фреймворк масштабування від Scrum.org для трьох-дев’яти команд на одному продукті. Nexus додає до Scrum рівно одну зону відповідальності — команду інтеграції, відповідальну за єдиний інтегрований інкремент, — виходячи з того, що на цьому масштабі ламається саме інтеграція, а не планування. На цій сторінці — хто входить до цієї команди, три артефакти й усі п’ять подій.
• МенеджментLeSSLeSS (Large-Scale Scrum) зберігає одного Product Owner, один Product Backlog, один спринт і один придатний до поставки інкремент — незалежно від кількості команд. Він масштабується прибиранням організаційної структури, а не додаванням, і тому є найвимогливішим до впровадження та найближчим до справжнього Scrum. На цій сторінці — десять принципів, розшарування «правила — гайди — експерименти», усі події LeSS і обидва варіанти.