Scrum. Навчись робити вдвічі більше за менший час

Розділ 2. Витоки Scrum

Для американських військових пілотів у В’єтнамі період проходження служби означав виконання ста польотних завдань над ворожою територією. При цьому п’ятдесят відсотків пілотів були збиті. Декого вдавалося врятувати, але більшість збитих уже ніколи не поверталися. У 1967 році, будучи ще молодим, недосвідченим винищувачем, я прибув із військово-повітряної бази Маунтін-Хоум в Айдахо на базу королівських ВПС Удон у північному Таїланді для виконання найнебезпечнішої роботи в авіації США – розвідки.

Це було задовго до нинішньої ери дронів та достовірних супутникових даних. Мій літак RF-4C Phantom був споряджений усіма видами зброї, обладнаний камерами та додатковим паливним баком. Моєю роботою були польоти над ворожою територією, щоб штурман міг зняти фото до та після нашого бомбардування. Більшість завдань виконувалися вночі, і я летів крізь тропічну пітьму приблизно в сотні метрів над землею, ледь не причісуючи верхівки дерев. У момент перетину кордону з Північним В’єтнамом дисплей у моєму шоломі час від часу спалахував, наче автомат для гри в пінбол, після чого з гучним писком та свистом активувалася система попередження про ракетну атаку. Небо світилося від трасерів зеніток, і я розумів, що через кілька хвилин мій літак засіче ракетний радар, хіба тільки 150 метрів – це достатньо низько, щоб від нього сховатись.

У такі хвилини рівень адреналіну в моїй крові мав би зашкалювати, але я не втрачав голови. Навпаки, небезпека мене майже заспокоювала. Цим я завдячую тренуванням з контролю ризиків, які отримав від ВПС. Ті тренування навчили мене робити чотири речі: Оглядати, Орієнтуватись, Вирішувати й Діяти. Зокрема, я мав спостерігати за об’єктом розвідки, визначати найкращий шлях у гарячу зону й назад, орієнтуватись у разі неочікуваних подій, а потім рішуче діяти на основі інстинктів та засвоєних навичок. Зволікання може вбити пілота, як і безрозсудна хоробрість. Як тільки мій штурман робив потрібні фото, я тягнув важіль на себе та виривався з-під обстрілу, хоча через перевантаження майже нічого не бачив. Від тих перевантажень штурман теж часто відключався, а в деяких випадках і втрачав контроль над своїм кишечником. Але він не скаржився. Бо я завжди доставляв нас назад живими.

Тоді я був просто молодим пілотом реактивного літака, який сподівався пережити свою сотню завдань. Я не знав, що досвід польотів та тренувань, які я пройшов щодо вміння думати та діяти в смертельно небезпечних ситуаціях, сформує спосіб моєї роботи до кінця життя. Я прибув до В’єтнаму в 1967 році з двома ескадрильями винищувачів F-4 та двома розвідниками RF-4C, загалом сотнею літаків. Ми прибули на зміну двом ескадрильям RF-101s. З п’ятдесяти RF-101s протягом одного року були збиті всі, крім чотирьох. А ті, що залишились, мали в корпусі стільки пробоїн, що просто не могли літати. Навіть не знаю, як пілоти взагалі посадили їх після останнього завдання. RF-4C був більш витривалим літаком-винищувачем, але половину наших літаків однаково збили протягом року. Ми покращили показники виживання, але 50 відсотків тих, хто прибув разом зі мною, все одно не повернулися на базу. Лише кількох щасливчиків вдалося врятувати з джунглів, перш ніж їх схопили в’єтнамці.

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

Але перед тим я роками намагався визначити, що відбувається в клітині, від чого вона стає раковою. Я багато дізнався про теорію систем і те, як лише система має певні стабільні стани. У міру свого розвитку клітина переходить з одного стабільного стану в інший. Саме визначенню правил переходу складної адаптивної системи з одного стану в інший та перетворення наступного стану на позитивний замість негативного я й присвятив майже десять наступних років свого життя.

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

