LeSS

LeSS на одному екрані

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

Масштабування через віднімання

Почнімо з того, що зазвичай стається, коли продукт переростає одну команду. Зʼявляється друга команда, потім третя. Хтось помічає, що троє Product OwnerProduct Ownerвідповідає за те, що будуютьОдна людина, відповідальна за те, що команда будує і в якому порядку. Повноваження тут справжні: Product Owner, який мусить погоджувати кожне рішення деінде, є посильним, і роль перестає працювати.Докладніше в статті →Усі терміни тепер пріоритизують один проти одного, тож над ними наймають координатора. Інтеграція постійно зривається — створюють команду інтеграції. Через пів року є програмний менеджер, реліз-менеджер, керівний комітет і купа передач роботи між ними, а поставка йде повільніше, ніж з однією командою.

LeSS вважає весь цей ланцюжок хворобою, а не ліками. Його відповідь — масштабувати Scrum, додаючи якомога менше: один Product Owner на весь продукт, один Product BacklogBacklogупорядкований список того, що лишилосьУпорядкований список усього, що може бути зроблено, і найцінніше — згори. Ключове слово тут «упорядкований»: беклог, де все однаково важливе, є списком побажань і не полегшує жодного рішення.Докладніше в статті →Усі терміни, один спринт, спільний для всіх команд, і один інтегрований інкремент наприкінці. Над командою немає жодної нової ролі. Між командами й клієнтом немає програмного прошарку.

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

Перше рішення: що вважати продуктом

LeSS ставить одне питання раніше за всі інші, і більшість впроваджень його пропускає: що таке продукт? Відповідь вирішує, скільки Product Owner і беклогів у вас буде. Визначте продукт вузько — і продуктів багато, у кожного свій власник, а кожна зміна, що перетинає два з них, стає переговорами. Визначте широко — і та сама зміна стає одним елементом в одному беклозі, який упорядковує одна людина.

Порада LeSS — визначати продукт так широко, як це практично, і якомога ближче до клієнта, а потім питати, чи може одна людина ним володіти. Якщо ні — саме тут починається LeSS Huge, а не привід знову нарізати продукт вужче.

Розвилка в масштабуванні: відняти чи додати

Це найчіткіша розвилка в масштабуванні. LeSS вимагає, щоб змінилася організація й фреймворк до неї підійшов; SAFeSAFeScaled Agile Framework — фреймворк, що веде багато agile-команд як однуScaled Agile Framework — ролі, події та практики для координації десятків agile-команд, побудовані навколо Agile Release Train: пʼять-дванадцять команд, що планують разом раз на вісім-дванадцять тижнів. Це найбільш приписовий і найпоширеніший фреймворк масштабування — і саме тому його можна встановити, не змінивши того, хто ухвалює рішення.Докладніше в статті →Усі терміни сам підлаштовується під організацію. LeSS дає кращий результат там, де керівництво справді йде на реорганізацію, і провалюється повністю там, де ні: напів-LeSS, який усе одно працює, не існує, бо відкинуті правила якраз і тримають решту. Nexus стоїть між ними: має того самого єдиного Product Owner і беклог, додає одну відповідальність за інтеграцію й не вимагає жодної реорганізації — тож це менший перший крок, а LeSS — глибший.

Фіче-команди — і що LeSS прибирає

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

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

Ціна реальна, і її варто планувати, а не заперечувати. Фіче-команді доводиться працювати в чужому коді, і перші місяці в незнайомих компонентах вона буде повільнішою, ніж були спеціалісти. Відповіді LeSS — про людей: ментор компонента, який добре знає компонент, навчає команди, що в ньому працюють, і переглядає їхні зміни, не володіючи чергою; спільноти практики навколо спільної навички; робота в парах; і спільна кодова база, яку можна змінювати кожному. Спеціалісти не зникають — вони перестають бути чергою.

Що LeSS зберігає, а що прибирає

