Scrum - Джефф Сазерленд
Щоб бути ефективною, ця зустріч потребує певної емоційної зрілості та атмосфери довіри. Головне – пам’ятати, що ви не шукаєте когось винного, а розглядаєте можливі недоліки процесу. Чому це сталося саме так? Чому ми це пропустили? Що може зробити нас швидшими? Дуже важливо, щоб люди брали на себе відповідальність за свою роботу і її результати як команда та шукали рішення як команда. Водночас люди повинні мати мужність порушувати питання, які дійсно їх турбують, орієнтуючись на пошук рішення, а не звинувачення. А решта команди повинна мати зрілість слухати відгуки, сприймати їх та шукати розв’язання, а не займати оборонну позицію.
У циклі Демінга (плануйте, робіть, перевіряйте, дійте) ретроспективна зустріч – це частина перевіряйте. Головне – дістатися кроку дійте (кайдзен), який дійсно змінить робочий процес та зробить його кращим наступного разу. Недостатньо лише ділитися відчуттями, потрібно мати змогу діяти.
Найкращий виявлений мною спосіб досягти всього цього базується на тому, що я називаю «показником щастя». Це простий, але дуже ефективний спосіб зрозуміти, де має бути кайдзен, а також який кайдзен зробить людей найщасливішими. Я вже використовував його, досягши дуже непоганих результатів.
Ось як це працює. Наприкінці кожного спринту кожен член команди відповідає лише на декілька запитань:
1. Як ви почуваєтесь щодо своєї ролі в компанії за шкалою від 1 до 5?
2. Як ви почуваєтесь щодо компанії в цілому за тією самою шкалою?
3. Чому ви так вважаєте?
4. Яка одна річ могла б зробити вас щасливішими в наступному спринті?
І все. Це можна зробити лише за кілька хвилин. Кожен член команди по черзі висловлює свої думки, що викликає дійсно глибокі обговорення. Разом команда зазвичай доходить до кайдзену доволі швидко. Цей метод виявляє найважливіші моменти для кожного члена команди, а також те, що вони вважають найважливішим для компанії.
А тепер ключовий момент. Команда бере це одне головне покращення та робить його найважливішою річчю, яку слід зробити в наступному спринті, – зі вступними випробуваннями. Як ви доведете, що покращення досягнуто? Потрібно визначити, що таке успіх, чітко та доступно, щоб у наступній ретроспективі спринту було дійсно легко побачити, чи досягли ви кайдзену.
Кілька років тому я вирішив розширити свою компанію Scrum, Inc. до консультаційної агенції з повним набором Scrum-послуг. Ми відстежили нашу швидкість і виявили, що кожного однотижневого спринту виконуємо завдань приблизно на сорок балів. Після запровадження показника щастя одразу виявилось, що наші сюжети не досить добрі. Вони не були достатньо підготованими, не мали визначення готовності та були надто розпливчастими. Я попрацював над цим, і ми почали писати кращі сюжети. Але протягом наступного спринту вони все ще були недостатньо добрими. Це відображали наші оцінки щастя. У третьому спринті виникла нова проблема. Ми взялися за неї. Так і пішло. Усього за кілька тижнів наша швидкість збільшилася із сорока балів за спринт до ста двадцяти. Ми потроїли продуктивність, просто питаючи, що може зробити людей щасливішими. Як результат, наші клієнти також стали щасливішими, а наші прибутки різко підскочили. Усе, що треба було для цього зробити, – почати питати в команди: «Що може зробити вас щасливішими?», а потім давати їм це.
Ми зобразили ці дані на графіку, наклавши їх на час, і побачили кілька надзвичайно цікавих моментів. Як генеральний директор, я зосереджений на тому, що може статись у майбутньому з нашими прибутками, зростанням та продуктивністю. І от що я виявив: на відміну від фінансових показників, показник щастя є прогностичним. Фінансові дані показують, що було в минулому, але, коли ви питаєте людей про їхнє щастя, вони дійсно проектують майбутнє. А коли вони думають про своє щастя в компанії, то починають проектувати свої думки про діяльність компанії. Як результат, ви отримуєте сигнал про проблему до її виникнення. І, якщо приділяти достатньо уваги тому, що каже вам ваша команда, можна вживати заходів та виправляти ситуацію до того, як вона перетвориться на проблему. На графіку нижче, наприклад, падіння рівня щастя передує падінню швидкості чи продуктивності на кілька тижнів. Якщо дивитися лише на продуктивність, ви не побачите негараздів, доки вони не зваляться вам на голову, неначе гірський обвал. Але, побачивши по всій команді падіння щастя, навіть за умови зростання продуктивності, знайте, що у вас проблема, якою слід зайнятися, причому якнайскоріше.
Робіть усе видимим
Що це за речі, які дійсно роблять людей щасливими? Це ті самі речі, які роблять команди видатними: автономія, майстерність і мета. Або, якщо взяти ширше, це здатність контролювати вашу власну долю, відчуття, що ви стаєте кращими в чомусь, і знання, що ви служите чомусь більшому, ніж самим собі. Але існують також деякі прості, конкретні кроки, які може зробити керівництво, щоб культура компанії заохочувала ці якості.
Одним з елементів Scrum, що часто передує досягненню автономії, майстерності та мети, є прозорість. Ідея полягає в тому, що має не бути жодних таємних інтриг, прихованих мотивів, нічого за лаштунками. Надто часто в компанії буває насправді неясно, хто над чим працює чи як щоденна діяльність кожного працівника наближає спільні цілі.
Запускаючи Scrum, я багато думав про закони, які один мій добрий друг намагався включити в законодавство штату Колорадо, – так звані закони «сонячного світла». Вони вимагали, щоб усі публічні зустрічі бути відкритими, усі записи – доступними для громадськості, а також щоб нічого не відбувалося за зачиненими дверима – нічого не приховувалось. Ось чому в Scrum будь-хто може прийти на будь-яку зустріч. Будь-яка зацікавлена особа може спостерігати за щоденним стендапом чи відвідати огляд спринту.
Я прагнув зробити все відкритим. А це може лякати деяких людей. Розповім про PatientKeeper – компанію, яка розробляє портативну апаратуру для лікарень та лікарів. Коли вони найняли мене, я одразу ж застосував до їхнього виробничого процесу систему Scrum. Я сказав розробникам, що тепер всі мають знати все, що відбувається в компанії. Вони ж настільки звикли до різних обмежень, що злякалися нового рівня прозорості як чергового підступного плану керівництва.
«Довіртесь мені, – переконував я. – Це не використовуватиметься вам на шкоду. Чи з метою покарання. Це піде лише всім на користь».
Як я вже казав, командна продуктивність цікавить мене значно більше за індивідуальну. Командну продуктивність можна подвоїти за місяць, а індивідуальну? На це може піти рік. А як щодо цілого гурту окремих людей? Цілого підрозділу? Цілої компанії? Тут потрібна вічність. Тому для зосередження на покращенні команди я використовую прозорість. Я вважаю, що зазвичай команда сама здатна розв’язати проблеми з індивідуальною продуктивністю своїх членів. Адже команді відомо,