За часів адміністрації Рейгана уряд радикально урізав гранти на наукові дослідження, у тому числі й мій грант від Національних центрів дослідження раку, коли я був провідним дослідником збирання та аналізу даних відділення клінічних та епідеміологічних досліджень Центру раку при Університеті Колорадо. Поки я думав, що робити далі, до мене звернулися з компанії під назвою MidContinent Computer Services, де почули, що я є провідним фахівцем у сфері їхніх найновіших розробок. MidContinent займалась обслуговуванням 150 банків у всій Північній Америці. Свій найновіший продукт вони назвали мережею «автоматичних касових апаратів» (банкоматів). Це було в далекому 1983 році, коли отримання готівки зазвичай означало вистоювання довгої черги в банку або під’їзд до спеціального банківського вікна на вашому автомобілі. Ви мали заповнити чек на готівку, вказавши потрібну суму, та передати його касирові.

Нова мережа мала залишити цю незручність у минулому, але на той час у MidContinent ніяк не могли вирішити проблему зв’язку їхніх банкоматів між собою. Їм потрібен був хтось, хто б зайнявся вирішенням цієї проблеми, і вони зробили мені заманливу пропозицію стати віце-президентом із роботи з новими системами. Комп’ютери їхньої мережі нічим не відрізнялися від тих, на яких я роками працював над дисертацією, а тому то була цілком непогана угода.

Принаймні так я собі думав. Ніщо у світі просто не дається, правда? Прийшовши в компанію, я очолив відділ, що користувався каскадною моделлю управління проектами. Там були сотні програмістів, які цілими днями просиджували за своїми столами, вдаючи, що працюють, але нічого не могли виконати вчасно або в межах бюджету. Щодо проекту впровадження мережі банкоматів, то витрати на 30 відсотків перевищили прибутки. Неефективність просто-таки вибивала ґрунт із-під ніг.

Передусім я витратив деякий час, намагаючись визначити, як там усе працює. Можете уявити, як вище керівництво ставилося до моїх хлопців. Там було багато крику, дріб’язкових розпоряджень, пасивно-агресивної поведінки та вимог працювати краще й понаднормово. Але хоч як керівництво тиснуло, проекти все одно хронічно запізнювались, не вкладалися в бюджет і не приносили очікуваного результату.

Я прийшов до думки, що найкращим варіантом для нас є все це змінити. Проблем було надто багато, щоб усувати їх окремо, тому я вирішив створити компанію всередині компанії. Я попросив нашого генерального директора Рона Гарріса дозволити мені сформувати окрему організацію з усіх залучених до проекту створення мережі банкоматів. У нас буде власна команда продажів, власна група маркетингу та власні фінансисти. Рон був блискучим і творчим керівником, який мені довіряв. Мабуть, за керівництва когось іншого це б ніколи не вдалося реалізувати. Почувши про мою ідею, він сказав мені: «Сазерленде, якщо ви хочете взяти на себе цей головний біль, то візьміть».

Я так і зробив. Я пішов до розробників та менеджерів і сказав їм: «Перше, що нам треба, це припинити робити речі, які нас убивають». Це як у тому старому жарті про людину, яка б’ється головою об цегляну стіну лише для того, щоб відчути, як це добре, коли перестане. «Ми маємо визначити кращий спосіб роботи, – сказав я їм, – і почати слід негайно».

І ми створили цілу невеличку компанію у формі єдиної команди, поділеної на групи. При цьому премії базувалися не на індивідуальній продуктивності, а на продуктивності всієї компанії. Ми задіяли концепції та інструменти, які десять років потому знайшли своє місце в Scrum (наприклад: власник продукту, беклог проекту та тижневі спринти), детальніше описані нижче та викладені в додатку. Через шість місяців ми стали найприбутковішим підрозділом у компанії. Прибутки на 30 відсотків перевищили видатки. Наші системи Nonstop Tandem стали першими онлайновими автоматами для транзакцій, яким банки довіряли достатньо, щоб їх використовувати. Ми розгорнули їх по всій Північній Америці. У наші дні, у яку б частину країни ви не поїхали, банкомат знайдеться скрізь. І всі ці машини точно знатимуть, скільки грошей на вашому рахунку. Моя команда добряче над цим попрацювала. Ага, нема за що.

