Переклад оригінальної статті 2016 року.
Бас Водде — коуч, консультант, програміст, тренер та автор публікацій на тему agile- та lean-підходу до розробки програмних продуктів. Народився в Голландії, а зараз мешкає в Сінгапурі. Бас веде блог, де можна дізнатися багато про нього. Також в його блозі. можна дізнатися про його погляди на agile-розробку програмного забезпечення.
Спочатку були експерименти, емпірика та накопичення досвіду. Далі з'явилися структура, стандарти та налаштування системи. Фреймворк LeSS виріс на родючому ґрунті практичних прикладів від гуру масштабування Баса Водде та Крейга Лармана.
Більшість фреймворків для масштабування використовують підхід кількох скрам-команд. Ключове питання, яке вони задають: "Як зробити так, щоб кілька Agile/Scrum-команд працювали разом?" LeSS вибирає підхід багатокомандного скраму. Питання на початку масштабування, яке задають при використанні LeSS, наступне: "Як застосовувати Scrum, коли у нас багато команд?" У результаті ухвалюються зовсім інші рішення про спосіб масштабування.
Між налаштуванням складного процесу під свої потреби (tailoring down) та масштабуванням є важлива різниця. Традиційний безпечний підхід до процесів - сформувати їх занадто багато, а потім попросити співробітників забрати зайве, тобто звузити до свого процесу. З іншого боку, agile-підхід полягає у масштабуванні та формулюванні мінімальної кількості процесів, причому співробітники можуть додавати нові, тільки якщо вони абсолютно необхідні.
Чому налаштування шкідливе? Більшість таких рішень приймається на початку проєкту. У цей момент обсяг глибоких знань про продукт, ринок чи методологію дуже невеликий, і люди схильні приймати безпечні рішення, щоб зберегти більше ролей, процесів та артефактів, ніж їм насправді потрібно.
LeSS уникає ослаблення цінностей та принципів Agile під час масштабування, працюючи з більшою комплексністю та традиційними організаціями. Ми все одно хочемо виробляти доступні для видачі частини продукту під час кожної ітерації. Ми все ще хочемо мати можливість змінити напрямок у будь-який час. Нам потрібне особисте спілкування та тісне співробітництво з клієнтами. Ми хочемо, щоб у нас були сильні команди, які можуть самоорганізуватися, щоб у нас розвивалася архітектура і дизайн. Деякі фреймворки для масштабування належать до цінностей та принципів Agile, як до чогось невартого, а інші — навпаки. LeSS відноситься до других.
LeSS існує вже давно. Правила, рекомендації та сама назва - нові, але засновані на більш ніж 10 роках експериментів з великомасштабною agile-розробкою в різних компаніях, які виробляють широкий асортимент продуктів.
«Спочатку ми не хотіли створювати фреймворк, – зізнається Бас Водде. – Можливо, це прозвучить дивно, але нам із Крейгом подобається працювати з організаціями та командами над практичними проблемами. Ми обидва віримо в емпірику, або емпіричний контроль процесу, коли команди використовують власні способи роботи, експериментують, навчаються та стають кращими. Тому сама ідея процесу чи навіть фреймворку завжди здавалася протилежною до того, що ми хотіли робити, а саме зосередитися на експериментах, які працюють у певному контексті».
Відповідно, LeSS ніхто спеціально не розробляв, але він розвивався сам собою. Лише у 2014 році партнери Бас Водде та Крейг Ларман почали використовувати термін LeSS та створили правила фреймворку LeSS. До того LeSS був лише добіркою висновків із задокументованих експериментів – того, до чого вони вдавалися, працюючи з багатьма масштабними групами розробників. Так вони навчилися акцентувати увагу на підвищенні прозорості, зменшенні витрат на організацію та більшій значущості роботи та контролю над нею всередині команд.
Значну частину цих висновків можна знайти у книгах Scaling Lean & Product Development (2008) та Practices for Scaling Lean & Agile Development (2010). Але проаналізувавши відгуки на свої книги, Водде та Ларман зрозуміли, що їм необхідно звертатися і до читачів, які тільки прийшли до Agile та масштабування та запитували про зрозумілі відправні точки. У процесі написання наступної книги Large-Scale Scrum: More with LeSS, яку вони вже скоро випустять, їм довелося вирішити конфлікт між наданням більшої кількості правил та розпоряджень і повною передачею контролю над процесом командам, щоб вони могли експериментувати, вчитися і ставати краще у власному контексті; автори описали цей конфлікт як "контроль процесу над процесом" або "контроль команди над власним процесом".
«Коли видаєш командам багато процесів і рекомендацій, вони будуть виконувати їх без розуміння початкових цілей, не думаючи, і згодом така робота стане марною… або навіть шкідливою, — каже Бас Водде. - І тут ми усвідомили, що Scrum вирішує цю суперечність, оскільки складається з невеликої кількості правил. Проаналізувавши їх, розумієш, що більшість стосуються створення зворотного зв'язку та забезпечення прозорості. Так команди можуть краще контролювати роботу. Наш конфлікт було вирішено!»
Правила LeSS, що підвищують прозорість та підсилюють контроль у необхідному масштабі, розмістилися на трьох сторінках. «Ці правила легко зрозуміти, але складно запровадити, – каже Бас Водде. – Вони також часто є руйнівними для організацій».
Загалом LeSS складається з чотирьох частин:
Першими з'явилися експерименти, оскільки саме склад розуму, що заохочує до експериментів, інспекцій, адаптацій та постійного покращення, є основою LeSS. Правила описують два фреймворки: базовий LeSS (2-8 команд) та LeSS Huge (8+ команд). Рекомендації також пояснюють, як застосовувати правила у різних типах організацій.
Перша частина LeSS складається із 10 принципів, але вони з'явилися останніми. Нині ці принципи поділяються на три типи. Перший - принципи на основі Scrum, такі як "прозорість", "емпіричний контроль процесів" або "LeSS - це Скрам". Другий тип - це вже скоріше не принципи, а розділи знань, такі як "ощадливе мислення" та "системне мислення". Останній тип - принципи, які стосуються лише LeSS, наприклад "орієнтація на клієнта", "акцент на цілісному продукті" і "більше з LeSS".
«Базові правила LeSS пояснюють, як застосовувати Scrum до кількох команд, описуючи, як масштабуються ролі, події та артефакти, – каже Бас Водде. — LeSS, на відміну від Scrum, також застосовує правила для організаційної структури. Ми з Крейгом дуже багато разів переконувалися, що якщо організаційна структура залишається недоторканою, то ухвалення Scrum/LeSS буде поверхневим чи не відбудеться взагалі. Тому ми додали кілька структурних правил: спеціально виділені команди, які працюють на одній локації; більшість команд елементів та скрам-майстри на повну ставку».
На думку Баса Водде, сила LeSS у мінімалістичному підході до фреймворку для масштабування. Він не додає непотрібних складнощів і залишається невеликим, якомога найбільш гнучким і ощадливим.
«Ми часто говоримо, що LeSS потрібний для масштабування розробки та демасштабування організації. Звучить, як суперечність, але насправді це не так. LeSS значно збільшує відповідальність команди, внаслідок чого утворюються менш традиційні ролі, процеси та артефакти. Тому й організаційні структури стають простішими».
Вся принадність організаційного демасштабування в тому, що вона призводить до спрощення – менше ролей, артефактів та процесів.
«Ми отримуємо більшу відповідальність команд, більш залучену та ефективну роботу, більше контролю, захопленості справою та покращень, – стверджує Бас Водде. - Більше результатів. Тому принцип так і називається - більше з LeSS!
Недавно мы решили, что пришло время делать крутой и эксклюзивный контент. Поэтому в декабре мы запустили Agile Friday - видеопередачу, в которой Евгений Лабунский, управляющий партнер Scrum Ukraine, будет общаться с крутыми экспертами в сфере Agile на самые горячие темы. В них мы будем говорить …
Large Scaled Scrum (LeSS), как и Scrum, не предписывает вам практически ничего. Это легкий каркас, который позволяет вам добавить в него только то, что вам нужно.
В LeSS все, что вы добавляете от себя, называется экспериментом. Лично мне очень нравится такое название, потому что, как и любой …
Сегодня вышел новый выпуск Agile Friday от Scrum Ukraine, в которой мы поговорим на тему роли Scrum Master в enterprise.
