Кілька тижнів ми з командою витратили на читання сотень документів, книжок та статей з організації команд і розробки продукту. А потім один розробник якось приніс статтю з Harvard Business Review від 1986 року, написану двома японськими викладачами економіки Гіротакою Такеучі та Ікуджиро Нонакою. Вона називалася «Розробка нового продукту. Нові правила гри». Такеучі та Нонака вивчали команди кількох найбільш продуктивних та інноваційних компаній світу: Honda, Fuji-Xerox, 3M, Hewlett-Packard та інших. Вони стверджували, що старий спосіб розробки продукту, заданий фазовою системою планування програм NASA, – каскадна модель – дефектний у своїй основі. Натомість найкращі компанії використовують ступеневий процес розробки, який є швидшим та гнучкішим. Ці команди мають різнопрофільних фахівців, автономію та взаємопідтримку. При цьому вони ставлять перед собою мету вийти за межі досягнутого раніше. Вони прагнуть чогось більшого за самих себе. Менеджмент не диктує їм, що робити. Навпаки, керівники компаній виступають у ролі лідерів-слуг та посередників, зосереджених на прибиранні перешкод зі шляху їхніх команд, а не на вказівках, котрий продукт розробляти і як. Японські викладачі порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum: «…м’яч пасується всередині команди, яка рухається полем як єдине ціле»[6].

Коли стаття Такеучі та Нонаки тільки вийшла, вона наробила галасу, але то було за сім років до того, як ми прочитали її в Easel. Усі нею захоплювались, але ніхто нічого із цим не робив. Пересічний американський менеджер був не здатний осмислити її ідеї, навіть попри те, що Toyota швидко збільшувала свою частку ринку, використовуючи цей підхід. В Easel нам не було чого втрачати. Ми вирішили спробувати, хоча стаття й описувала більше виробничу сферу, а не розробку програмного забезпечення. Я вважав, що їхні ідеї приведуть до чогось фундаментального, процедури, що описувала б найкращий спосіб співпраці людей у будь-якій сфері діяльності. Адже вони чудово вкладалися в усі інші експерименти, які я проводив іще з моєї першої роботи у приватному секторі в MidContinent.

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

Можливості цієї нової форми управління проектами так мене надихнули, що вся моя майбутня робота зосередилась на вдосконаленні Scrum для компаній. У 1995 році разом із Кеном Швабером я презентував на дослідницькій конференції Асоціації обчислювальної техніки працю під назвою «Спосіб розробки SCRUM», яка систематизувала ці практики. Після того ми відмовилися від слів великими літерами та дещо допрацювали цю ідею, але основні принципи залишаються незмінними; а компанії, які прийняли цей спосіб, зазвичай отримують негайні переваги[7].

У системі Scrum команди, які добре працюють, здатні досягти того, що ми називаємо гіперпродуктивністю. Важко повірити, але серед груп, які добре впроваджують Scrum, ми регулярно бачимо десь так від 300 до 400 відсотків покращення продуктивності. Найкращі команди можуть досягти підвищення продуктивності аж до 800 відсотків, а потім повторювати цей успіх знову й знову. Крім того, в результаті використання цієї системи подвоюється якість їхньої роботи.

То як створити в Scrum-команді автономію, прагнення перевершити самих себе, взаємозаохочення – а потім досягти гіперпродуктивності за рахунок поєднання всього цього? Мова про це піде в решті розділів цієї книжки, але базові принципи я збираюся подати вам тут. У скороченій формі їх можна також побачити в додатку.

Оскільки Scrum бере початок із технік, використовуваних у японському виробництві, не завадить трохи дізнатися, звідки їх узяли японці. За іронією долі, вони багато чого навчилися в одного американця – Вільяма Едвардса Демінга. Під час американської окупації Японії після Другої світової війни Демінг працював на генерала Дуґласа Мак-Артура. Підхід Мак-Артура до відновлення економіки полягав у тому, щоб звільнити більшу частину вищого керівництва японських компаній, підвищити керівників середньої ланки та залучити до ділових операцій експертів зі Сполучених Штатів, таких як Демінг. Вплив Демінга на японське виробництво був надзвичайним. Він навчив сотні інженерів того, що називається «статистичним контролем процесів». Основною ідеєю було точне вимірювання зробленого та його якості, а також прагнення до безперервного покращення. Не просто разового покращення, а постійного. Слід завжди шукати, що можна покращити, і ніколи не зупинятися на досягнутому. Для цього потрібно постійно проводити експерименти, які вказуватимуть на можливість досягти кращих результатів. Якщо спробувати цей метод, чи не буде він кращим за старий? Як щодо іншого? Що як змінити один цей момент?

Відомий виступ Демінга перед керівниками японських підприємств у 1950 році. Серед слухачів були й такі люди, як Акіо Моріта, засновник компанії Sony. Демінг тоді сказав їм:

Найбільше Демінг відомий якраз своїм методом дій – циклом ПРПД (Планувати, Робити, Перевіряти, Діяти). Цей цикл можна застосувати до виробництва практично всього: автомобіля, відеогри чи навіть паперового літачка.

Коли я навчаю когось застосовувати Scrum, то використовую саме їх – паперові літачки. Я поділяю людей на команди й ставлю перед ними завдання зробити якомога більше паперових літачків, які літатимуть кімнатою. У команді буде три категорії людей. Одна людина перевірятиме, скільки зроблено літачків, які дійсно можуть літати. Друга буде частиною виробничого процесу разом з усіма, але також звертатиме увагу на сам процес та шукатиме способи покращення якості літачків і прискорення їх виробництва. Усі інші концентруватимуться на виготовленні якомога більшої кількості літачків, дійсно здатних пролетіти задану відстань за відведений на це час.

Потім я кажу, що ми маємо виконати три шестихвилинні цикли виробництва паперових літачків. Одну хвилину кожного циклу команди мають Планувати, як вони збираються робити літачки, три хвилин – Робити (виготовляти й тестувати якомога більше літачків, дійсно здатних літати). І нарешті, дві хвилини вони мають Перевіряти. На цьому етапі команда дивиться, як можна покращити процес виготовлення їхніх паперових літачків. Що пішло правильно? Що – неправильно? Чи не слід змінити дизайн? Як можна покращити процес виготовлення? А потім вони Діятимуть. У системі Демінга «діяти» означає змінювати ваш спосіб роботи на основі реальних результатів і реального впливу зовнішніх умов. Та сама стратегія використовувалась і в роботах Брукса.

Пройдіть цей цикл тричі, і, хоч що ви виробляєте – паперові літачки чи справжні космічні кораблі, – ви станете кращими, значно кращими (прискорившись у два-три рази і щонайменше подвоївши якість). Саме завдяки цьому циклу Демінга – радикальній ідеї на той час, коли її презентували японцям, – компанія Toyota і стала автовиробником номер один у світі. Саме так працює будь-який різновид «ощадливого» виробництва (американський термін для використання концепцій виробничої системи Toyota) або розробка продукту в Scrum.