Після моєї першої кар’єри в армії, а другої – в освіті, прийшовши в бізнес, я почувався свого роду аутсайдером. Проте точка зору сторонньої людини якраз і стала одним із найцінніших моїх активів. З першого ж дня для мене стало загадкою, чому люди наполягають на роботі способом, який наперед є неефективним та марнотратним, дегуманізованим і просто гнітючим. Гадаю, вони вважали, що так діють усі, а тому він, мабуть, найкращий.

Мені дійсно подобалося працювати в MidContinent, але я прагнув випробувати свої вміння та навички на нових викликах. Закінчилося це тим, що протягом наступних двох десятиліть я працював на великі й малі компанії на посаді віце-президента з проектування або технічного директора. У кожній з них я намагався досягти більш ефективної спільної роботи команд. Улаштувавшись в одну із цих компаній, я опинився в Кембриджі, штат Массачусетс, усього за кілька кварталів від Массачусетського технологічного інституту (МТІ). Кілька тамтешніх докторів та професорів якраз заснували нову компанію зі створення роботів, і їм стало тісно в їхній лабораторії. Розглянувши різні варіанти, вони орендували офісне приміщення в моєї компанії.

Через кілька тижнів після їхнього переїзду сталася геть неочікувана річ: у мій кабінет забіг шестиногий робот завбільшки з кота, який почав ганятися за мною навколо столу. Розробники відразу забрали його та нервово вибачилися за їхню машину, але кожні кілька днів це повторювалося знову. Один із роботів постійно тікав з лабораторії та починав гасати будівлею. Я весь час чув клацання механічних ніг у коридорах.

У мене тоді була одна традиція. Наприкінці дня в п’ятницю я завжди виставляв у своєму кабінеті вино та пиво, щоб усі члени команди могли розслабитись і неформально поспілкуватися після важкого тижня. На ці посиденьки я запрошував також моїх сусідів робототехніків, і однієї п’ятниці до мене завітав Родні Брукс. Цей викладач штучного інтелекту МТІ був одним із засновників компанії. Я спитав його, як працюють ці бродячі роботи.

«Ми десятками років намагалися створити дійсно розумну машину, – сказав він мені. – Витратили мільярди доларів і багато-багато років праці, збудувавши найбільші комп’ютери, які тільки могли, з найбільшими базами даних, але отримали лише комп’ютер, здатний обіграти людину в шахи».

Він пояснив, що до його роботів застосовується зовсім інакший підхід. Замість спроб побудувати щось із одним-єдиним центральним мозком, вони збудували робота, у якого кожна із шести ніг мала власний мозок. Процесор у спині мав лише кілька простих правил: уперед, назад, не наступати на інші ноги. Чип нейронної мережі в голові робота контролював дотримання цих правил і діяв як рефері для всіх частин. Він повідомляв ногам про те, що бачив крізь свою камеру, коли натикався на перешкоду, – та й усе.

За словами Брукса, цікавим було те, що кожного разу, коли робота вмикали, він учився ходити заново. У нього не було бази даних про розташування інших предметів у кімнаті. Натомість його базою даних був сам світ. Кожного разу після вмикання він визначав розташування інших предметів, немов уперше. Натикався на речі й сприймав їх як реальне оточення, що означало його здатність адаптуватися до будь-якого середовища.

«Давайте я вам покажу», – сказав Брукс, затягнувши мене до їхньої лабораторії. Він сунув чистий нейронний чип в одного комахоподібного робота, і я побачив, як той оживає. Спочатку робот невпевнено заспотикався кімнатою, наче новонароджене теля, яке вперше намагається стати на ноги. З кожним кроком він ставав усе впевненішим. Ноги швидко вчилися співдіяти. Уже через декілька хвилин робот бігав навколо. Його вміння ходити не було ані збереженим, ані запрограмованим. Усі складники працювали разом за рахунок кількох простих функцій. Ці ноги не думали, а просто діяли. Я був надзвичайно вражений геніальністю та простотою цієї системи. Тут було щось, що робило саме те, чого мене вчили робити, коли я літав над В’єтнамом: Оглядати, Орієнтуватись, Вирішувати й Діяти. Цей робот був інтегрований у довкілля й рішуче діяв на основі даних із довкілля.

– А що б сталося, – спитав я Брукса, – якби ми змогли розробити набір простих інструкцій для груп людей працювати разом, точно як оці ноги? Вони б самоорганізувались та самооптимізувались, як і цей робот?

