Цитаты из книги «Scrum. Навчись робити вдвічі більше за менший час»

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

Люди хочуть бути щасливими. Не в сенсі сонного самовдоволення, як вівці, а в значно більш активний спосіб. Томас Джефферсон, серед багато чого іншого, вихваляв той вид щастя, який приносить гонитва за чимось. Саме вона, схоже, й робить нас щасливими. Правильне застосування Scrum зробить щасливими робітників, клієнтів, менеджерів та акціонерів (зазвичай у такому порядку).

Гладенько буває лише на папері. Не закохуйтесь у свій план. Він майже напевно неправильний. Плануйте лише те, що вам потрібно зробити. Не намагайтесь проектувати все на роки вперед. Просто плануйте достатньо для підтримки зайнятості вашої команди. Що це за собака? Не оцінюйте проект в абсолютних величинах типу годин — доведено, що люди цього не вміють. Оцінюйте відносний розмір завдань: собаками, футболками (S, M, L, XL, XXL) чи, ще краще, за допомогою послідовності Фібоначчі. Питайте оракула. Використовуйте сліпу техніку, на кшталт дельфійського методу, для уникнення чужих впливів типу ефектів ореолу чи стадності або просто дурного групового мислення. Плануйте за допомогою покеру. Використовуйте для швидкої оцінки роботи, яку потрібно виконати, спеціальний планувальний покер. Робота — це сюжет. Спочатку думайте про те, кому це принесе цінність, потім про те, що це таке, а потім — навіщо це їм потрібне. Люди мислять сюжетами та побажаннями, тому давайте їм їх. Як X, я хочу Y, щоб Z. Знайте вашу швидкість. Кожна команда має точно знати, скільки роботи вона може виконати в кожному спринті. Крім того, її члени мають знати, наскільки вони можуть покращити цю швидкість, працюючи розумніше та усуваючи бар’єри, які їх затримують. Швидкість × Час = Виконання проекту. Визначивши швидкість свого просування, ви знатимете, як скоро досягнете мети. Ставте сміливі цілі. За допомогою Scrum не так уже й важко подвоїти виробництво чи вдвічі скоротити час завершення проекту. Якщо робити все правильно, ваші прибутки та вартість акцій також подвояться.

Того літа ціни на акції Medco приємно дивували. З початком розбудови інфраструктури вони поповзли вгору, а коли ми закінчили, вони продовжили зростати. Наскільки? На багато мільярдів доларів, із 25 до понад 50 доларів за акцію протягом одного року. На Волл-стрит вирішили, що компанія продовжуватиме зростати, приваблюватиме нових клієнтів і зберігатиме лідерство у своїй галузі. Якби ж я знав, то попросив би собі відсоток від зростання ринкової вартості компанії, а не простий гонорар. Через кілька років Medco застосувала Scrum для створення того, що вони назвали Medco 2.0. Вони реструктуризували всі частини компанії, згори донизу. Нові заводи, нові рóботи, нові виробничі процеси, більше автоматизації. Марк Ленді, який тоді вже був головним технічним директором компанії, каже, що без досвіду лікувально-оздоровчих центрів вони б не змогли це зробити. «Нам просто не дозволили б зробити це в промислових масштабах. Але ми отримали підтримку всієї організації: відділу розробки, операцій, фінансів, клінічних випробувань. Ми змогли створити нову культуру». А це, він каже, є найважливішою частиною Scrum: зміна культури праці людей, яка може деяких лякати. Правда, за його словами, компанії довелось позбутися співробітників, які не змогли переключитись на новий лад. Не через їхню некомпетентність, а через приховування інформації та знань для власної користі, забезпечення власної незамінності, а не допомоги команді та компанії. Проте саме зміна такої культури дозволяє досягти справжньої досконалості.

1. Чи можемо ми щось змінити для більшого приско­рення? — Ну, — сказав головний інженер, — десь у середині останнього спринту хлопці з інформаційної безпеки відключили вихід в Інтернет, тому наші команди в Індії та Бразилії не змогли нічого зробити. — То це ж треба виправити, так? — я аж вухам своїм не повірив. Головний інженер подивився на голову служби інформаційних технологій, який сидів за столом трохи далі. На їхню думку, це мало скоротити час виконання проекту на місяць. Залишалося ще два. 2. Чи можемо ми виключити якісь пункти з беклогу? Доручити частину іншим командам? Нічого путнього ніхто не запропонував. 3. Можна не робити якісь речі? Зменшити якимось чином обсяг проекту? — Неможливо, — відповіли вони. І без того всі вимоги були скорочені до мінімуму. — Гаразд, — сказав я, — але давайте просто присвятимо другу половину дня їх перегляду. Кожне завдання має поборотися за своє життя. Це зайняло кілька годин, але ми зекономили ще місяць.

Отже, після трьох спринтів вимірювання швидкості команди прискорились із 20 до 60 балів за спринт, і я вже знав, коли вони завершать проект. Ураховуючи їхню швидкість та прогрес на початок березня, потрібно було ще дев’ятнадцять двотижневих спринтів, а отже, строк виконання — 1 грудня.

У Scrum цей вид планування проводиться абсолютно для кожного спринту під час спеціальної зустрічі. Усі збираються разом, розглядають перелік завдань, які потрібно виконати, і кажуть: «Гаразд, чого ми можемо досягти в цьому спринті? Чи готові ці завдання? Чи можливо виконати їх до кінця цього циклу? Чи зможемо ми потім продемонструвати їх клієнтові, показавши реальну цінність?» Ключем до відповіді на ці питання є лише те, наскільки швидко команда просувається вперед.

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

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

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