Це переклад статті Craig Larman — the co-creator of LeSS (Large-Scale Scrum), Certified LeSS Trainer. Оригінал статті «Succeeding with Large-Scale Development — More with LeSS» розміщено на вебсайті SolutionsIQ за цим посиланням.
Дякую, що знайшли час прочитати (і подивитися) це введення в LeSS (Великомасштабний скрам)!
Якщо для знайомства з різними аспектами LeSS ви надаєте перевагу відео, ніж тексту, будь ласка, подивіться ці відео на LeSS website less.works. З цього списку корисно розпочати перегляд відео Introduction to LeSS (short video) – Craig Larman.
Історія створення
Звідки взявся LeSS? У 2002 році я написав книгу Agile & Iterative Development: A Manager’s Guide. / «Гнучка та ітеративна розробка: керівництво для менеджера».На той час багато людей «знали», що гнучку розробку масштабувати неможливо. Але мій досвід у компанії Valtech (займалася аутсорсинговою розробкою), показує протилежне. Нам вдалося помітити, що це можливо.
Я почав одержувати від клієнтів прохання застосовувати аджайл-концепції, особливо фреймворк Scrum для великомасштабної розробки, оскільки я був одним із перших інструкторів зі скрам, починаючи з кінця 1990-х, й одним із перших Certified Scrum Trainer (Сертифікованих Тренерів Скраму). Зрештою, це призвело до співпраці з такими групами: Ericsson, UBS, Bank of America Merrill-Lynch, JP Morgan та Nokia Networks та багатьма іншими. (До речі, Nokia Networks — це група телекомунікаційної інфраструктури, а не група мобільних пристроїв Nokia, яку, зрештою, купила Microsoft.)
Ви можете дізнатися більше про деякі враження клієнтів на сайті тематичних досліджень LeSS case studies site.
Головне, за що варто цінувати LeSS — він не був створений «на папері» або в теорії. Він став результатом нашого досвіду роботи з багатьма клієнтами з 2005 року, котрі займалися застосуванням великомасштабного скраму.
Тим часом на початку 2005 року, у Nokia Networks було дуже приємно зустрітися й почати працювати з моїм другом, Басом Водді / Bas Vodde, співавтором LeSS. Бас відіграв ключову роль, допомагаючи групам з прийняттям великомасштабного скраму в Nokia Networks у складі їхньої внутрішньої команди «Гнучка компанія», а також був членом великої лідерської групи (приблизно 1000 осіб) розподіленої продуктової групи, яка почала використовувати LeSS. Отже, Бас мав величезну кількість багаторічного досвіду використання та застосування великомасштабної гнучкої розробки: від налагодження великих організацій до практичної розробки вбудованих систем. Він не був кабінетним педагогом або тим, хто просто провів кілька днів на зборах керівництва, обговорюючи масштабування. Багато років він займався всім цим на передовій. Він має глибинні знання системного мислення, сучасних принципів менеджменту, а також в Agile і Lean-системах, включно зі скрам (оскільки він також є одним із перших сертифікованих тренерів зі скраму).
Бас був і залишається для мене чудовим партнером з коучингу та консалтингу з масштабування гнучкої розробки, і я багато чого в нього навчився. З іншого боку, ми обидва багато чого навчилися в наших клієнтів, які переходили на LeSS за ці роки. У такий спосіб, ми стали партнерами в коучингу та комунікаціях з LeSS, починаючи з нашої першої книги на цю тему, яку ми написали у 2007 році, базуючись на нашому досвіді роботи з клієнтами, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum / «Масштабування Lean та Agile Розробки: Мислення та Організаційні інструменти для великомасштабного скраму». Потім у 2009 році в друк пішов другий том про LeSS, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum / «Практики масштабування Lean та Agile розробки: великомасштабна, розподілена та офшорна розробка продуктів у великомасштабному скрамі».
Зараз ми завершуємо нашу третю книгу-підручник, яка допоможе людям успішно розпочати роботу Large-Scale Scrum: More with LeSS / «Великомасштабний скрам: досягти більшого з LeSS».
LeSS означає менше
Якби мені довелося по-справжньому коротко описувати LeSS, я сказав би одне: «LeSS відносно невеликий і простий». У мене є досвід консультування та коучингу в 1990-х роках за RUP (Раціональний Уніфікований Процес). Один із ключових висновків, які я зробив із цього досвіду, полягає в тому, що фреймворки, які рясніють визначеннями й «прописаністю» (безліч корисних порад), насправді не працюють із погляду великомасштабного прийняття. Вони недостатньо контекстуальні. Вони перешкоджають емпіричному контролю процесу (ключовий принцип скраму), унікальному навчанню та дослідженню, які обов’язково мають відбуватися. Групи розробників (і робота з розробки) дуже різноманітні для чогось на кшталт деталізованої чітко визначеної структури чи процесу чи багато в чому стандартного рецепта. Тепер РУП спробував протистояти цій проблемі, запропонувавши «адаптувати» чи видалити елементи, щоби нібито спростити це. Теоретично звучить добре, але в реальному світі я бачив, що це просто не працює. У результаті групи «перейняли» занадто багато ролей, структур, процесів і методів, ставши надмірно «визначеними» і складними. Хоча їм і порадили «брати серед цього буфету з опціями лише те, що вам, справді, потрібно». У цих групах співробітники відштовхувалися від припущення, що вони могли б делегувати повноваження або уникнути вивчення, виявлення та усунення своїх системних слабкостей, оскільки «ці проблеми вирішуються через ухвалення фреймворку, який ми купили».
Але ось про що ми довідалися: більш визначений процес веде до меншого навчання, і, навпаки, менш певний процес веде до більшого навчання.
… Але LeSS — це не мінімалізм: Зона Золотовласки для груп Шу
Отже, логічний висновок з висліву «менш визначений процес веде до більшого навчання» полягає в тому, щоби прийняти ніяк не визначений процес або фреймворк, або, як варіант, прийняти систему з лише кількома простими принципами. Наприклад, існують «системи», такі, як рух the Learning Organization, який рекомендує системне мислення, врівноваженість, ментальні моделі, загальне бачення та командне навчання. Хто може з цим посперечатися? Це ж чудові принципи!
Але… проведіть такий експеримент. Сходіть в продуктову групу телекомунікаційної інфраструктури, що складається з 500 осіб, розміщених на 5 об’єктах, яка десятиліттями слідує дуже традиційній організаційній структурі та культурі так, що стара система дійсно вбудована в мізки співробітників. Або в банк. І скажіть їм: «Привіт, хлопці, займіться тепер системним мисленням, врівноваженістю, ментальними моделями, загальним баченням і командним навчанням!»
Нічого на ділі не змінюється.
І це друга річ, яку ми дізналися за десятиліття участі в ініціативах щодо впровадження змін: для групи, яка перебуває на початковій стадії прийняття великої зміни, потрібна певна критична маса конкретних порад щодо структури, політики, процесів, ролей тощо, щоби дійсно щось зробити для такої зміни. Інакше, якщо це група «стадії Шу» (стадія навчання новачків основам бойового мистецтва - прим.) із сильними традиційними елементами, то вони або дійсно нічого не змінюють або через потужні сили протидії з боку статусу-кво, ці зміни стають «підробкою», щоби зовні якось відповідати ідеї. Але якщо докопатися до суті, це виявиться все тією ж старою системою. Між іншим, така фальсифікація здійснюється за допомогою переосмислення або перевантаження нової термінології, щоби вона здебільшого означала те саме, що й цей статус-кво.
Отже, існує зона Златовласки (зона біля зірок, яка придатна для життя — прим.) для сучасного фреймворку розробки в організації на стадії Шу: між «лише кількома простими принципами» й «безліччю ролей, структур, технік і процесів».
Ми спостерігаємо (і багато інших помітили це), що звичайний однокомандний скрам переважно і розташований в такій зоні для невеликої продуктової групи. Його прості конкретні елементи дають достатньо визначення, щоби реалізувати глибші принципи: емпіричний контроль процесу з прозорістю, самоорганізацією тощо.
Так само LeSS (великомасштабний скрам) використовує ту ж тему: просто достатньо конкретних елементів для організації на стадії Шу, щоби здійснити реальні зміни та знати, що робити для початку роботи; щоби залучити глибші принципи емпіричного контролю процесу з прозорістю й самоорганізацією. Але цього навряд чи вистачить. У LeSS є величезний простір для унікального ситуативного навчання та адаптації, який необхідний для незліченної кількості унікальних організацій.
LeSS фокусується на першопричинах у структурі організації.
Крім того, коротко описуючи LeSS, я б сказав: «LeSS фокусується на докорінних причинах організаційних слабкостей при масштабуванні». Багато експертів з організаційної структури знають, що основними причинами проблем є (1) наявне статус-кво організаційних структур та ролей та (2) командно-адміністративні політики, які заперечують реальність невід’ємної мінливості та людської мотивації в роботі з розробки. Але так само, багато експертів або консультантів ходять навшпиньки навколо цих питань і уникають їх порушувати, оскільки це може поставити під сумнів наявні структури влади й переконань. Це ще одна причина, через яку такі «фальшиві зміни» трапляються. Інакше кажучи, вони допустимі лише до того ступеня, доки не кидають виклик чи не порушують ролей статусу-кво, структури влади й політики…. «Ви, програмісти, приймайте, звісно, всю цю штуку зі скрамом. Робіть усе, що бажаєте, для більшої продуктивності. Але переконайтеся, щоб усе це було зроблено до встановленої вами дати поставки! А менеджери проєктів будуть вимірювати ваші показники, щоби переконатися, що ви йдете правильним шляхом».
Зазвичай, будь-яка «зміна», внесена до такої організації, буде просто поверхневим шаром нової термінології та технік у незмінній за своєю суттю системі...
РАНІШЕ, ТРАДИЦІЙНО: UX-аналітики пишуть остаточну версію Experience, щоби передати її іншим. Команда бізнес-аналітиків описують use cases та передають їх програмістам, архітектори визначають UML PowerPoints і передають свої проєкти програмістам, програмісти пишуть код для тестування групою тестування, після його інтеграції за допомогою менеджера інтеграції тощо.
ПІСЛЯ, 'АДЖАЙЛ': Аджайл-UXи пишуть Історії Досвіду, щоб інші могли їх прочитати, Аджайл-БА-команди пишуть user stories для передачі програмістам, аджайл-архітектори визначають Епіки Архітектури й передають свої проєкти програмістам, програмісти пишуть інтеграції та тестування тощо.
Справді, що змінилося?
Однак, хороші новини полягають у тому, що LeSS не оминає ці ключові проблеми: він безпосередньо усуває першопричину проблем організаційної структури, що лежать в основі системної слабкості під час масштабування: безліч однофункціональних команд передають результати незавершеної роботи іншим командам, Контрактна гра, командно-адміністративний менеджмент, укорінені позиції статус-кво тощо.
Успіх із LeSS
Зазвичай розуміння LeSS та його прийняття — це щось більше, ніж те, що вдалося розглянути в цій короткій статті. Прекрасний спосіб розпочати роботу — це курс Certified LeSS for Executives або Certified LeSS Practitioner (див. списки курсів course listings), читання та перегляд відео на сайті less.works, робота з коучем, що має практичний досвід роботи з LeSS та читання трьох книг з LeSS. LeSS простий, але ефективний, і ми хочемо допомогти вам досягти успіху з його застосуванням.
Comments