Ролі в LeSS — це ролі Scrum і більше нічого. Один Product Owner володіє впорядкуванням усього Product Backlog, а команди спілкуються з клієнтами й користувачами напряму, а не через бізнес-аналітиків. Команди — це фіче-команди: крос-функціональні, довгоживучі, до десяти людей кожна, як у Scrum Guide. Scrum MasterScrum Masterусуває те, що блокує командуЛюдина, відповідальна за те, щоб працював процес, а не за те, щоб робота була зроблена. Вона усуває перешкоди й захищає команду від смикань — вона не керівник команди, і саме ставлення до ролі як до керівної є звичною причиною провалу.Докладніше в статті →Усі терміни обслуговує одну-три команди на повну ставку — «на повну» тут правило, бо частково зайнятий Scrum Master стабільно скочується до ролі координатора.

Складніша половина — прибирання. Немає проєктного менеджера, програмного менеджера, тімліда, що роздає роботу, окремої архітектурної групи, яка вирішує за команди, відділу аналізу чи тестування, немає PMOPMOProject Management Office — офіс, що задає стандарти проєктівПідрозділ, що задає стандарти управління проєктами в організації, збирає звітність із проєктів і часом наймає проєктних менеджерів. Його цінність залежить від того, що саме з цього він робить: PMO, який лише збирає статус-звіти, додає рівень, не додаючи жодного рішення.Усі терміни між Product Owner і клієнтом. Наявні менеджери не мусять зникати, і правила називають їх необовʼязковими, а не забороненими. Але їхня робота змінюється з керування роботою на покращення системи, крізь яку ця робота проходить: іти й дивитися, як команди працюють насправді, навчати, прибирати перешкоди, яких жодна команда не прибере сама, і розвивати людей.

Недороблена робота й «відділ недоробленого»

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

Правило — не скасувати цей відділ першого ж дня. Воно в тому, щоб розширювати Definition of Done крок за кроком, переносячи в спринт одну діяльність щоразу, коли команди можуть її взяти, доки відділу не залишиться чого робити. Сторінка про Scrum малює той самий розрив і пояснює, чому відкладати його — дорогий вибір; LeSS додає, що на масштабі недороблене від восьми команд приходить одночасно.

Десять принципів і три шари настанов

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

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

• Правила — обовʼязкові

  Мінімальне визначення LeSS — перша таблиця на цій сторінці. Порушили правило — ви більше не робите LeSS. Це припустимий вибір, але назвіть його чесно.

• Гайди — перевірені поради

  Практики, що спрацювали в багатьох впровадженнях: як провести SprintSprintцикл роботи фіксованої довжиниФіксований період, зазвичай від тижня до чотирьох, наприкінці якого є щось достатньо завершене, щоб показати. Фіксована саме довжина, а обсяг рухається: спринт, який подовжили під роботу, втратив єдине, заради чого існував.Докладніше в статті →Усі терміни Planning One, як формувати фіче-команди, як Product Owner працює з багатьма командами. Наполегливо рекомендовані, але не обовʼязкові.

• Експерименти — спробуй і подивись

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

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

Події по черзі

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

Sprint Planning One і Two

Sprint Planning One — коротка й спільна. Product Owner приносить верх беклогу, а учасники всіх команд — усі або представники кожної, якщо зала замала, — вирішують, яка команда які задачі бере. Вибір навмисно попередній, а другий результат важить не менше за перший: помітити задачі, над якими двом командам варто працювати тісно, ще до того, як хтось написав бодай рядок.

Sprint Planning Two йде одразу після, і кожна команда планує, як будуватиме свої задачі. Команди, що взяли тісно повʼязані задачі, планують в одній кімнаті — LeSS називає це багатокомандним Sprint Planning Two, — щоб спільне проєктне рішення ухвалили раз, а не двічі.

Три види рефайнменту

• Загальний рефайнмент

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

• Багатокомандний рефайнмент

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

• Командний рефайнмент

  Звичайна діяльність зі Scrum — для задач, які найімовірніше візьме одна команда. У Scrum це норма, у LeSS — виняток, щойно задачі перетинаються.

Daily Scrum і координація між подіями

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

Sprint Review і дві ретроспективи

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

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

LeSS Huge: Requirement Areas

