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

А якби ви могли завершувати проекти в п’ять разів швидше за ваших конкурентів, з уп’ятеро більшою цінністю? Це шлях до перемоги.

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

Як вам це зробити? Насамперед вам потрібен хтось, хто може визначити як бачення, так і цінність. У Scrum ми називаємо таку особу власником продукту.

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

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

Розробляючи її, я надихався роллю головного інженера компанії Toyota . Людина на цій посаді відповідає за всю виробничу лінію окремої моделі, наприклад, Corolla чи Camry . Для цього вона має задіяти таланти груп працівників, які спеціалізуються на створенні корпуса, коліс, електропроводки тощо. Головний інженер має об’єднати групи окремих фахівців, щоб створити єдину багатофункціональну команду, здатну зібрати авто. За межами Toyota цих легендарних головних інженерів (або шуса , як їх називають у Японії) вважають всесильними лідерами так званого «шляху Toyota ». У певному розумінні це правда. Але влади при цьому вони не мають. Ніхто їм не підзвітний – радше вони самі підзвітні своїм групам. Люди можуть вказувати головним інженерам на їхні помилки, тому вони мають стежити за правильністю своїх рішень. Вони не дають нікому оцінок продуктивності, підвищень чи заохочень. Вони лише приймають рішення щодо бачення авто і способів його виготовлення – шляхом переконання, а не примусу.

Саме цю ідею я й хотів утілити в системі Scrum . Джон Шук з Інституту ощадливого підприємництва якось почав свій опис ролі головного інженера цитатою з інструкції для командного складу морської піхоти США:

Відповідальність людини за лідерство не залежить від влади… глибоко вкорінене припущення, що влада має дорівнювати відповідальності, є коренем великого організаційного негаразду. Я вважаю, що непорозуміння навколо цього питання загрозливе й проблемне, воно проникло в нашу свідомість так глибоко, що ми цього навіть не усвідомлюємо [41] Shook, John. «The Remarkable Chief Engineer.» Lean Enterprise Institute, 3 лютого 2009. .

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