Scrum@Scale

Scrum@Scale на одному екрані

Спершу — увесь фреймворк. Scrum@Scale Guide визначає його як дванадцять компонентів: два центри, три компоненти на циклі Scrum MasterScrum Masterусуває те, що блокує командуЛюдина, відповідальна за те, щоб працював процес, а не за те, щоб робота була зроблена. Вона усуває перешкоди й захищає команду від смикань — вона не керівник команди, і саме ставлення до ролі як до керівної є звичною причиною провалу.Докладніше в статті →Усі терміни, чотири на циклі Product OwnerProduct Ownerвідповідає за те, що будуютьОдна людина, відповідальна за те, що команда будує і в якому порядку. Повноваження тут справжні: Product Owner, який мусить погоджувати кожне рішення деінде, є посильним, і роль перестає працювати.Докладніше в статті →Усі терміни і три там, де цикли зустрічаються. Якщо ви діагностуєте організацію, а не вивчаєте фреймворк, читайте спершу останню колонку: так виглядає кожен компонент, коли його не несе ніхто.

Таблиці відповідають чинному гайду — версії 2.1 від лютого 2022 року, опублікованій під CC BY-SA 4.0. Перша редакція, лютого 2018-го, називала компонент Delivery словом Deployment, а «MetaScrum» — групу Product Owner, яку 2.1 називає командою Product Owner; багато з того, що ходить про фреймворк, досі вживає ці назви.

Один патерн на будь-якому масштабі

Гайд визначає Scrum@Scale як легкий організаційний фреймворк, у якому мережа команд, кожна з яких працює відповідно до Scrum Guide, може розвʼязувати складні адаптивні проблеми. Решту тримають дві ідеї. Перша — прямо зі Scrum: відповідальність за те, що будується, тримають окремо від відповідальності за те, як. Scrum робить це двома ролями — Product Owner і Scrum Master. Scrum@Scale — двома циклами, кожен із власними людьми й власним центром, які зустрічаються лише в названих компонентах.

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

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

Чотири-пʼять — не довільне число, і гайд каже, звідки воно. Scrum Guide обмежує команду десятьма людьми або менше; гайд посилається на гарвардське дослідження, за яким оптимальна команда в середньому — 4,6 людини, і застосовує те саме число на рівень вище. Варто помітити, що цей аргумент показує, а що ні. Число 4,6 стосується людей, які працюють разом цілий день; гайд переносить його на команди в групі команд, чиї учасники — представники, що зустрічаються на пʼятнадцять хвилин. Таке перенесення правдоподібне. Але не виміряне.

Арифметика вкладеності простіша, і вона справджується. Двадцять пʼять команд, що координуються всі з усіма, мають 300 можливих пар. Пʼять груп по пʼять мають по 10 пар у кожній групі, 50 разом, і ще 10 між пʼятьма представниками: 60. Сам гайд каже, що масштабування Scrum of Scrums зменшує кількість шляхів комунікації. Ціна — відстань. Проблема між двома командами з різних груп тепер проходить три переходи замість одного — від команди до представника її групи, від нього до представника іншої групи і вниз до іншої команди, — і тому масштабовані щоденні події йдуть послідовно щоранку, а не раз на тиждень.

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

Цикл Scrum Master: координація «як»

На цьому циклі три компоненти, і несе їх організація Scrum Master: Scrum Master команд, Scrum of Scrums Master і, в центрі, Executive Action Team. Окремі назви компонентів і дозволяють сказати «наша проблема — поставка» замість «нам треба більше аджайлу».

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

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

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

  Узгодити схожі процеси повʼязаних команд, розібратися з залежностями між командами, перш ніж вони стануть перешкодами, і тримати норми команд узгодженими, щоб результат був однорідним. Scaled Daily ScrumDaily Scrum15-хвилинне переплановуванняПʼятнадцятихвилинна подія кожного робочого дня, на якій розробники перевіряють рух до Sprint Goal і переплановують наступні двадцять чотири години. Це не звіт про статус: якщо зустріч працює лише з керівником у кімнаті, вона ним уже стала.Докладніше в статті →Усі терміни існує саме для цього компонента.

• Поставка

  Стабільний потік цінного готового продукту до клієнтів, робота різних команд, інтегрована в один цілісний продукт, і якісний досвід для тих, хто ним користується. Редакція 2018 року називала цей компонент Deployment.

