top of page
logo_scrum_ua_white.png
Фото автораAlexey Krivitsky

5 пасток Скрам Майстра — досвід Олексія Кривицького


Понад 6 років я працював full-time Скрам Майстром у компаніях та бачив багато різних ситуацій. Також я працював зовнішнім Scrum, Agile консультантом і бачив безліч різних компаній, спілкувався з великою кількістю Скрам Майстрів, яких навчав, наставляв і коучив. Зі свого власного досвіду та спостережень хочу з вами поділитися моєю свіжою знахідкою: п’ятьма пастками, капканами або глухими кутами Скрам Майстра.


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



«Бути корисним»


Уявімо ситуацію. Ви приходите як Скрам Майстер у команду. Невідомо, чи був там раніше Скрам Майстер. Це не важливо. Ви прийшли, адже вас найняли. Звичайно, що ви намагаєтесь і хочете стати другом для цієї команди, збудувати містки довіри. І найкраще, що ви можете зробити це запитати поради в досвідчених колег, й отримати від них приблизно таку відповідь: «Слухай, виріши, конкретні проблеми команди.» (І у вас у думках може зазвучати — О! Точно! Потрібно проявити себе як chief impediment remover. Я Скрам Майстер. Буду вирішувати.)


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



Ви повинні вирішувати мета проблеми, а не проблеми.


Вам потрібно вирішувати більш важливе завдання, його похідну. Ваша реальна місія (мета або завдання) — покращувати систему, а не вирішувати нагальні проблеми. Це важливо розуміти. Тому якщо ви вірите в те, що ваша місія покращувати систему за допомогою виконання повторюваних операційних задач, ви вже втрачаєте час, і не покращуєте цю систему. Ви є частиною системи, а далі система починає вас використовувати так, як їй зручно. Це пастка матриці, у яку ви потрапили. Як тільки ви перетворюєтеся на посередника «піди й поговори з тими людьми», ви більше не Скрам Майстер, ви більше не Коуч, ви — передавач, частина системи, і люди будуть вас використовувати для власної вигоди.Не вирішуйте проблеми навпростець. Ваше завдання — вирішувати причини виникнення проблем. І тут, безперечно, буде корисною відома техніка «5-ти Чому?» («Five whys») для аналізу та пошуку причин, вирішення реальних проблем, а не їх симптоматики. Завжди намагайтесь вирішувати проблеми вищого порядку.Наприклад, ви можете проапргрейдити комп’ютери команди, адже в них повільні комп’ютери. Це рішення навпростець. Вирішення такої мета проблеми це налаштувати системи в компанії. Я так робив навіть у великих компаніях: запускав у Jira проєкти на IT саппорт та налаштовував систему так, щоби люди могли самостійно створити тікет та проапгрейдити чи замовити апгрейд своєї системи.


Це розв’язання проблеми, але це також і рішення класу проблем.


«Втягнутися в роботу»


З часом ви почали вирішувати мета проблеми, люди вам довіряють, й у вас з’являється час подивитися над чим працює команда. Вона відчинила вам двері довіри, і ви, звичайно, занурюєтеся. А там грумінги, фічі, тікети, кастомери і ви теж на цьому знаєтеся, адже ви, наприклад, колишній розробник або будь-хто. Й ось «Oops!.. I did it again». Ви робите роботу. У команді достатньо людей, щоби виконувати роботу.


Ваша функція — аналізувати системні імпедименти, працювати над системою роботи, а не над самою роботою.

Робота затягує, вона проста та зрозуміла. Й у вас, найімовірніше, для цього вже є певні навички. І саме тому так важко вибратися із цієї пастки. Не так багато Скрам Майстрів, які все ще в першій пастці, але я бачу дуже багато тих, хто досі знаходиться в другій. Вони просто члени команди. Якщо ви прийдете подивитися на команду, то ви не зрозумієте хто тут Скрам Майстер, а хто розробник.Ваша робота — дати інструменти для того, щоби виконувати роботу, навчити робити роботу. Припустімо, що вам подобаються грумінги і ви від них у захваті. Тоді навчіть команду, та покажіть як їх ефективно проводити.


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


Наприклад, вам подобається писати код. Чудово! Ви не повинні приховувати цю навичку. Ви знаєте й у вас є ідеї як рефакторити складний код, як налаштовувати білди. Зробіть це! Ніколи не працюйте наодинці, адже ви тоді будете налаштовувачем Continuous Integration-на. Я був у такій ситуації, тому працюйте у парі, групою, робіть разом, передавайте свої навички далі.


Навчання, наставництво, фасилітація та коучинг — чотири речі, які є вашою прямою роботою. І тому вам потрібно робити роботу побічно.



«Володіти процесом»

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



Завдання Скрам Майстра — допомогти людям узяти відповідальність за свою роботу, за свій процес. І тому чим більше вас десь, тим менше їх там. Ваше завдання — фасилітувати оволодіння процесом, запустити культуру регулярних покращень (Святий Kaizen та Continuous Improvement). Поки ви берете на себе всі тікети з ретроспективи для покращення, ні в кого не буде можливості навчитися вдосконалюватися. Не беріть усі action item-и на ретроспективі, залиште команді хоча б один. :)


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




Працювати [тільки] з командами


Ви віддали процес команді. Люди вдосконалюються, проводять ретро та голосують за тікети. Усе добре, ви челенджите й команда росте. Але якщо подивитися в посібник зі Скраму, там сказано, що Скрам Майстер надає три види послуг сервісу: команді, власнику продукту (PO), і сервісу організації. Працюючи тільки з командами та зациклюючись на їхньому вдосконаленні, ви можете проґавити дуже багато можливостей покращити роботу PO та організації. Це досить банальна ідея та пастка, але так багато Скрам Майстрів працює лише на рівні команди.


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


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


Насправді у такому вигляді ця роль і була задумана засновниками Скраму.


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


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




Відсутність стратегії виходу

Чи можете ви бути нескінченно корисними для конкретної системи?Питання риторичне. Думаю, що навряд. Згідно з законом Вайнберга з книги «Секрети консультанта» огірок стане швидше солоним, ніж розсіл набуде смаку огірка. Рано чи пізно ви перефарбуєтеся у колір системи.



Ви створите новий процес і ви захищатимете його від подальших реформ. Фактично ви станете агентом нової покращеної матриці. Завдання Скрам Майстра челенджити «статус кво», ставити незручні питання. І для того щоб це робити, потрібно мати щось більше, ніж просто список імпедиментів. Для цього потрібно мати великі серйозні покращення, або знати свої межі, розуміти час, коли треба піти. Без великих змін ви лише елемент системи, не агент змін.Агент змін перебуває в конфлікті між власним віжном та системою у своєму поточному стані.


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



Я розробив інструмент Agile Coaching Canvas, який допомагає Скрам Майстрам коучити себе й команди для того, щоб створювати довгостроковий віжн Скрам Майстра.Я вважаю, що PO повинен мати віжн продукту, інженери та команда — віжн інженерної складової, а Скрам Майстер, Agile коуч — віжн більш кращої системи (В Lean це має назву «Perfection Vision»).


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


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

1 перегляд0 коментарів

Останні пости

Дивитися всі

Yorumlar


bottom of page