Уявіть, що у вас є 3 гнучкі команди, які працюють за Scrum, і тепер ви хочете масштабувати – Scrum вже недостатньо. Який наступний крок? Для цього існують різні фреймворки, зокрема БЕЗПЕЧНОNexus та багато інших. Сьогодні ми ближче познайомимося з LeSS.
LeSS - це SCRUM (визначення)
У "The Структура LeSS намагається застосувати принципи та ідеали Scrum у великому корпоративному контексті якомога простіше за допомогою чітко визначених правил та інструкцій. Через свою простоту LeSS отримав визначення або ярлик "ледь адекватного" фреймворку –, але це не означає, що він має негативне забарвлення.
7 Переваги системи LeSS
Основний фокус LeSS не в тому, щоб створити ще один, новий фреймворк. Натомість принципи Scrum застосовуються до багатьох команд.
Деякі з переваг, які ви отримуєте LeSS можуть бути досягнуті:
- Нижчі витрати на впровадження впроваджуючи практики, які команди вже використовують у Scrum
- Власник продуктуякий розуміє структуру та принципи, а потім долає розрив між бізнес- та технічними командами.
- Для Доставка товару, менше людей будуть необхідні. LeSS не додає експоненціально більше ролей та накладних витрат
- Він пропонує повний огляд продукту у фокусі уваги
- У "The Команди перебувають у прямому контакті з клієнтом та іншими зацікавленими сторонами
- Постійне вдосконалення сприяють регулярні ретроспективи та інші зустрічі, які є фундаментальними процесами маніфесту Agilen
- Для багатьох організацій підхід LeSS до масштабування Scrum-команд може бути таким наступним логічним кроком на шляху до гнучкого масштабування.
Перш ніж ми заглибимося в тему, невелике зауваження. Нещодавно у нас в гостях були 11 міжнародних експертів з гнучких методів на вебінарі –, присвяченому питанню: Як правильно масштабувати гнучкі методи?
Результатом став цей фантастичний відеозапис (англійською мовою), в якому розглядаються, наприклад, такі питання:
- Як краще починати: знизу вгору чи зверху вниз?
- Як ви допомагаєте лідерам дійти згоди щодо спільного бачення?
- Як правильно обрати гнучкий фреймворк – і чому це насправді не так важливо?
Моя найтепліша рекомендація: подивіться! Це займе відносно багато часу, але воно варте кожної хвилини.
Як побудована система LeSS? Визначення
За визначенням, великомасштабний скрам побудований на принципах, фреймворках, настановах та експериментах. Ілюстрація (джерело: Веб-сайт LeSS) показує це. Пояснимо це на прикладі:
Принципи: Команда X розробляє мобільний телефон. Для них важливий принцип прозорої діяльності. Тому вони працюють прозоро і роблять регулярні щоденники. З іншого боку, вони хочуть з'ясувати, звідки саме надходять матеріали, важливі для виробництва мобільного телефону, щоб потім прозоро повідомити про це своїм клієнтам. Прозорість наскрізь.
рамкові умови: У той же час вони постійно працюють над створенням рамкових умов, які роблять фреймворк SCRUM ідеальним з гнучкі цінності визначає: Відкритість, Сміливість, Повага, Цілеспрямованість та Відданість.
Керівні принципи: Керівними принципами розробки є бачення продукту, технічні вимоги до продукту, а також спосіб спільної роботи в команді.
Експерименти: Коли виникає невизначеність, ми опиняємося в зоні експериментів, де все зводиться до тестування та випробувань. Наприклад, якщо ми хочемо розробити нову функцію або вийти на абсолютно нову цільову групу. (Джерело: Веб-сайт LeSS)
10 принципів LeSS
Визначення LeSS 10 принципів. Вони допомагають –, якщо ми залишимося з нашим прикладом –, розробити мобільний телефон, який найбільше відповідає цінностям та ідеям клієнта. Ось список 10 принципів з першого погляду:
- Масштабний скрам - це скрам: Мобільний телефон може розроблятися не однією, а кількома командами, щоб клієнт був задоволений, а час розробки був розумним
- Емпіричне управління процесом: На основі короткострокового досвіду окремі функції мобільного телефону постійно адаптуються та переглядаються.
- Прозорість: Наша команда Х вирішила відтепер відкрито ділитися щотижневими цілями команди на своїй внутрішній платформі. Це дуже допомагає зрозуміти, над чим насправді працює кожен.
- Більше з меншими витратами: В принципі, слід експериментувати з новими ідеями і вчитися на них, перш ніж встановлювати інертні правила і, таким чином, додавати "баласт".
- Повний фокус на продукті: Команди мають ще більшу схильність до неоптимізації своїх цілей, ніж окремі люди. Тому найбільшим викликом для команд є інтеграція їхньої роботи в продукт. Тому "призначення" всього продукту має бути максимально чітким. Таким чином, команди та окремі особи мають можливість самостійно визначати відповідні підцілі, якщо це необхідно.
- Клієнтоорієнтованість: Тільки команди, які працюють безпосередньо з клієнтом, можуть максимізувати реальну цінність продукту. На жаль, організації мають тенденцію відривати команди від клієнтів, як тільки вони починають зростати. Щоб протидіяти цьому, клієнтів регулярно запрошують на зустрічі з командою, щоб, наприклад, надати зворотній зв'язок.
- Постійне вдосконалення на шляху до досконалості: LeSS - це глибокі зміни для багатьох організацій. Зауважте, що це не означає автоматичного покращення. LeSS дозволяє організації почати ставати кращою –, і з цього моменту потрібно постійно оптимізувати. LeSS - це процес!
- Ощадливе мислення: LeSS підкреслює, перш за все, бачення місця самої події (Gemba), концепцію триступеневого навчання ShuHaRi (Shu = наслідувати, Ha = варіювати, Ri = визначати власні правила) і повага до людей.
- Системне мислення: Всі дії, зміни та вдосконалення завжди повинні бути продумані системно або відповідно до системи, щоб досягти поставлених цілей. Приклад: Якщо я теоретично пропоную фінансові бонуси в одній команді –, що це означає для інших команд (тобто для решти організаційної системи)?
- Теорія черг: Основна ідея полягає в тому, що у світі програмного забезпечення ми створюємо багато невидимих черг (наприклад, документи з вимогами, неперевірене програмне забезпечення) і навряд чи дбаємо про оптимальне управління цими чергами. Наприклад, чи знаєте ви, що коли використання ресурсу збільшується з 50% до 90%, час очікування нових завдань не подвоюється, а збільшується в кілька разів? Тому визначайте ліміти незавершеного виробництва (WIP), уникайте багатозадачності та великих робочих пакетів.
Структури LeSS
LeSS пропонує дві конфігурації: Базовий LeSS за Від двох до восьми команд (від 10 до 50 осіб) та Лесс Величезний за Більше восьми команд (від 50 до 6 000 осіб і більше).
Джерело: Less.works
Рекомендується почати з Basic LeSS, щоб поекспериментувати, отримати досвід і зворотній зв'язок, перш ніж переходити безпосередньо до LeSS Huge. Існує два запропонованих підходи до впровадження LeSS Huge:
- Почніть з однієї області вимог за раз в межах більшого продукту і спочатку зосередьтеся лише на ній.
- Або поступово розширюйте сферу роботи команди, Визначення Готового та Визначення Продукту.
Таким чином, компанія може накопичити командний досвід роботи з LeSS, розширитися в одній продуктовій області, досягти початкового успіху – і таким чином отримати управлінську підтримку перед тим, як масштабувати LeSS по всій компанії.
До речі, невеличке зауваження в контексті гнучкої трансформації: ви хочете переконатися, що ви наразі правильні пріоритети у вашій гнучкості Трансформація?
Тоді пройдіть наш тест на зрілість для вашої гнучкої трансформації –, який займає лише 3 хвилини. Ви навіть отримаєте бенчмарк, заснований на результатах понад трьохсот інших учасників. Натисніть кнопку 🙂
Ролі та планування в LeSS
Базовий LeSS фокусується на команді та найважливіших ролях Scrum:
- Власник продукту Scrum, який відповідає за бачення та напрямок розвитку продукту.
- команди Scrum-розробників, відповідальні за створення та доставку продукту
- Скрам-майстер, який підтримує команду в постійному вдосконаленні.
- Роль менеджера і те, як він/вона підтримує команду в усуненні перешкод або "перешкод" на шляху до безперервного вдосконалення і автономії (розширення до SCRUM).
Huge LeSS доповнює Basic LeSS наступними ролями:
- Величезний регіональний власник продукту LeSS підтримує власників продуктів і має вирішальне значення для зв'язку бізнес-вимог (фінанси тощо) з командами розробників.
- Area Product Owner спеціалізується на завданнях, орієнтованих на клієнта, і виступає в ролі власника продукту для функціональних команд, орієнтованих на продукт.
Більшість автобусів Agile їздять по колу....
...і лікувати поверхневі симптоми. Настав час використовувати психологію – для стійкої зміни мислення.
"Ми виявляємо занадто багато несподіваних проблем і помилок на пізньому етапі!"
Зустрічі в LeSS
У "The Доопрацювання продуктового беклогу (PBR) Зустріч
Зустрічі PBR розширюють планування спринту в усіх фокусних областях за рахунок серії паралельних виконань LeSS-спринту. Постійне проведення цих зустрічей необхідне в кожному спринті, щоб зрозуміти, обговорити і вдосконалити елементи і підготуватися до майбутніх спринтів. Основними видами діяльності на нарадах PBR є
- Створення Epics –, тобто кластеризація великих схожих тем; у нашому прикладі це об'єднання спринтів від команди дизайну та юзабіліті.
- Роз'яснення та відповіді на відкриті питання: всі повинні мати однакове розуміння продукту та ідей клієнта і колег.
- Оцінка розміру користувацької історії, ризиків, залежностей: Квазі виведення та детальне планування окремих тем
У "The Огляд спринту
Еквівалент Scrum: огляд спринту - це зустріч наприкінці спринту для оцінки виконаної роботи по відношенню до мети спринту. Це стосується самого продукту. Прогрес стає видимим і визначаються нові сфери для дій. Це робить прогрес щодо продукту і мети прозорим.
У "The Ретроспектива
Подібно до Scrum: Ретроспектива - це зустріч, яка стосується співпраці в команді. Йдеться про покращення співпраці всередині команди і, таким чином, про покращення процесів та контенту. Йдеться також про взаємодію між окремими розробниками, роботу Скрам-майстра та комунікацію з Власником продукту. Це робить ретроспективу важливою частиною процесу безперервного вдосконалення (CIP).
У масштабному Scrum іноді рекомендують проводити "ретро з ретро", тобто між багатьма командами.
Коефіцієнт майстерності Scrum – для великомасштабного скраму
Скільки команд повинен мати скрам-майстер? Можна стверджувати, що один Скрам-майстер на команду - це найкраще –, хоча це також Недоліки має. Як правило Співвідношення Scrum Master у великих масштабах становить від 1:1 до 1:3 – Скрам-майстер має від однієї до максимум трьох команд.
Коли великомасштабний Scrum LeSS є правильним методом Agile?
Large Scale Scrum можна використовувати, якщо ви вже працюєте з SCRUM і хочете масштабувати Scrum. А також, щоб знайти баланс між самоорганізацією та правилами.
Бас Водде якось сказав, що він і Крейг Ларман вважають, що LeSS - це дуже хороший підхід, оскільки він досягає золотої середини між необхідною кількістю вказівок і мінімальною їх кількістю.
Як і сам Scrum, це лише фреймворк процесу, який команди, що його використовують, можуть розробляти дуже індивідуально та урізноманітнювати. Цей аргумент здається правдоподібним і насправді відрізняє Large Scale Scrum (LeSS) від деяких інших фреймворків масштабування.
Ілюстрація: Sweet Spot
Порівняння: великомасштабний скрам проти скраму
LeSS базується на Scrum, щоб підтримувати його використання в ширшому контексті та масштабувати його в більших організаціях і за межами однієї команди. Тож тут немає питання "або" чи "або". LeSS є розширенням SCRUM. Тому, щоб впровадити LeSS, вам завжди потрібен SCRUM. Має сенс спочатку впровадити SCRUM, а потім перейти на LeSS.
Порівняння: великомасштабний Scrum проти масштабованого Agile Framework SAFe®.
Хоча LeSS стає все більш популярним у компаніях з великими командами розробників програмного забезпечення, інші масштабовані гнучкі фреймворки, такі як Scrum of Scrums або Scrum @ Scale, також набувають все більшого значення. Одним з провідних фреймворків є Масштабована Agile Framework® (SAFe).
Між великомасштабним Scrum та масштабованим Agile Framework SAFe® є багато спільного. Наприклад, обидва починаються з масштабування Scrum-команди та впровадження таких принципів, як ощадливе мислення, безперервне вдосконалення та клієнтоорієнтованість.
3 Основні відмінності між великомасштабним Scrum та масштабованим Agile Framework SAFe®.
- Організація: LeSS фокусується на спрощенні організаційної структури, залишаючись гнучкою та адаптивною.
- Ролі: SAFe має додаткові ролі (дехто каже, що з цієї причини вони є більш "накладними"), включаючи інженера з випуску поїздів (RTE), інженера з вирішення поїздів (STE) та власників епізодів.
- Реалізація: Масштабована Agile фреймворк SAFe® містить процеси, артефакти та організаційні зміни, які деякі організації можуть бути не в змозі прийняти. Тому ви завжди повинні дивитися на те, який фреймворк підходить вам і вашій організації.
Для успішного впровадження великомасштабного скраму
Успішне впровадження великомасштабного Scrum вимагає розриву з перевіреними часом припущеннями і зміни корпоративної структури – з усім вибухонебезпечним потенціалом на "рівні босів" і "втратою обличчя", яку тягне за собою відповідна зміна.
Тому основою є те, що всі заявляють про свою готовність до цієї зміни – див. також Модель управління змінами за Коттером або нашу статтю про Дорожня карта трансформації Agile.
Створіть привабливе бачення для роботи в напрямку – і запустіть багато проектів змін одночасно, в дусі експерименту.
Коли початкова мета досягнута, зміни завершуються, і організація пристосовується до нового статус-кво, поки наступна зміна не стане неминучою.
Цей класичний підхід подібний до послідовного та "Підхід великих партій (див. Малюнок) розробки програмного забезпечення, де зміни є винятком, суворо керованим органами контролю.
При впровадженні LeSS немає ініціативи змін, тому немає менеджерів змін. У LeSS зміни відбуваються безперервно через експерименти та вдосконалення – зміна - це статус-кво.
Які кроки для успішного впровадження?
1. зміна, адаптація або зміна командної культури
Ми рекомендуємо починати зі Scrum-команди, доки команда та організація не набудуть достатнього досвіду в новій гнучкій культурі, а відповідальні особи, які приймають рішення, не ініціюють наступний крок. Це також зменшує ризик хибного розвитку.
2. покращення співпраці всередині команд
Масштабована робота кількох команд над одним продуктом вимагає впровадження гнучких практик. Особливо важливими є практики, які полегшують командам координацію між собою. Першим командам все ще доводиться багато експериментувати, оскільки вони є першопрохідцями для решти організації.
Якщо команди дійсно відокремлені від решти організації, вони можуть досягати в ній відповідно швидкого прогресу. Це можна зробити швидше і з меншим ризиком в рамках керованої структури.
3. зміни в корпоративній структурі
Подальше зростання гнучкої організації означає реструктуризацію на всіх рівнях. Найпізніше зараз ініціатор змін повинен залучити керівництво. Всі рівні від команд до вищого керівництва піддаються –, і організаційна структура стає дуже стрункою. Це, мабуть, найбільш "болюча" частина процесу, особливо для керівництва.
4. зміна корпоративної культури
Застосовуючи фреймворки Scrum і LeSS та відповідні гнучкі практики в усіх сферах діяльності підприємства, можна досягти загальноорганізаційного навчання гнучкій культурі. Процес ніколи не зупиняється, оскільки не існує оптимальної гнучкої організації.
Перехід на Agile за допомогою Scrum, LeSS і LeSS Huge вимагає далекоглядної стратегії. Тому він повинен супроводжуватися відповідними порадами та навчанням.
Якщо ви все ще шукаєте відповідну ретро-дошку, наша стаття може допомогти вам з цією темою: Найкращі ретро-дошки в порівнянні.