Scrum of Scrums і його Master

Scrum of Scrums працює так, ніби він Scrum-команда. Він відповідає за повністю інтегрований набір потенційно придатних до релізу інкрементів наприкінці кожного спринту — один продукт, а не пʼять результатів команд. Його Scrum of Scrums Master відповідає за те, щоб масштабовані події відбувалися, були корисними й укладалися в таймбокс, а разом із Chief Product Owner — за придатний до релізу інкремент щонайменше раз на спринт. Гайд дає йому ще три обовʼязки: робити перешкоди, покращення й прогрес видимими для організації; узгоджувати поставку команд із планом релізів; і вести впорядкування та усунення перешкод, особливо тих, що між командами.

Сам патерн старший за фреймворк. Сазерленд уперше провів Scrum of Scrums в IDX Systems 1996 року, щоб тримати в ногу команди восьми бізнес-підрозділів, і описав це 2001-го. Scrum@Scale, уперше представлений 2014 року й записаний у гайді 2018-го, зробив правилом, що група — це команда з власними ролями, подіями й беклогом і з відповідальністю за один інтегрований результат, а не нарада лідів команд.

Scaled Daily Scrum

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

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

Scaled Retrospective

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

Executive Action Team

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

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

Найчіткіша опублікована картина цього циклу на великому масштабі — Saab. У числі за травень–червень 2018 року Harvard Business Review описав авіаційний підрозділ Saab — понад 100 agile-команд у софті, залізі й фюзеляжі, що будують винищувач Gripen, — який щоранку координується драбиною стендапів. О 7:30 кожна команда проводить пʼятнадцятихвилинну зустріч і називає свої перешкоди. О 7:45 ті, що потребують координації, ідуть до команди команд, яка їх розвʼязує або ескалює далі. До 8:45 executive action team має список критичних питань, які мусить розвʼязати. Команди також мають спільний ритм тритижневих спринтів.

До цього кейсу — два застереження. Статтю написано у співавторстві з Джеффом Сазерлендом, творцем Scrum@Scale, тож це не незалежне свідчення. А результат, на який вона посилається, — IHS Jane’s назвав Gripen найекономічнішим військовим літаком у світі, — це властивість літака, яку драбина, можливо, допомогла отримати, а не вимір самої драбини. Що кейс показує добре — механізм: сімдесят пʼять хвилин від блокера команди до столу людини, яка може його усунути.

Цикл Product Owner: координація «що»

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

Команда Product Owner і Chief Product Owner

Кожен Scrum of Scrums має один спільний беклог, що живить його команди, і команду Product Owner, яка його веде: Product Owner кожної команди на чолі з Chief Product Owner, який відповідає як Product Owner за всю групу. Chief Product Owner задає стратегічне бачення всього продукту, веде один упорядкований беклог для всіх команд, вирішує, які метрики відстежує команда, коригує беклог за відгуками клієнтів і модерує MetaScrum. Product Owner кожної команди й далі вирішує, що потрапляє в спринт його команди.

Завдання команди Product Owner — щоб ці окремі рішення йшли одним шляхом. Гайд перелічує, що для цього треба: зробити бачення видимим для всіх, заручитися підтримкою ключових стейкхолдерів, вести один упорядкований беклог без дублювання роботи, прибирати залежності, які піднімають команди, скласти узгоджені дорожню карту й план релізів і разом зі Scrum of Scrums Master погодити мінімально однаковий Definition of DoneDefinition of Doneщо тут означає «готово»Перелік умов, які робота мусить пройти, перш ніж її дозволено назвати завершеною: протестовано, перевірено, задокументовано, розгорнуто — як домовилась команда. Цінність у тому, що «готово» перестає бути предметом думки на статус-зустрічі.Докладніше в статті →Усі терміни для всіх команд — нижню межу, нижче за яку робота жодної команди не вважається завершеною.

Executive MetaScrum

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