– Не знаю, – відповів він. – Чому б вам не спробувати це й не повідомити мені, що із цього вийшло?

Я дедалі краще розумів: якщо зможу створити систему, яка, подібно до цього робота, координуватиме незалежні центри рішень із постійним відгуком про стан справ, буде досягнуто значно вищих рівнів продуктивності. Розподіляючи потік інформації між «ногами» групи, можна буде досягти ефективності, якої раніше не досягав ще ніхто.

Моя розмова з Родні Бруксом відбулася понад два десятиліття тому. Протягом багатьох років він був завідувачем кафедри робототехніки та штучного інтелекту МТІ, а той схожий на павука робот, якого я бачив, на прізвисько Чингізхан, тепер зберігається в музеї Смітсонівського інституту. Сьогодні ви, мабуть, чули про одну з компаній Брукса iRobot, що виробляє пилосос Roomba та використовує для прибирання ваших кімнат той самий адаптивний інтелект, який Чингізхан використовував, щоб ганятися за мною по кабінету. Його остання новинка в Rethink Robotics, робот Бакстер, може успішно співпрацювати з людьми в спільному робочому просторі.

Праця Брукса мене надихнула. І в 1993 році я приніс ці ідеї із собою в компанію Easel, куди мене запросили на посаду віце-президента з об’єктних технологій. Керівництво Easel хотіло, щоб моя команда за шість місяців розробила абсолютно нову серію продуктів для деяких із їхніх найбільших клієнтів, таких як Ford Motor, які використовували їхнє програмне забезпечення в проектуванні та створенні власних додатків. Я сів порадитись зі своїми розробниками й сказав їм, що, на мою думку, вони не зможуть цього зробити за допомогою старого способу розробки програмного забезпечення.

Тією старою методикою була каскадна модель, яку я вже описував у попередньому розділі: усе, що стосується проекту, ретельно зображувалося на масштабних діаграмах Ґантта, кожне завдання точно оцінювалось у годинах і виділялося симпатичними кольорами, що стікали сторінкою, немов каскад. Ці діаграми здавалися дуже гарними й точними, але були цілковитою нісенітницею.

Я знав, що в Easel каскадна модель викине нас за межі дедлайнів на місяці, якщо не роки. Ми мали розробити зовсім інакший спосіб управління проектами. Я пішов до генерального директора і сказав, що діаграми Ґантта не для нас. Він був шокований і вимагав пояснити чому.

– Скільки діаграм Ґантта ви бачили за свою кар’єру? – спитав я.

– Сотні, – сказав він.

– А скільки з них справдилися?

– Жодної, – відповів він після паузи.

Саме тоді я й пояснив йому, що збираюся презентувати наприкінці місяця робоче програмне забезпечення, а не невиконану діаграму Ґантта. Він зможе випробувати його сам і переконатися, що ми на правильному шляху. Ми маємо спробувати це, якщо хочемо вкластись у відведені строки.

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

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

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

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

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

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

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

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

…хоч які чудові у вас технічні фахівці, саме ви, лідери, повинні прагнути успіхів у покращенні якості та однорідності продукції, а ваші техніки мають бути здатні на ці покращення. Отже, перший крок – за керівництвом. Перш за все, техніки вашої компанії та робітники ваших заводів повинні знати, що ви маєте завзяття для вдосконалення якості та однорідності продукції, а також почуття відповідальності за якість продукції.

Якщо лише говорити про це, нічого не вийде. Важливо діяти3.

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

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

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

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

Причина того, чому новий спосіб управління проектами був таким важливим і чому стільки різних компаній його прийняли, почасти полягала в надзвичайно поганому стані розробки програмного забезпечення. Проекти майже завжди не вкладалися в строки та бюджет, а часто й взагалі не працювали. І це було не через тупість чи жадібність людей – скоріше річ була в способі їхнього мислення про роботу. Вони наполягали на застосуванні каскадної моделі, казали, що все можна планувати заздалегідь, навіть що умови не змінюються в ході багаторічного проекту. А це вже просто божевілля перед лицем таких змін.

