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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Саме команди виконують проекти у світі праці. Існують команди, які виробляють автомобілі, відповідають на телефонні дзвінки, проводять хірургічні операції, програмують комп’ютери, готують новини та проникають у двері захоплених терористами приміщень. Безумовно, існують також окремі ремісники чи художники, які виконують роботу самотужки, але саме команди обертають Землю. І саме на них базується Scrum.

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

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

Візьмімо, наприклад, процедуру отримання студентами оцінок під час занять. У Єльському університеті особливо складним вважається курс комп’ютерного програмування професора Стенлі Айзенштата CS 323. Коли студенти почали скаржитись на те, скільки часу займає кожне завдання, професор не зробив своє завдання простішим, а почав відстежувати, скільки часу потрібно кожному студентові на його виконання. Потім Джоел Спольскі, який пройшов курс Айзенштата в далекі 1980-ті, а тепер має власний бізнес із програмного забезпечення, порівняв отримані дані з реальними оцінками, які люди отримували. Він хотів з’ясувати, чи існує якась кореляція між часом, витраченим на проект, і отриманою студентом оцінкою. Цікаво, що не існує. Одні люди працюють швидко й отримують «відмінно», а інші працюють довго, а отримують те саме. Єдиною різницею є кількість витраченого на завдання часу. Як же застосувати це в бізнесі?