Це правило старше за фреймворк. У PatientKeeper, бостонській компанії з програмного забезпечення для медицини, де Сазерленд був технічним директором, із 2003 року щотижня працював MetaScrum: півтори години, веде головний Product Owner, присутні CEO, вище керівництво й керівники маркетингу, розробки, QA, впровадження та підтримки. Там переглядали кожен реліз; спринти додавали, змінювали чи скасовували; продавці мусили обстоювати там будь-яку зміну розгортання продукту. Стаття Сазерленда 2005 року каже, що рішення компанії, які зачіпали беклог, ухвалювали лише на цій зустрічі, що прибрало більшу частину лобіювання, і називає її ключовою причиною успіху компанії; 2004 року PatientKeeper запустив понад 45 корпоративних релізів. Це розповідь автора про власну компанію, без жодного порівняння.

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

Де цикли зустрічаються

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

Процес команди — перший перетин

Процес команди — це Scrum так, як його приписує Scrum Guide. Оскільки кожна Scrum-команда має Product Owner і Scrum Master, кожна команда і є місцем першої зустрічі двох циклів. Гайд дає цьому компоненту чотири цілі: максимізувати потік завершеної роботи, що відповідає Definition of Done, підвищувати результативність команди з часом, працювати стійко й так, щоб це збагачувало команду, і пришвидшувати цикл відгуку від клієнтів. Від цього залежить усе вище. Масштабування команд, які не вміють завершити роботу за спринт, дає не масштабовану організацію, а більше незавершеної роботи — швидше.

Відгук на продукт і реліз — другий перетин

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

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

Метрики й прозорість — спільний компонент

Scrum@Scale не приписує набору метрик, але гайд каже, що як мінімум організація має вимірювати чотири речі, і для кожної дає приклад.

Гайд обґрунтовує цей компонент затримкою рішень: числа існують, щоб Executive MetaScrum і Executive Action Team вирішували на фактах і швидше. Читайте чотири виміри як набір. Кожен окремо можна поліпшити коштом іншого — продуктивність коштом якості, якість коштом швидкості, обидва коштом вигорання команди, — і лише всі чотири разом роблять це видимим.

Упровадження: модульний, але не необовʼязковий

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

Де починати, гайд теж каже: розробити масштабовану еталонну модель (Reference Model), перш ніж масштабувати. Це невеликий набір команд, що координуються, щоб постачати щоспринту, — на практиці один Scrum of Scrums із чотирьох-пʼяти команд. Коли ці команди досягають успіху, решта організації має робочий, здоровий приклад для наслідування, а Executive Action Team на малому масштабі дізнається, які корпоративні правила заважають. Копіювати еталонну модель, яка ще не постачає щоспринту, — означає копіювати її проблеми.

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

Scrum@Scale проти Nexus, LeSS і SAFe

Найбільше ці чотири перетинаються між трьома й девʼятьма командами, тож розмір між ними не вибирає; вибирає те, що організація готова змінити. Nexus не змінює структури: він дає інтеграції власника в особі Nexus Integration TeamNexus Integration Teamєдине, що Nexus додає до ScrumЗона відповідальності, яку Nexus додає до Scrum: Product Owner, Scrum Master і учасники з самих Scrum-команд, що відповідають за готовий інтегрований інкремент щонайменше раз на спринт. Вона навчає команди інтегрувати власну роботу; якщо вона сама робить усі мержі, то стала тією передачею роботи, яку Nexus мав прибрати.Докладніше в статті →Усі терміни, і це найлегша відповідь, коли зламалася саме інтеграція. LeSS вимагає реорганізації, від якої зникає більшість залежностей, — кожна команда стає фіче-командою, здатною провести видиму клієнтові фічу від ідеї до готовності, — і віддає більше, коли керівництво на це йде. SAFeSAFeScaled Agile Framework — фреймворк, що веде багато agile-команд як однуScaled Agile Framework — ролі, події та практики для координації десятків agile-команд, побудовані навколо Agile Release Train: пʼять-дванадцять команд, що планують разом раз на вісім-дванадцять тижнів. Це найбільш приписовий і найпоширеніший фреймворк масштабування — і саме тому його можна встановити, не змінивши того, хто ухвалює рішення.Докладніше в статті →Усі терміни стартує з наявної структури й додає над командами прошарок — Agile Release TrainAgile Release Train5–12 команд, що планують і постачають разомУ SAFe — довгоживуча група з пʼяти-дванадцяти agile-команд, зазвичай 50–125 осіб, які разом планують на PI Planning, працюють до однакових меж ітерацій і щоітерації інтегрують свою роботу. Її варто проводити навколо шляху, яким продукт іде до клієнтів; потяг, проведений навколо наявних відділів, координує їх, нічого не змінюючи.Докладніше в статті →Усі терміни, що координує їх навколо спільного Planning Interval на вісім–дванадцять тижнів.