Я переконався в цьому на власному досвіді в компанії BellSouth, коли відвідував їх як консультант багато років тому. Вони мали висококласних інженерів, багато з яких прийшли з відомого дослідницького центру Bell Labs. Вони ідеально дотримувались каскадної моделі. Бралися за величезні проекти на 10 чи 20 мільйонів доларів. Могли зібрати всі вимоги замовника, потім зачинитися на вісімнадцять місяців і вчасно й чітко в межах бюджету видати саме те, що просив замовник. Вони були однією з дуже й дуже небагатьох компаній у всьому світі, яким це вдавалося. Проблема полягала в тому, що на цьому етапі замовники хотіли вже іншого. Обставини змінювались. Ділові цикли скорочувались, а клієнти вимагали більш інтерактивного обслуговування.

Мене запросили подивитися, чи зможу я допомогти BellSouth визначити, що вони роблять неправильно. Дуже скоро я зрозумів, що неправильним був увесь спосіб їхньої роботи. Це може бути неприємно чути, коли вам здається, що ви все робите як слід. Тому одного дня, коли я став перед повною залою, де було 150 інженерів BellSouth, і сказав, що якщо вони не перейдуть на іншу, більш інтерактивну модель, то не втримаються на поверхні, мене не схотіли слухати. Вони всі були дійсно розумними людьми, але вважали мої ідеї черговою управлінською маячнею.

Я ніяк не міг переконати їх, тому просто знизав плечима й пішов, залишивши їм останнє попередження: «Змінюйтесь або помріть»… Компанії BellSouth більше не існує.

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

Подібно до айкідо чи, можливо, танго, Scrum є чимось, що дійсно можна вивчити лише на практиці. Завдяки постійній практиці та вдосконаленню ваше тіло, розум і дух з’єднуються в одне ціле. У бойових мистецтвах ви вивчаєте концепцію під назвою Шу-Ха-Рі, яка вказує на різні рівні майстерності. У стані Шу ви знаєте всі правила та форми. Ви повторюєте їх, наче танцювальні па, тому ваше тіло всотує їх. При цьому ви не відхиляєтесь ані на крок.

У стані Ха, опанувавши форми, ви можете робити щось нове. Наприклад, додавати нові повороти до ваших танцювальних па.

У стані Рі ви вже здатні відкинути форми, які дійсно опанували на практиці, й вільно творити, адже знання суті айкідо чи танго так глибоко вкорінилось у вас, що її відображує кожен ваш крок.

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

Ось чого ви маєте досягти за допомогою Scrum. Я всім зичу досягти цього стану в їхньому житті. Робота зовсім не повинна вас засмоктувати. Вона може плинути потоком, бути виявленням радості, шляхом до вищої мети. Ми можемо бути кращими. Можемо бути великими майстрами своєї справи! Нам просто потрібна практика.

Решту розділів цієї книжки я присвячую розгляду конкретних аспектів Scrum одного за одним. Таке глибоке занурення покликане детально пояснити вам поняття та структуру Scrum. У додатку ви можете знайти текст під назвою «Впровадження Scrum – із чого почати» (стислий опис цієї системи), але він лише розповість вам що робити. Якщо ж ви підете зі мною до кінця, я розповім навіщо.

Що треба запам’ятати

Зволікання подібне до смерті. Оглядайте, Орієнтуйтесь, Вирішуйте, Дійте. Знайте, де ви є, оцінюйте свої варіанти, приймайте рішення та дійте!

Шукайте відповіді ззовні. Складні адаптивні системи дотримуються кількох простих правил, які вони засвоюють із довкілля.

Видатні команди мають свої особливості. Це різнопрофільні фахівці, автономія та взаємопідтримка.

Не гадайте. Плануйте, Робіть, Перевіряйте, Дійте. Плануйте, що ви збираєтесь робити. Робіть це. Перевіряйте, чи відповідає це тому, що ви хотіли. Дійте з огляду на це та змінюйте спосіб своєї роботи. Повторюйте це в регулярних циклах і досягайте за рахунок цього безперервного покращення.

Шу-Ха-Рі. Перш за все, засвоюйте правила та форми, а як тільки опануєте їх, вносьте щось нове. Наприкінці, досягнувши стану високої майстерності, відкидайте форми і просто будьте – глибоко засвоївши все вивчене та приймаючи рішення майже підсвідомо.