Євген Лабунський: «Agile допомагає будувати антитендітні системи»

Як провести agile-трансформацію в IT-компанії? З цим питанням команда рекрутингової агенції Indigo звернулася до експерта. В інтерв'ю Євген Лабунський, Agile Coach, Scrum Master, керуючий партнер Scrum Ukraine, розповів про те, в яких організаціях «приживаються» гнучкі підходи, до чого готуватися на шляху трансформації, чому зміни в команді змінюють країну і чи можна використовувати agile для персональної ефективності.

Євген: Насправді популярні agile-підходи існують давно. Наприклад, канбан з 50-х років застосовується у компанії Toyota. Скрам вперше описали японські автори у статті "The New Product Development Game" (Harvard Business Review), 1986 року. Потім IT-команди в 90-х роках «змахнули пилюку» з цих концепцій і почали їх використовувати у своїй сфері, тому що зіткнулися з необхідністю швидко отримувати від клієнтів зворотний зв'язок, реагувати на зміни та покращуватись. Це допомогло "включати" цикли інновацій. Більшість людей, які стояли біля витоків agile, були програмістами й використовували різні інженерні практики, які належать до гнучкої методології (наприклад, екстремальне програмування і багато інших). Точкою відліку розвитку agile у сучасному розумінні вважається 2001 рік: тоді було прийнято Agile Маніфест, основний документ, що включає 4 цінності та 12 принципів гнучкої розробки. Це досить рідкісний випадок, коли багатьом людям вдалося зібратися в одній локації та придумати щось дуже тямуще.

Євген: Мистецтво робити те, що потрібне, вчасно. У багатьох agile асоціюється з «вищими, сильнішими, швидшими». Це парадигма т.з. помаранчевих організацій, мета яких – перемогти конкурентів. Але насамперед agile вирішує не проблему швидкості: немає сенсу швидко робити нікому не потрібну нісенітницю. Agile – це насамперед про розуміння клієнта та про постійні зміни. Не виконання якось придуманого плану, а логіка поетапного поліпшення.

Євген: Звичайно, у продуктових. В аутсорсингових компаніях також можливе застосування agile, але тільки якщо команда відкрито взаємодіє з клієнтом, готова працювати з ним як з партнером. У той час, як в аутсорсингу часто спостерігається інша ситуація: є команда, яка застосовує, наприклад, скрам, працює спринтами. Але беклог наповнює бізнес-аналітик з цієї ж IT-команди, клієнта не запрошують на ретроспективи – лише на демо. Product Owner з боку клієнта, але команда не може розповісти йому про всі невдачі - бо боїться, що замовник піде. Закриваючи систему від клієнта, команда втрачає agile: у комунікації з'являються зайві ланки, зникає інформація, загалом відбувається все те, чого ми хочемо уникнути.

Євген: Трохи понад рік тому до нас звернулася продуктова компанія з Мінська, яка працює у сфері RPA (роботизованою автоматизацією бізнес-процесів – прим. ред.). Компанія переживала етап швидкого зростання та шукала оптимальну систему для подальшого розвитку. Ми разом із командою з 60 осіб (весь девелопмент) зібралися на п'ятиденній виїзній сесії, провели навчання з agile. А потім з меншою групою, з 25 осіб, по суті з нуля розробили нову організаційну структуру, орієнтуючись на принципи agile: визначили, якими будуть команди та взаємодія між ними, ролі, завдання. Використовували один із фреймворків масштабування скраму в організації – Large Scale Scrum (LeSS). Потім компанія близько пів року імплементувала цю систему. На цей момент в організації з понад 100 осіб є 15 скрам-команд, які взаємодіють між собою та працюють над одним масштабним продуктом. Це велика замкнута екосистема. Ми проводимо для них сесії, планування, навчання та командний коучинг.

Євген: По-перше – боятися. Серйозно, страх паралізує будь-які творчі ініціативи та інновації. По-друге, agile-трансформація точно провалиться без залучення топменеджерів. Вони просто не зрозуміють, що ви робите. Інсайти, які команда отримує під час змін, не можна передати словами – щоб зрозуміти суть, потрібно перебувати всередині цієї ситуації та пробувати самому. Працює лише тісна колаборація всередині організації. Це експеримент для всіх, і насамперед топменеджмент має хотіти розібратися, як це працює. Саме менеджери мають демонструвати нову поведінку своїм прикладом.

