Що потрібно знати керівникам про Agile-підхід і роль власника продукту, щоб прискорити перехід на гнучку модель
У попередній статті «Agile-трансформація: які помилки керівники мають виправити негайно?» ми
пообіцяли докладніше розкрити проблему взаємодії між керівником та власником продукту. Тож
розгляньмо такі питання, як лідерство в Agile, поняття автономності й роль Product Owner.
ТРИ ПРОБЛЕМИ
Запровадження Agile передбачає зміни організації — не тільки структурні й функціональні, а й світоглядні. Природнім чином це призводить до тертя між керівниками й співробітниками. Тому процес переходу на нову модель гальмується або зупиняється взагалі. Як усунути цю перепону? Як пришвидшити перехід на Agile? З власної практики ми дійшли висновку, що незалежно від галузі та геолокації, багатьом компаніям, які самотужки запроваджують Agile, заважають такі чинники:
- слабкий рівень підготовки керівників;
- нерозуміння різниці між старою і новою парадигмами менеджменту;
- порушення меж з боку авторитарних менеджерів.
Відповідно, перехід на Agile гальмують такі три проблеми:
- Нерозуміння концепції лідерства в парадигмі Agile.
- Нерозуміння керівниками поняття «автономність» в Scrum.
- Нерозуміння ролі Product Owner.
РОЛЬ ЛІДЕРА
В’ячеслав Москаленко, сертифікований тренер Scrum, розповів:
Мене вразила компетентність лідерів однієї компанії, найбільшого виробника вибухових речовин й системи підривання для нафтовидобувної промисловості — транснаціональної корпорації з мільярдними статками. Компанія започаткована в Австралії ще у 1874 р., та й не зовсім пов’язана з ІТ — постачає комерційні . Проте її керівники усвідомили нові вимоги часу й створили підрозділ із цифрових рішень, внаслідок чого компанія оптимізувала виробничі процеси, розширила спектр послуг і здобула переваги на ринку. Я мав честь запровадити Agile-підхід у новоствореному підрозділі та підготувати команді до роботи.
Компетентність керівників компанії приємно здивувала. Вони не вказували мені, що робити, не втручалися і не заважали ні мені, ані іншим співробітникам. Натомість з повагою ставилися до ролей та не перетинали межу, добре розуміючи важливість автономності кожної ролі в команді.
Роль лідера в парадигмі Agile — не втручатись, а допомагати. Його завдання — створити умови для досягнення стратегії розвитку продукту.
Наприклад, клієнт готовий замовити ваш продукт, якщо за три місяці ви адаптуєте його до вимог законодавства його країни. У такому разі «допомога» з боку керівника може полягати у наданні команді зовнішніх контактів, важливу інсайдерську інформацію. Він також може стежити за просуванням проекту (progress), переконуватися в тому, що всі йдуть в одному напрямку й розуміють мету, а в разі необхідності давати зворотний зв’язок (але не втручатися у внутрішні процеси й не нав’язувати власну думку!) В Agile внесок керівника має хіба що рекомендаційний характер, і то — на прохання команди. Саме це відбувалося в цій компанії.
На противагу австралійським «підривникам», деякі авіакомпанії, що ніяк не могли попрощатися зі старою школою менеджменту, пожали гіркі плоди (одні збанкрутіли, інші ледь протрималися за рахунок державної підтримки) — значною мірою через небажання керівників змінюватися, директивні методи керування, постійні втручання в процес, свавільні розпорядження «зверху», скасування інноваційних ідей, блокування рішень scrum-команд, особисті амбіції, нездатність бути гнучкими та швидко адаптуватися до нових реалій.
Це дуже нагадує архаїчні методи управляння минулого сторіччя, тому може виникнути хибна думка про те, що вертикальні моделі — пережиток минулого. Ба ні. Відсутність гнучкості — явище універсальне. Щодо ролі скрам-команди, то йдеться про «внутрішню кухню» — формування та пріоритезацію завдань, розробку інкременту та ін. (докладніше про команду та її ролі в scrum див. окремі статті на ресурсах Agile.Live), у той час як роль керівника — діяти в окреслених межах своєї компетенції. Іншими словами, керівник забезпечує «рамку», всередині якої працює команда. Світоглядно Agile-лідер ставить власний успіх в залежність від успіху команди.
Agile-лідер вважає, що його успіх залежить від успіху команди, яка здатна автономно приймати рішення.
АВТОНОМНІСТЬ
Одна з найпринциповіших характеристик Agile-підходу — самоорганізованість команди та автономність власника продукту (Product Owner). Нерозуміння автономності в парадигмі Agile може дорого коштувати.
Розгляньмо приклад порушення керівниками автономності власника продукту й зони відповідальності команди.
Порушення автономності
Не змінюючи старих звичок, керівник старої парадигми:
- Сам визначає показники ефективності (KPI) для команди.
- Сам розробляє план дій.
- Сам встановлює кінцеві терміни виконання.
- Контролює, втручається, заважає працювати.
- Береться власноруч розрулювати дрібні ситуації, якщо раптом щось пішло не так.
- За звичкою скликає наради, зовсім непотрібні для команди.
- Успіх команди ставить у залежність від власної персони.
На противагу таким авторитарним методам, в Agile цими питаннями займається команда у
взаємодії з власником продукту (Product Owner).
РОЛЬ ВЛАСНИКА ПРОДУКТУ
Власник продукту (Product Owner) у Scrum наділений автономністю, що передбачає відповідальність. З точки зору вертикальних структур, Product Owner може бути на рівні менеджера середньої ланки, проте за функціональністю й повноваженнями — значно перевершувати свого керівника. За методологією Scrum, Product Owner наділений правом представляти організацію, а тому уповноважений ухвалювати будь-яке рішення щодо продукту. До того ж, рішення власника продукту скасовувати не можна. Це часто дивує менеджерів старої школи. Проявляючи командно-адміністративний стиль керування, вони нівелюють гнучкий підхід, внаслідок чого їхні заяви про «виведення компанії на новий рівень» залишаються декларативними, а підхід не можна вважати Scrum.
«Власником» продукту називають через те, що він має «привласнити» перелік завдань, що стосуються розробки продукту (Product Backlog) — визначити їхні пріоритети, що неможливо без права «власності» над завданнями. Насамперед роль власника продукту полягає в розумінні цінності самого продукту, що він має донести до команди, враховуючи потреби майбутніх користувачів та замовників.
Власник продукту має і обмеження. Наприклад, не має права відповідати на запитання «як» (це прерогатива всієї команди), хоча відповідає за «чому» і може тільки впливати на «що» і «хто». Нарешті, власник продукту — комунікатор на всіх рівнях і взаємодіє зі скрам-мастером (це окрема тема, яку ми спеціально висвітлимо на Agile.Live).
ПІДСУМКИ
Отже, одна з найперших навичок, яку варто сформувати керівникам компаній, які запроваджують Agile, — це розуміння меж власної компетенції та ролей — передусім власника продукту. Не команда має залежати від успіху керівника, а керівник — завдячувати свій успіх команді. Для успішного запровадження гнучкого підходу керівнику варто формувати новий стиль лідерства, що передбачає:
- Вміння давати зворотний зв’язок (не втручатися, а відгукуватися; рекомендаційний, а не наказовий стиль комунікації).
- Відмова від мікроменеджменту (для цього є ціла команда зрілих людей, які не потребують напучування патріарха).
- Цікавитися системою та стратегією, а не фрагментарними питаннями.
- Переконатися в тому, що усі учасники команди розуміють цілі, вимоги, критерії успіху, показники ефективності, квартальну/річну мету тощо.
- Не вказувати, а цікавитися, ставити запитання (формувати стиль наставника, на відміну від керівника).
Саме лідери нової Agile-парадигми, які створили належні умови для команди, подбали про розуміння цілей, забезпечили автономність власнику продукту, дали простір усій команді для реалізації свого бачення на те, як потрібно реалізовувати завдання, здатні вивести компанію на нові вершини, як це зробили керівники цифрового підрозділу компанії-лідерів з виробництва продукції для нафтовидобувної промисловості.
ДОЛУЧИТИСЯ ДО AGILE.LIVE
Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Product Owner (PSPO), Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E)
Підписатися на сторінку у LinkedIn
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live