Scrum. Навчись робити вдвічі більше за менший час. Джефф Сазерленд
компаній виступають у ролі лідерів-слуг та посередників, зосереджених на прибиранні перешкод зі шляху їхніх команд, а не на вказівках, котрий продукт розробляти і як. Японські викладачі порівнювали робочий процес із грою в регбі й казали, що найкращі команди діють так, немов гуртуються задля досягнення спільної мети, що й називається Scrum: «…м’яч пасується всередині команди, яка рухається полем як єдине ціле»[6].
Коли стаття Такеучі та Нонаки тільки вийшла, вона наробила галасу, але то було за сім років до того, як ми прочитали її в Easel. Усі нею захоплювались, але ніхто нічого із цим не робив. Пересічний американський менеджер був не здатний осмислити її ідеї, навіть попри те, що Toyota швидко збільшувала свою частку ринку, використовуючи цей підхід. В Easel нам не було чого втрачати. Ми вирішили спробувати, хоча стаття й описувала більше виробничу сферу, а не розробку програмного забезпечення. Я вважав, що їхні ідеї приведуть до чогось фундаментального, процедури, що описувала б найкращий спосіб співпраці людей у будь-якій сфері діяльності. Адже вони чудово вкладалися в усі інші експерименти, які я проводив іще з моєї першої роботи у приватному секторі в MidContinent.
Це стало офіційним народженням Scrum. Ми здали готовий продукт вчасно, ще до закінчення шести місяців, не перевищивши бюджет і з меншою кількістю помилок, ніж у будь-якому попередньому замовленні.
Можливості цієї нової форми управління проектами так мене надихнули, що вся моя майбутня робота зосередилась на вдосконаленні Scrum для компаній. У 1995 році разом із Кеном Швабером я презентував на дослідницькій конференції Асоціації обчислювальної техніки працю під назвою «Спосіб розробки SCRUM», яка систематизувала ці практики. Після того ми відмовилися від слів великими літерами та дещо допрацювали цю ідею, але основні принципи залишаються незмінними; а компанії, які прийняли цей спосіб, зазвичай отримують негайні переваги[7].
Перевіряйте та адаптуйте
У системі Scrum команди, які добре працюють, здатні досягти того, що ми називаємо гіперпродуктивністю. Важко повірити, але серед груп, які добре впроваджують Scrum, ми регулярно бачимо десь так від 300 до 400 відсотків покращення продуктивності. Найкращі команди можуть досягти підвищення продуктивності аж до 800 відсотків, а потім повторювати цей успіх знову й знову. Крім того, в результаті використання цієї системи подвоюється якість їхньої роботи.
То як створити в Scrum-команді автономію, прагнення перевершити самих себе, взаємозаохочення – а потім досягти гіперпродуктивності за рахунок поєднання всього цього? Мова про це піде в решті розділів цієї книжки, але базові принципи я збираюся подати вам тут. У скороченій формі їх можна також побачити в додатку.
Оскільки Scrum бере початок із технік, використовуваних у японському виробництві, не завадить трохи дізнатися, звідки їх узяли японці. За іронією долі, вони багато чого навчилися в одного американця – Вільяма Едвардса Демінга. Під час американської окупації
Takeuchi, Hirotaka, and Ikujiro Nonaka. «The New New Product Development Game.» Harvard Business Review (січень— лютий 1986 р.): 285–305.
Schwaber, Ken. «Scrum Development Process,» у збірці OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, eds. (London: Springer, 1997).