По-третє, гарантований фейл - не виділяти людей у ​​команду на 100%, "балуватися" 10-15% зайнятості. У команди обов'язково станеться когнітивний дисонанс, люди не зрозуміють, куди їм бігти, і врешті-решт побіжать туди, де голосніше кричать. По-четверте, обирати Product Owner, який нічого не розуміє у бізнесі, не знає, куди має прийти компанія і для чого взагалі робляться зміни. У продуктовій компанії цю роль повинен виконувати, наприклад, Product менеджер В аутсорсингу немає нікого кращого за представника клієнта. Але не бізнес-аналітик самої компанії, який передає інформацію команді – він буде ланкою, що змінює контекст.

По-п'яте, велика помилка – не міняти сам ІТ-ландшафт. Трансформація має на увазі докорінні зміни в IT-інфраструктурі. Якщо впровадити скрам, але залишити, наприклад, мільйон етапів тестування всередині організації, система залишиться такою ж негнучкою, складною та повільною.

Євген: Дуже просто – запустити пілот. Немає іншого способу навчитися ходити, крім як зробити перші кроки – тут той самий принцип. Потрібно вибрати один-два продукти чи напрямки діяльності, виділити людей, посадити їх в одному приміщенні та спробувати працювати у новому форматі. При цьому важливо розуміти, що на початковому етапі компанії обов'язково стикаються з проблемами. Коли люди починають працювати по-іншому, на поверхні виявляються проблеми, які були й раніше, – просто їх ніхто не помічав. І створюється оманливе враження, що у всьому винен agile. Наприклад, здається, що людей не вистачає, треба наймати більше працівників. Хоча насправді це не так, і питання у тому, чим зайняті люди, чи роблять вони те, що потрібно, з погляду цілей бізнесу.

Менеджерам потрібно відповісти на запитання: "Чи готові ми до цього?" Що вибрати: повернутися, до старих систем роботи, і знову вдавати, що проблем немає; або розв'язувати проблеми й все-таки почати шлях в agile. Є конкретна точка ухвалення рішення, яка ділить роботу на «до» та «після». Багато компаній виявляють бажання стати agile. Але тут бажання надто мало. Є два рівні мети: compliant to go - коли ти згоден йти, але в принципі тобі окей і так. І commitment to go – коли ти справді готовий пройти цей шлях. Так ось для трансформації підходить лише другий варіант.

Важливо, з яким настроєм ви починаєте трансформацію. Що б ви не хотіли довести – що agile працює чи що не працює – ви обов'язково це доведете. Якщо вам agile - це просто модне слово, а до змін ніхто не готовий, все зруйнується і повернеться попередня система взаємодії.

Євген: Є різні моделі, наприклад, ADAPT, яка складається з п'яти етапів: Awareness (поінформованість про те, що зміни неминучі), Desire (бажання змін), Ability (здатність зробити зміни), Promote (внутрішні цикли зв'язку, обмін знаннями) та Transfer (перехід до нової панівної організаційної моделі, культури управління).

Євгеній: Перша умова запуску пілота – тільки Product Owner може давати роботу команді. Разом з Product Owner команда створює беклог та дорожню карту. Швидше за все, інші люди в організації, особливо лінійні менеджери, захочуть втрутитися в роботу, щось проконтролювати, внести свої корективи. Дуже важливо захистити команду від зовнішнього впливу. Тут культура завжди слідує за структурою. Якщо вчора люди працювали в департаментах, а сьогодні їх зібрали в одну крос-функціональну команду, це не означає, що вони завтра забудуть попередній досвід. Наприклад, спочатку вони можуть узгоджувати кожен рух з колишнім лінійним менеджером.