Scrum@Scale стоїть між ними за вагою й окремо від них в одному. Він зберігає спринт як горизонт планування на кожному рівні, як Nexus і LeSS, а SAFe — ні. Він лишає структуру команд організації, чого не робить LeSS. І він єдиний із чотирьох вписує керівників у фреймворк як Scrum-команди з власними беклогами й каже, коли вони можуть змінювати пріоритети. Це його найсильніша ідея і найчастіша точка відмови: частину, яку фреймворк покладає на керівництво, керівництво найохочіше відкладає.

Одна деталь показує, як мандрує словник. У SAFe на кожному потязі була подія під назвою Scrum of Scrums, доки версія 6.0 2023 року не перейменувала її на Coach Sync. У Scrum@Scale Scrum of Scrums — це команда з беклогом і відповідальністю за один інтегрований продукт; у SAFe до 6.0 і в більшості організацій, що вживають цю назву, — зустріч. У цій різниці — більша частина різниці між фреймворком та його імітацією.

Що показують дані

Разом ці дані тонкі так само, як і в Nexus, але з іншої причини. Детальні розповіді походять від творця фреймворку; великі опитування рахують Scrum of Scrums — ту частину Scrum@Scale, що в більшості організацій і так була. Висновок Verwijs і Russo все ж варто зберегти: найпростіші підходи — Scrum of Scrums і LeSS — отримали трохи вищі бали за підтримку менеджменту, ніж решта, 5,11 і 5,07 проти 4,57–4,88, з відривом, який автори вважають надто малим, щоб мати практичне значення. Жодне з цих джерел не виокремлює двох компонентів, що роблять Scrum@Scale іншим, — Executive MetaScrum і Executive Action Team. Чи дають вони те, що обіцяє гайд, сьогодні — аргумент, а не результат дослідження.

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

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

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

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

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

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

• МенеджментSAFeSAFe (Scaled Agile Framework) — це набір ролей, подій і практик, що дає змогу вести десятки agile-команд в одному спільному ритмі планування. Це найбільш приписовий із фреймворків масштабування і найпоширеніший у великих компаніях — саме тому, що дає наявній управлінській структурі визначене місце. Сторінка починається з усього фреймворку на одному екрані — кожна подія на кожному рівні з її ритмом і хто сидить на кожному рівні; далі — Agile Release Train і Planning Interval, чотири конфігурації та дорожня карта впровадження, PI Planning та Inspect & Adapt, як SAFe вимірює себе і як кожну метрику обходять, його цінності й десять принципів, що показують незалежні дослідження і де все це вироджується.
• МенеджментNexusNexus — фреймворк від Scrum.org для 3–9 Scrum-команд, що будують один продукт, і він додає до Scrum рівно одну зону відповідальності: Nexus Integration Team. Його передумова: на цьому масштабі першою ламається інтеграція, а не планування. Сторінка починається з усіх елементів Nexus на одному екрані — кожна подія і що вона робить зі своїм відповідником у Scrum, і три артефакти з їхніми зобовʼязаннями; далі — чому доповнення лише одне, хто насправді входить до команди інтеграції, кожна подія за гайдом 2021 року і що змінилося з 2018-го, як знаходити й прибирати залежності, як Nexus співвідноситься з LeSS, SAFe і Scrum@Scale, що показують дані і де все це вироджується.
• МенеджментLeSSLeSS (Large-Scale Scrum) — фреймворк, що масштабує Scrum, ведучи багато команд як одну: один Product Owner, один беклог, один спринт, один продукт. Він масштабується прибиранням організаційної структури, а не додаванням, і тому найвимогливіший до впровадження та найближчий до самого Scrum. Сторінка починається з усіх правил і всіх подій на одному екрані; далі — розмасштабування й визначення продукту, фіче-команди й те, що LeSS прибирає, десять принципів, кожна подія, LeSS Huge і його Requirement Areas, що показують чотири впровадження з датами і де все це вироджується.