Чи справді вам потрібні гнучкі методології? Коли і як впроваджувати Agile
DOU запросив досвідчених експертів з Agile — Артема Биковця, CEO Simplesense, Ярослава Бондарчука, Delivery Management Consultant в Intellias, та Ярослава Новосьолова, Agile Coach в Fozzy Group, — щоб обговорити, як впроваджувати цю методологію, уникати помилок, а також з’ясувати, коли Agile не допоможе.
Та перш ніж читати тези розмови, підпишіться на YouTube-канал DOU, щоб не пропустити нові відео.
Де застосовують Agile
Чи варто в усіх проєктах використовувати Agile? Які є критерії? (1:43)
Ярослав Новосьолов: Agile — це про систему цінностей, яка об’єднує те, що раніше називалося lightweight methodology. І проста відповідь така: якщо вам не підходять класичні підходи, то, мабуть, підійде щось з Agile.
Варто застосовувати принципи Agile, коли є висока невизначеність і ви розробляєте продукт. Але, наприклад, коли беремося за софт, який уже робили багато разів, або маємо суворі обмеження — тут гнучкі методології, можливо, не допоможуть.
Артем Биковець: Брати Agile, а потім думати, потрібен він чи ні, не варто. Треба починати з визначення: що ми за компанія, чого прагнемо, які цілі, що хочемо дати користувачам, клієнтам. Бо Agile — це не зовсім про процеси, це більше про спосіб мислення, а іноді це називають ледь не філософією. Він охоплює 4 цінності, 12 принципів. Це маніфест, в якому люди через досвід і набиті гулі виклали своє бачення. Agile з’явився як квінтесенція багаторічної практики.
Ярослав Бондарчук: Підтримаю колег стосовно адаптивності. У будь-якому разі Agile не має бути самоціллю. Чому так всі ненавидять Agile? Бо, коли ми, не зовсім розуміючи власні потреби, намагаємось робити Agile, з’ясовуємо, що не готові бути гнучкими.
На що може впливати Agile
На що не може вплинути Agile? (8:10)
Артем Биковець: Agile ні на що не впливає itself, бо це просто рекомендований підхід до того, якими принципами можна керуватись, щоб організація була більш адаптивною. Що це означає? Наприклад, я зранку прокинувся, маю план дій, а мені кажуть, що на територію садочку, куди ходить моя дитина, залетіли дикі бджоли, і мені треба її забрати звідти. Треба бути адаптивним.
Тобто адаптивність — це моя властивість як системи, наскільки швидко і легко я можу змінити напрямок руху, скільки мені це буде коштувати часу і грошей. Agile може вплинути на те, чи будете ви або більш гнучкі, адаптивні, або менш.
Часто люди позначають цим словом, наприклад, відсутність документації або перемикання із задачі на задачі. Тобто помилково мають на увазі «погані процеси», що дратують, заважають професійно виконувати обов’язки і приносити користь. Але ж один з принципів Agile чітко каже: continuing attention to technical accense, тобто вимагає постійної уваги до технічної досконалості та проєктування, щоб підвищувати гнучкість. Але хто там читав? Мовляв, Agile — це «фігак-фігак» і в продакшн, але ні, це вже by definition не Agile.
Ярослав Новосьолов: Я стикаюся з хейтом від тих, хто працює інакше і не готовий перебудовувати свої звички. Найгірше, коли менеджмент хоче щось покращити, не змінюючи своїх цінностей і майндсету.
Ярослав Бондарчук: Нерідко трансформація компанії — це зовсім не те, що потрібно людям, у них «болить» в іншому місці. Можливо, цінності Agile і справді класні, вони їм подобаються, але поки не будуть вирішені базові потреби, жодних змін не буде. Інколи консультант думає, що точно знає, що краще для організації, але це не завжди так.
Артем Биковець: Справді в наборі цінностей нічого поганого немає. Але відбувається якось так: бог Agile зайшов в храм, викинули бога Waterfall. І тепер називають будь-що аджайлом: багато мітингів, постійні зміни планів (одна компанія навіть сказала мені: «Мы компания с високой динамикой приоритетов», коментуючи десятки змін у планах протягом року).
А найбільше Agile ненавидить мідл-менеджмент. Бо ці люди
Важливо роз’яснити людям, куди компанія рухається і як відбуватиметься перехід в Agile, щоб співробітники почувалися в безпеці, а не сиділи й думали, чи їх звільнять, чи зарплату зменшать, чи що це взагалі означатиме. Також з новою людиною при наймі варто проговорювати таке: «Зараз ти йдеш на цю роль, твоя робота повністю безпечна, поки виконуєш ті зобов’язання, які на себе береш, в тебе буде зарплатня і всі інші соціальні гарантії, але в якийсь момент ми можемо змінити твою долю і запропонувати щось інше. Ми відкриті, але очікуємо від тебе такої ж відкритості до змін». Ось про це важливо не забувати.
Помилки у впровадженні
Які основні помилки під час провадження Agile? (26:54)
Ярослав Бондарчук: Одна з найбільших помилок — це коли думаєш, що точно знаєш, що цій компанії потрібно, і, не з’ясувавши потреб людей, намагаєшся запропонувати конкретний фреймворк. І що більш революційною буде зміна, то більша ймовірність зафейлити й піти не в той бік.
Ярослав Новосьолов: Помилка, коли починають робити карго-культ, тобто без розуміння повторюють певні практики. Інша помилка — коли люди знають навіщо, але не розуміють, що для того, щоб це «навіщо» сталося, треба змінитись і працювати над собою. І ще одна помилка — починати будь-які зміни без готовності помилятися.
Артем Биковець: Одна з помилок — CopyPaste трансформація, коли читаєш про успіх якоїсь компанії і кажеш: «О, хочу, як у них». І починаєш те, що вже є, називати іншими словами. Наприклад, є група бекендерів, які спілкуються, обмінюються досвідом, і ми називаємо їх гільдією. Тепер у нас є гільдія, як у Spotify.
Або коли кажуть: «Ми хочемо Scrum, але натягнемо його на нинішню організаційну структуру і змінювати нічого не будемо». Потім топи оплачують рахунок за трансформацію і звітують СЕО: пройшла Agile-трансформація, давай мені підвищення і премію.
Є два виходи з цього кейсу. Перший — це коли СЕО, не дивлячись, каже: «Клас, тепер наша компанія Аgile», дає інтерв’ю умовному Forbes і розповідає, як вони стали Agile-компанією. А співробітники роблять фейспалм і бідкаються. Або другий варіант — СЕО йде в народ, запитує людей, дивиться на бізнес-показники і бачить, що time-to-market лишився той самий, кількість дефектів не змінилась, замовники та користувачі незадоволені результатами. Тоді звільняють трансформатора і шукають іншого.
А що ж відбувається з цим трансформатором? У нього в резюме буде написано: Big Company from Fortune 500, I’ve successfully finished Agile transformation. І він нарозхват, 10 компаній стають у чергу, б’ються за нього і дають йому високу зарплатню. І цей трансформатор зробить ще одній компанії таке чудове фейкове щеплення від комплексності.
Ярослав Новосьолов: До речі, інколи від Agile очікують більшу швидкість масштабування, і це теж велика помилка. Бо думають, що якщо до команди, яка бігла з певною швидкістю, додати ще дві, то разом вони бігтимуть втричі швидше. Що стається насправді: люди з першої команди починають вчити новачків, ті проходять процеси онбордингу, тож спершу значно втрачається темп.
Артем Биковець: На червоній обкладинці книги маркетологи написали: «Scrum. Doing twice at the same time», або «Скрам. Навчись роби вдвічі більше за той самий час». Треба правильно трактувати ці слова. Agile і Scrum — це різні речі. Agile — 4 цінності і 12 принципів, Scrum — це фреймворк, який на рівні практик показує, як їх застосувати.
Уявімо: є пиріжкова, і ви вирішили впроваджувати Agile «у стиснуті строки». Тепер продавчиня щоранку синхронізується по 15 хвилин з тими, хто їй привозить продукцію. Позавчора спекли 100 пиріжків, продали 75, сьогодні планують продати решту. І що, з того самого тіста й за ті самі гроші тепер будуть продавати вдвічі більше пиріжків? Навряд чи, це так не працює.
Що означає вдвічі швидше за той самий час? Це про швидкість delivery, бо ми працюємо інкрементально, тому декомпозуємо, відкусуємо те, що найнеобхідніше, найтерміновіше, і якомога швидше це постачаємо клієнту. Для чого? Щоб отримати фідбек, якщо робимо щось зовсім не те, наш користувач чи замовник скаже: «Воу, це не те, що я хотів, що ви робите?». І ми такі: «Слава богу, що ми дізналися про це через два тижні, а не за пів року, як було раніше». Продукт не треба робити одним пострілом, це щось живе, він має еволюціонувати й може повністю змінюватися багато разів.
Ярослав Новосьолов: Якщо ви дуже довго будете щось якісне робити, то можете втратити момент, коли це потрібно людям. Як це зробити швидше? От про цю швидкість Agile.
Ярослав Бондарчук: Коли говорять про скрам, часто згадують про максимізацію незробленої роботи. Саме через якісь втрати можна розмовляти з бізнесом про те, де можливе поліпшення, адаптація, як зекомонити гроші. Доносити йому важливість, показувати місця, де він потенційно втрачає.
Як стати Agile Coach
Наскільки потрібні сертифікації і тренінги, щоб стати Agile Coach? Як стати Agile Coach? (48:16)
Ярослав Новосьолов: Сертифікат не є оцінкою вашої кваліфікації. Це просто документ, що вам дали знання, а чи ви їх засвоїли — ще питання. Якщо ви щось пробуєте нове на роботі, сходіть на тренінг для того, щоб розкласти все по поличках, зрозуміти, де ви маєте слушність, а де варто зробити інакше.
Артем Биковець: Щоб стати хорошим Agile-коучем, треба вийти з передової та еволюціонувати в цього фахівця. Тобто попрацювати в командах, побачити, як не збираються білди, вилазять дефекти після релізів, довго триває brainstorm, скільки часу йде на задачу, зрозуміти, що замовники взагалі від нас хочуть.
Корисно попрацювати в різних сетапах на зразок аутсорсу, аутстафу, продукту. І не мовчати, якщо щось не подобається, пропонувати зміни.
Які треба отримати сертифікати та що робити, щоб стати Agile Coach? Залежить від того, чого саме ви прагнете. Якщо хочете, щоб у вас в резюме було просто написано Agile Coach, можна ходити на відповідні співбесіди, поки вас кудись не візьмуть. А перед тим отримати сертифікацію. Це не складно, треба лише кілька сотень баксів заплатити.
Але якщо ми кажемо про не просто title, а про скілсет, про користь для організації, щоб коментарі «самый безполезный человек на проекте» вас не стосувалися, то готуйтесь гарувати.
Ярослав Бондарчук: Насправді одна з цілей скрам-майстра — зробити себе непотрібними на проєкті, в команді, організації, але дуже бажаними при цьому.
Де компанії взяти Scrum Master
У рамках трансформації краще натренувати внутрішніх скрам-майстрів чи найняти зовнішніх? (57:20)
Ярослав Новосьолов: Я вважаю, що найкращий підхід — міксувати. У нашій компанії є люди, яким не байдужий розвиток компанії, але які можуть мати складнощі з тим, як правильно прийти до того, чого хочемо. І круто, коли приєднуються спеціалісти, які знають, як впроваджувати зміни, які цей шлях вже проходили і які разом будуть утворювати сильну коаліцію. Але якщо ви будете наймати людей зовні, які не знають контексту, є велика ймовірність того, що команда не буде сприймати їх за своїх. Тому моя відповідь: міксувати залежно від зрілості команд, людей, від готовності до змін.
Ярослав Бондарчук: Підтримую думку, що має бути баланс між зовнішніми і внутрішніми людьми. У Берна було три правила щодо організації. Перше — вона намагається вижити за будь-яку ціну. Друге — структури, які в організації були сформовані історично, психологічно формують динаміку між людьми. І третє — це те, що сплетіння однієї структури людей і тієї динаміки, яка між ними існує, формує організаційну культуру, яку так часто згадують.
Культура охоплює сценарій організації, оскільки компанія має здатність поглинати людину. І коли немає зовнішнього втручання, фахівцям всередині важко змінюватися.
Артем Биковець: Думка така — потрібен мікс. Співробітники заслуговують, щоб їм дали шанс впроваджувати те, за що вони боролися. Бо із зовнішнім консультантом може бути конкуренція, а нам потрібна співпраця. А ще у людей з компанії є глибока експертиза, розуміння контексту, в якому вони перебувають, культурних, політичних особливостей, яких неможливо уникнути. Але без зовнішнього погляду ніяк: консультант може принести більш широку експертизу.
Ярослав Новосьолов: До речі, ви всередині компанії можете казати дуже правильні речі, але до вас просто не будуть дослухатися. Проте дослухаються до людини зовні.
Факапи у впровадженні Agile
Які ваші найбільші факапи трансформації бізнесу або компаній? (1:11:18)
Артем Биковець: Працював в одній компанії, яка на той час називалась BetLab. Ми будували продукт, і я прийшов, коли нас було ще 25 чи 27 людей. Ми тільки вчились робити Scrum, це, мабуть, був такий скрамчик, який тільки навчився ходити. І у нас були хороші практики: парне програмування, сode review, кросфункціональні команди, ми вчилися одне в одного технологій, стеку. І все було яскраво і гарно. Але в якийсь момент бізнес поставив амбітну ціль, і ми почали швидко наймати людей. За пів року зросли з 32 до 102 фахівців, якщо я не помиляюсь. Команди виникали одна за одною, приходили якісь люди, а ти навіть не знав, хто вони, ще не встиг познайомитись. Хоча раз на тиждень ми робили мітинги, щоб всі одне з одним спілкувалися.
Тож почали масштабувати Scrum, і я був скрам-майстром трьох команд одночасно. По-перше, не треба так робити. Знаєте, якщо у мами три дитини одного віку, то одна залишається без їжі на певний час. От так у скрам-майстра: одна команда постійно недоглянута. І мій особистий факап: я надавав преференції тим командам, з якими починав, і вважав, що моя місія — зробити їх найкращими. Ми перейшли межу і почали конкурувати. Ми більше показували на демо, більше робили, мали менше дефектів, попереду всіх лізли, тому що знали, як це виконати краще.
В якийсь момент я переконався, що вже працюю не на бізнес, а на свої команди. І для мене це були різні сутності. Тобто є команда, а є бізнес, і ми одне проти одного, я на якійсь одній стороні.
Що я взяв з цього досвіду? Що не можна забувати, на кого працюєш. Не важливо, ти Agile Coach чи програміст, тебе хтось найняв. Зазвичай це певна компанія, де є люди, які тобі можуть подобатися чи не подобатися, але ти маєш приносити користь. Agile Coach чи скрам-майстер не повинен підтримувати конкуренцію. Він має допомагати іншим командам правильно інтегруватися, не наздоганяти, а вирівнюватись в компетенціях.
Ярослав Новосьолов: Один з моїх фейлів пов’язаний з питанням «Навіщо вам трансформація?». Разом з Agile-командами ми працювали над системою оцінки 360, і ось я дізнався, навіщо це потрібно. Виявилось, що у власника був такий принцип кожний квартал звільняти 10% відсотків співробітників і наймати 10% нових фахівців. У мене було враження, що я в гестапо прийшов Agile впроваджувати. Тепер точно знаю, що варто питати, навіщо будь-які зміни.
Ярослав Бондарчук: Розповім про трансформацію шести команд у R&D, які з часом зросли. Вирішили запустити одну фіча-команду, а решта лишались компонентними. Це було не дуже добре рішення, оскільки ми створили конфлікт між цією командою та іншими, які захищали свої компоненти і не давали можливості з ними працювати. На папері наче всі погодилися, але де-факто люди не хотіли змінювати статус: зручно, коли кожен свій компонент ідеально вилизав, а тепер фіча-команда стала цапом-відбувайлом. Проблема була на рівні організації та міжкомандної взаємодії, і такі речі треба доносити менеджерам
Коли багато проєктів
Яку б ви порадили методологію, коли команда одна, а проєктів багато? (1:36:14)
Артем Биковець: У продуктовій розробці можна працювати над проєктами, але результат кожного з них має приносити користь кінцевому продукту. Scrum будується навколо продуктової розробки, і байдуже, скільки проєктів припадатиме на одну команду. Вони всі мають потрапити в один беклог і бути впорядковані єдиним продукт-оунером — власником цього продукту. А власник — це не бізнес-аналітик «підвищеної якості» з вищою зарплатнею, це реальна людина, співвласник або інвестор, який реально відчуває відповідальність за успіх або неуспіх продукту на ринку. І якщо ця людина навчиться декомпозувати проєкти, вирівнювати пріоритезацію так, щоб команди кожної ітерації працювали над найнеобхіднішим, найкритичнішим, найтерміновішим, найважливішим, то це буде гарною Аgile-роботою однієї команди над багатьма проєктами.
Ярослав Бондарчук: А якщо це проєкти, які формуються не навколо одного продукту або ми не знаємо, що це за продукт? Тоді складно їх згуртувати у спринт, який, своєю чергою, має контриб’ютити в product goal, якого ще немає, тому що немає продукту. Навколо чого команда має об’єднувати свої зусилля, де той vision, де кінцева зірка, до якої ми всі йдемо, і чи є вона взагалі?
Тому, можливо, для таких кейсів Scrum не є найкращим вибором. Я не знаю, що було б найкращим, бо є багато факторів. Але не думаю, що скрам.
Майбутнє і тренди
Що прийде на зміну Agile? (2:01:08)
Артем Биковець: Для мене Agile — це одна з ниточок еволюції управління людьми, організаціями, проєктами в тих сферах, де є підвищена невизначеність і комплексність. І світ продовжує пришвидшуватися, він непередбачуваний і невідомий. Тому думаю, що Agile буде розвиватись.
Можливо, навпаки, буде пушбек і ми знову скажемо, що ні, треба вузькоспеціалізовані спеціалісти, конвеєр, щоб усе по черзі робити.
Ярослав Бондарчук: Мені здається, що майбутнє вже настало, просто воно не рівномірно розподілено. Є племена в Африці, а є технології в Сингапурі. Відповідно для когось Agile — це норма, хтось ще не пустив його і на поріг, а хтось пішов далі. Для мене логічний розвиток полягає в тому, що ті чотири цінності, які існують, будуть розширюватися. Я бачу спіральне зростання того, що вже є.
Ярослав Новосьолов: Нині з Agile асоціюється багато речей, які починалися зовсім не в Agile. Наприклад, є такі моделі, як Dual-track Аgile або Diamond Agile. А коли Scrum починався, то в одній зі статей Кен Швабер писав, що його ідея полягала в тому, щоб відірвані від команди розробки UX-спеціалісти нарешті почали з кимось співпрацювати.
Тому мій прогноз такий, що всі затребувані речі будуть просто доповнювати Agilе. Це не епоха Agile, а епоха, яка почалась з Agile. Вона доповнюється. А коли Agile стане не потрібен, наприклад, ми доживемо до часів, коли штучний інтелект заздалегідь даватиме відповіді на питання в умовах дуже високої невизначеності, то не треба буде експериментувати й витрачати так багато зусиль. Тоді Agile буде не потрібний, а може, разом з ним і всі інші методи.
