Напівмайстер і мультиплікатор: чому кожній команді розробників потрібен свій скрам-майстер?

“А можна, ми обійдемося без скрам-майстра?” — ось таким питанням мене НЕ здивували керівники однієї світової корпорації. Варіації цього запитання досі чую знову і знову.

З іншого боку, до нас звертаються фахівці ІТ з протилежним запитанням: “Що робити, коли менеджери не розуміють, навіщо їм скрам-майстер?”

У відповідь на цю дилему хочу поділитися своїми міркуваннями, враховуючи досвід багаторічної практики з компаніями зі США, Англії, Сінгапуру та інших країн.

Звичний спосіб мислення

Насамперед варто зрозуміти спосіб мислення будь-якого керівника, адже перед кожним із них стоять два головні завдання:

1. Скорочувати витрати.
2. Збільшувати доходи.

Більшість із них керуються класичним менеджментом, який нині часто називають “старою парадигмою”, що полягає у вертикальній моделі керування (“керівник → підлеглий”), де мусить існувати начальник, який вказує, хто і що має робити, і виявляє коефіцієнт корисної дії працівників.

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

Тож керманичі справді можуть не бачити нюансів, які можуть повернутися їм бумерангом у вигляді недоотриманих вигод, повільного запуску продукту, навіть значних втрат, якщо їм вчасно не надати значення.

Почувши про Scrum, керівники ставлять звичні запитання:

1. Де можемо скоротити наші витрати на вашу інноваційну модель?
2. Як витиснути з неї найбільше вигоди (бажано, якнайшвидше), щоб було видно “результат”?

Втомлений менеджер бачить у новій моделі тільки те, що а) знайоме, б) зрозуміле, в) що може чітко виміряти, мов приладом.

Роботу програміста ще так-сяк виміряти можливо, власника продукту — більш-менш, а от хто такий скрам-майстер?

Оскільки термін “Скрам-майстер” більшості з них а) незнайомий, б) незрозумілий, ще й в) не піддається вимірюванню, то питання звучить доволі логічно: “Ми не розуміємо, яку помітну вигоду отримаємо від цієї ролі. Також не розуміємо, як виміряти її безпосередню ефективність на кожному етапі розробки. Навіщо нам витрачати на неї бюджет?”

Почувши про самоорганізацію, самокерованість, автономію та кросфункціональність скрам-команд, керівники тільки зрадіють своєму рішенню — ніяких скрам-майстрів! Якщо учасники команди в будь-якому разі “самоорганізовані”, то нащо нам ті “майстри”?

Альтернативний погляд

На щастя, чимало менеджерів займаються (або займалися в дитинстві) спортом — футболом, плаванням, тенісом, хай навіть шахами. Відповідно, кожен мав справу з тренером.

Саме під цим кутом пропоную подивитися на роль скрам-майстра.

Уболівальники бачать одинадцятьох футболістів “Динамо”. Тренера на полі не видно. Лиш зрідка він втручається в процес — коли гравець зазнав травми й потрібно підсилити команду або дати важливу підказку (іноді гравці захоплюються грою так, що забувають, навіщо вийшли наполе). Внесок кожного футболіста очевидний для мільйонів глядачів. А от чим займається тренер? Для більшості це питання незрозуміле. Особливо, коли команда програє з розгромним рахунком. Коли ж навпаки — команда виграє, то вболівальники прославляють тренера, хоча знову не розуміють, чим він займався увесь той час.

Отже, успіх усієї команди — успіх тренера. Це один із найважливіших ціннісних принципів у Scrum. Лідер успішний, коли успішна його команда. (В старій парадигмі навпаки — вся команда залежить від одного лідера).

“Лідер успішний, коли успішна його команда”.
— В’ячеслав Москаленко

У цьому й полягає головна роль скрам-майстра — сформувати й виростити успішну скрам-команду.

За аналогією зі спортом, скрам-майстер — це тренер. Позбавити скрам-команду скрам-майстра — те ж саме, що позбавити київське “Динамо” тренера.

Коли я прийшов до тренера з плавання, він просто сказав мені: “Пропливи двічі”. Я проплив. Він спостерігав. Далі лишень підказував: руку підняти трішечки вище, голову розвертати краще і т.п.. Далі я продовжував займатися, враховуючи його підказки.

З точки зору коефіцієнта корисної дії, тренер 80% спостерігає, а тільки 20% створює щось “корисне”. Той, хто керується такою “логікою”, навряд чи зрозуміє, навіщо тренерам платять.