• LeSS Basic — 2–8 команд

  Один Product Owner здатен утримати весь беклог у голові. Усі команди мають спільний Sprint Review і спільну загальну ретроспективу. Нічого понад Scrum не додається — це фреймворк у задуманому вигляді.

• LeSS Huge — 8+ команд

  Беклог ділиться на Requirement Areas, кожна з Area Product Owner і чотирма-вісьмома командами. Єдиний Product Owner лишається й тепер упорядковує роботу між областями, а не між окремими задачами.

Requirement Area — це велика область потреб клієнта, і правило, яке вирішує долю LeSS Huge, — як ви їх нарізаєте. Області виділяють за тим, що потрібно клієнтові, ніколи за технічним компонентом. Область «оформлення замовлення» — правильно. Область «шар бази даних» відтворює саме ту передачу роботи, заради усунення якої LeSS існує, і за два спринти дасть компонентні команди з новою вивіскою.

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

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

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

Впровадження LeSS — і що показують чотири впровадження

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

• Глибоко й вузько, а не широко й мілко

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

• Згори вниз і знизу вгору

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

• Добровільність

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

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

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

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

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

Крейг Ларман, один із двох авторів LeSS, передбачив, як це стається, у пʼяти коротких «законах організаційної поведінки» — тут своїми словами. Організації неявно побудовані так, щоб захищати наявні посади менеджерів і спеціалістів. Тож будь-яку зміну зводять до нових назв для старих ролей. Того, хто цьому опирається, називають пуристом чи теоретиком. Витіснені менеджери й спеціалісти стають коучами змін — і оголошують зміну завершеною. А у великих організаціях культура йде за структурою — саме тому LeSS спершу змінює структуру.

Чесна межа лежить там само. LeSS розвʼязує координацію, прибираючи структуру, що її породжує, і не має відповіді для організації, яка не хоче цю структуру прибирати: зменшеної версії, яка все одно працює, немає. Кейс BMW додає другу межу — зміна структури не змінює винагород, кар’єрних шляхів і оцінювань довкола неї, а вони тягнуть структуру назад. А там, де продукт узагалі неможливо інтегрувати щоспринту, — залізо з довгими термінами, релізний цикл регулятора, — правило одного інкремента стає напрямком, а не фактом, і LeSS так і каже. Це чесно, але вирішувати, з яким обсягом недоробленого ви готові жити, лишається вам.

• Кілька Product Owner, що зʼявляються «з практичних міркувань», відновлюють прошарок, який LeSS прибрав.
• Компонентні команди, перейменовані на фіче-команди, — і кожній фічі досі потрібні три з них.
• Requirement Areas, нарізані за технічними компонентами або по дві-три команди в кожній.
• Девʼять областей, запущених до того, як запрацювала перша, — і кожна успадковує її проблеми.
• Команди інтегруються лише наприкінці спринту, тож «один інкремент» стає авральним складанням.
• Definition of Done, який ніколи не росте, тож «відділ недоробленого» стає постійним.
• Scrum Master на частину ставки на пʼять команд, який стає координатором зустрічей замість того, щоб змінювати систему.
• Прибраний рівень менеджменту тихо відроджений як «тімліди» — з недоторканою старою системою оцінювання.
• Пропуск загальної ретроспективи, де мали порушувати міжкомандні та організаційні перешкоди.

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

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

• Менеджмент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, що показують дані і де все це вироджується.
• МенеджментОрганізаційні структури управлінняОрганізаційна структура — це те, як компанія ділить роботу між підрозділами й хто кому підпорядковується, а отже — хто дає проєкту людей, гроші й рішення. Лінійна, функціональна й матрична — це не методології управління на кшталт Scrum чи Kanban. Це форма організації, всередині якої методології доводиться працювати, і вона визначає, скільки повноважень насправді має людина, що веде проєкт. Сторінка починається з усіх поширених структур поруч і п’яти питань, які покажуть, у якій із них ви працюєте, а далі — два питання за кожною структурою, класичні ієрархії, матриця і дев’ять її відомих збоїв, проєктні й продуктові команди, закон Конвея, компанії, що пробували обійтися без менеджерів, і де реструктуризація перетворюється на театр.