На зміну ментальних моделей потрібен час. Насамперед зрозумійте, на яких переконаннях будувалася робота. Створіть безпечне оточення, щоб люди побачили, що можна відкрито говорити про проблеми, які зазвичай замовчують. Що за помилки тепер не карають, оскільки це теж частина циклу зворотного зв'язку, а нові знання роблять команду розумнішою. Добре, коли є підтримка коуча, зовнішнього чи внутрішнього, який працює з командою, але не є її зацікавленим учасником і може дати зворотний зв'язок. Усе це допомагає розбудовувати систему взаємодії. Як результат ми отримаємо learning organization – компанію, яка постійно навчається та «шерить» свої знання. Але це тривалий процес, його встановлення займає від року. Зате потім зміни відчуваються буквально з порога – одразу помічаєш, що в компанії люди активно комунікують, усі переговори зайняті, а стіни рясніють візуалізацією.

Євген: Якщо у вас в руках молоток, все довкола перетвориться на цвяхи. Тому слід враховувати, що саме компанія хоче покращити. Наприклад, канбан допомагає зрозуміти та оптимізувати виробничий end-to-end process, скрам – продуктову розробку. Це взаємодоповнюючі речі. Але я знаю організації, які не мають ані канбана, ані скраму – і при цьому вони дуже гнучкі. Холакратія з боку може здатися хаосом, але це теж чудова гнучка модель для зрілих команд. Хоча і присутність ієрархії – це непогано. Важливо, що менеджер робить у цій ієрархії: роздає завдання «дуерам» чи допомагає людям розвивати ідеї та досягати результатів. Структура може бути будь-якою. Фреймворки включають багато елементів, і команда сама визначає, що їй потрібно. Можна вигадати й власну систему, яка спрацює.

Євген: Про це рідко говорять, але до того, як говорити про фреймворки, читати, наприклад, Джефа Сазерленда або Майка Кона, має сенс розібратися в глибинних засадах побудови організацій. Варто почитати книги про спіральну динаміку, теорію хаосу, системне мислення, наприклад, «П'ята дисципліна» Пітера Сенге. Ознайомитись з концепціями кайдзен та Lean – це основа, а також моделлю Cynefin, яку запропонував Дейв Сноуден. Рекомендую книги Нассима Талеба – «Чорний лебідь» та «Антикрихкість». Тому що agile допомагає будувати антитендітні системи, які з кожним витком покращуються на основі свого досвіду. Agile набагато глибше відомих всім слів «скрам» та «канбан».

Євген: Такі люди вітають командну роботу і ставлять загальні результати вище за особисті. Мабуть, це основний патерн поведінки. Але чи можна виявити його на співбесіді? Складно сказати. На співбесідах все брешуть, і на запитання «Чи командний ви гравець?» дадуть відповідь те, що ви хочете почути. Все пізнається «у бою». Але зазвичай люди, які не підтримують agile майнт-сет, потрапляючи до таких груп, незабаром йдуть. Загалом у команді потрібні різні люди: збалансована система працює краще.

Євген: Цей інструмент включає всього три кроки: Mobilize (приміщення, в якому «мобілізується» команда), Visualize (дошка, на якій візуалізується робочий процес), Ritualize («ритуали», регулярні зустрічі у своєму просторі біля дошки). Але це можна застосувати, наприклад, в HR-командах, для IT він занадто простий. Хоча це можуть бути перші кроки.

Євген: З другого курсу я почав працювати у сфері IT на позиціях Project Manager. З 2011 року почав вивчати та застосовувати agile, потім отримав сертифікацію Scrum Master. Останні два роки ми з компанією Scrum Ukraine займаємося організаційним консалтингом та проєктами agile-трансформації. У нашому портфелі є як продуктові IT-компанії, так і інші великі організації, наприклад банки — Райффайзен Банк Аваль, УкрСиббанк, ПУМБ. Тема agile цікава мені тому, що я вірю: змінюючи організації, роблячи людей щасливішими в рамках компанії, можна змінити країну. Коли починаєш по-іншому працювати, легко зрозуміти, наскільки все взаємопов'язано. Розуміючи щось нове про роботу та про себе, вкладаючи душу в те, що робиш – хочеш вкладати більше й у навколишній світ.

Євген: В особистій ефективності все дуже індивідуально. Звісно, ​​можна жити спринтами. Але це складно – я пробував. Багато речей продовжуєш робити тільки тому, що «закомітився» на весь тиждень. Зникає фан та емоції. А життя має бути непередбачуваним – тоді від нього можна взяти найкраще.

Діалог вела Катя Маєвська