Це повинні переосмислити втомлені менеджери старої парадигми.

Для того, щоб скрам-команда була ефективною й дала бажаний результат, потрібно з повагою поставитися до емпірично розробленої моделі Scrum, випробуваної часом та підтвердженої успіхом світових компаній масштабу Fortune Global 500.

Це означає, що, запроваджуючи скрам, ви запроваджуєте його рольову модель (докладніше про це див. у статті “Рольова модель Scrum: як виникла і чому важлива”), де кожна роль на своєму місці, завдяки чому команда функціонує найефективніше.

З власного досвіду зазначу: всі успішні проекти, реалізовані скрам-командою, мали рольову модель “Скрам”. Для об’єктивності також зазначу, що успішними були й деякі проекти з певними компромісними рішеннями у короткотривалій перспективі, хоча у довготривалій мали свої небажані наслідки. Проте всі невдалі або проблемні проекти об’єднувала одна спільна риса — неповага до рольової моделі в “Скрам”, руйнування цієї моделі, відсутність однієї зі скрам-ролей або її дисфункція.

Хитрощі старої школи

Керівники, які не прочитали цю статтю, вдаються до різних хитрощів, щоб руками й ногами триматися за хай навіть стару, але звичну і зрозумілу модель — більше зекономити і більше “витиснути”, мов із апельсина, результат — тут і зараз.
Серед найпопулярніших хитрощів дві:

1. Змусити скрам-майстра паралельно виконувати інші, більш зрозумілі ролі (наприклад, програміста).
2. Змусити скрам-майстра “обслуговувати” не одну, а кілька команд (що більше, то краще).

Наслідки хитрощів

1. Напівмайстер

Ідеться про:

• додавання інших повноважень скрам-майстру (щоб він також програмував, тестував тощо);
• додавання повноважень скрам-майстра іншому члену команди (програмісту, тестувальнику тощо).

Цікаво, якою була би ефективність збірної Англії з футболу, якби функції одного з одинадцяти гравців на полі виконував… тренер? Або навпаки: функцію тренера (не капітана команди, а тренера) — воротар чи нападник?

Чимало менеджерів старої школи вважають, що високою. Принаймні, такий висновок можемо зробити, судячи з їхніх рішень.

Насправді рішення поєднання ролей робить зі скрам-майстра “напівмайстра”, як у футболі — напівтренера. Відповідно, ми отримуємо “напівскрам” і “напівефективність”.

2. Мультиплікатор

Інший прийом — змусити скрам-майстра працювати на кілька команд, щоб витиснути з нього все за найкоротший період і порадувати “економією” бюджетний комітет або фінансового директора.

Менеджери з таким мисленням не розуміють, що найцінніший актив — талановиті фахівці.

Епоха геніїв відійшла у минуле, зараз — епоха професіоналів, що об’єднуються в команди, й допомагають виводити продукт на ринок в рази швидше, ніж конкуренти. Цього керівники старої школи також не розуміють.
Наслідком шляху “мультиплікатора” буде втрата найціннішого капіталу — ресурс людського таланту. Не бажаючи нічого змінювати у своїх підходах, “старі бурдюки”, ставлячись до талановитих професіоналів, мов до гайок із болтиками свого “механізму”, залишаться далеко або глибоко позаду своїх конкурентів.

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

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

Ламання скрам-моделі блокує розвиток самого скрам-майстра, понижує його ефективність як “тренера”, блокує розвиток команди, що обов’язковою передумовою успіху, ускладнює реалізацію проекту, дає значно нижчі результати.

Кейс мультиплікатора

Одній із авіакомпаній, з якою мені довелося співпрацювати, таки вдалося нав’язати скрам-майстру роль “мультиплікатора”. Керівництво представників великої авіації, мов за підручником, мислило категоріями старої парадигми.

Відповідь на запитання “Який відсоток корисної дії у вашого скрам-майстра?” їх не задовольнила, тому вирішили закріпити за ним кілька команд, всього 40 осіб — хотіли зекономити.

Наслідки такого рішення:

• Скрам-майстер швидко перегорів і виконував свою роль механічно, формально.
• Скрам-майстер втратив зосередженість, розпорошуючи увагу на проблеми різних команд.
• Команди не реалізовували свій потенціал.

Чи може модель “мультиплікатора” мати успіх?

Так. “Мультиплікація” може мати місце, але діяти за іншими законами. Спочатку скрам-майстер має сформувати одну команду, виростити її, поступово делегувати частину повноважень. Мова йде про максимум дві-три команди і тільки про один продукт. Я назвав би це органічним масштабуванням.

Коли модель “мультиплікатора” небажана взагалі?

Найгірше рішення, на мою думку, — це закріпити за скрам-майстром різні команди, які працюють над різними продуктами.

Кейс напівмайстра

Коли я починав свій шлях в ІТ, в компанії, що була лідером із розробки програмного забезпечення, мені сказали: “Ти будеш скрам-майстром на 50%. Половину часу майстром, половину — програмістом”.

Тоді я ще не розумів (так само й не розуміли менеджери), що це міна сповільненої дії. У корені такого рішення — конфлікт інтересів, адже скрам-майстер повинен вести команду до самостійності і автономії, певної незалежності від нього, у той час як де факто був змушений працювати над операційними завданнями разом із іншими. Гібридна роль нагадувала більше тімліда, ніж скрам-майстра.

Моє рішення

Щоб працювати ефективно, я розробив стратегію — цікаві і складні завдання делегував команді, у той час як нудні рутинно-адміністративні (які зазвичай ніхто не хоче робити), залишав собі.

Досвід інших

Підготувавши кількасот скрам-майстрів, я з’ясував, що 4 з 5 були в такій самій ситуації “напівмайстра”! Колеги скаржилися на муки від втрати фокусу, пріоритетів, перевантаження.

У ролі “напівмайстра” успішний результат показував тільки один із десятьох.

Решта дев’ятеро виконувала роль скрам-майстра суто формально — не тренували й не зрощували команду, а працювали, як завжди — проводили “наради”.

Чого я тільки наслухався від скрам-майстрів-початківців: “Скрам не працює!”, “Скрам жахливий!”, “Я недолугий скрам-майстер!”, “До ночі сиджу і маю фіксити чужі баги, щоб вчасно підготуватися до релізу”, “Замовник ріже всі мої ініціативи!”

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

Що робити керівникам

Усвідомити нові поняття

1. Насамперед, варто усвідомити поняття “агент змін”. Скрам-майстер — не особа, яка “виконує обов’язки згідно з посадовими інструкціями”, а лідер, що впливає на середовище й розвиває команду.
2. Також варто розуміти різницю зі старою парадигмою, де всі присутні або керівники, або виконавці. Керівники керують, ставлять завдання, контролюють, проводять зустрічі, звітують, слухають звіти. Цим займаються менеджери проекту.
   У Scrum переосмислено цю роль і створено аналог нового покоління — власник продукту (докладніше див. у статті “Як нерозуміння ролі Product Owner гальмує Agile-трансформацію”).
3. Усвідомити аналогію Скрам-майстра з тренером у спорті.
4. Переосмислити поняття цінності ресурсів, де найвищою цінністю є талановиті фахівці.

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

“За відсутності або дисфункції скрам-майстра за півроку троє з десяти покинуть команду без скрам-майстра, і ці троє будуть найкращі”.
— Слава Москаленко

Втрати у разі відсутності скрам-майстра

1. Команда не зростає.
2. Виникає велика кількість дефектів.
3. Накопичується технічний борг.
4. Порушуються кінцеві терміни.
5. Виникає зайва напруга в команді.
6. Гальмується реліз.
7. Компанія втрачає конкурентні переваги на ринку.
8. Компанія втрачає найцінніший ресурс — людський талант.
9. Компанія недоотримує прибуток.

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

Скрам-майстер якраз і потрібен для того, щоб забезпечити стабільність, надійність, безперебійну роботу команди, на яку можна розрахувати упродовж тривалого часу й мати тривалі результати.

В кожній скрам-команді мусить бути свій скрам-майстер.

Висновки

1. Керівникам варто утриматися від хибної ідеї економити на скрам-майстрах, коли йдеться про розробку за Scrum-підходом.
2. Уникайте невдалих експериментів з напівмайстрами та мультиплікаторами.
3. Коли виникає необхідність масштабувати роль скрам-майстра, керуйтеся органічним масштабуванням.
4. Саме формат “один скрам-майстер на одну команду” найкраще забезпечує її зростання та ефективність.
5. Якщо ваша компанія хоче рівнятися на успіх Fortune Global 500 — не жалійте грошей на скрам-майстра.

ДОЛУЧИТИСЯ ДО AGILE.LIVE

• Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Product Owner (PSPO), Professional Agile Leadership Essentials (PAL-E)
• Підписатися на сторінку у LinkedIn
• Підписатися на Telegram-канал Agile.Live
• Підписатися на You-канал Agile.Live