Scrum може бути корисний навіть компанії та організації, які не шукають і не потребують Agile-трансформації. Але виникає питання: які саме проєкти можна «довірити» скраму? Співзасновник Agile.Live Слава Москаленко розповідає про досвід запровадження скраму в одному з проєктів глобального авіаперевізника.
З початком пандемія Covid-19 та запровадження карантинних обмежень по всьому світу у нас з’явився клієнт – одна з найбільших у світі авіаційних компаній. Керівництво поставило завдання розробити рішення, яке б інтегрувалося в систему управління бронюванням квитків – manage booking system. Кожна сучасна авіакомпанія світу має свої застосунки, в яких можна керувати власним бронюванням: проходити онлайн реєстрацію на рейс; міняти місця у літаку, замовити їжу тощо. Клієнт бажав швидко додати функціонал з опрацювання ковід-сертифікатів, який би завантажував потрібні медичні документи, робив верифікацію для зменшення бюрократії в аеропорту.
На початку карантину пасажири часто стикалися з неприємними ситуаціями — їхні ковід-сертифікати не відповідали вимогам, тому вони пропускати рейси в очікуванні потрібного документу. Запровадження подібного додаткового функціоналу серйозно підвищило б лояльність клієнтів.
Компанія, яка ніколи не впроваджувала гнучкі підходи і працювала за традиційними методами, вирішила робити цей проект по скраму. Згідно із планами, внутрішня команда за 2-3 місяці повинна була запустити цифрове рішення на рівні MVP – доступна усім клієнтам автоматизація. Однак проект затягнувся на півроку, а MVP, який можна було дати клієнту так і не запрацював.
Компанія побачила, що щось пішло не так: проблеми з контролем та управлінням ризиків, низький динамізм у створенні рішення. Тоді керівництво звернулося до зовнішніх консультантів, які б допомогли їм швидко вивести функцію на ринок і підвищити конкурентоспроможність компаній.
Буквально через місяць після нашого приходу як консультантів вдалося зробити перший продуктовий реліз (Production Release). Далі ми запровадили систему, завдяки якій кожні два тижні випускали релізи – з’являлися нові фічі, функціонал, які ми інкрементально додавали до продукту. У підсумку ми досить швидко реалізували важливий і критичний для компанії проект, в якому постійно змінювались вимоги та було невдоволення від стейкхолдерів. У підсумку продукт запрацював для клієнтів компанії, а самі авіалінії зберегли лідерство у галузі у кризовий період.
Що саме ми зробили?
Наш клієнт, що працює за вотерфольним підходом, зробив правильне рішення – розробити критичний функціонал у стислий час за допомогою скраму. Але всередині компанії не знайшовся власний експерт, який би міг взяти на себе роль скрам-майстра та відповідальність за створення продукту.
Тому запит від клієнта був досить простий: не треба коучити команди з тренінгами і воркшопами, системно впроваджувати Agile, переводити всі команди та проєкти з вотерфолу на скрам. Була необхідність чітко, швидко і динамічно зробити ризиковий, критичний проєкт.
Відсутність сильного скрам-майстра давала взнаки:
1) команда збирається, багато робить, але немає чіткого розуміння стратегії і дорожньої карти самого продукту.
2) були відсутні прозорі комунікації між бізнесом, менеджерами, продуктовою командою, власниками продукту самої команди. Люди брали відповідальність не за кінцевий успіх, а лише за свій фронт робіт.
Перше з чого ми почали нашу роботу – це вивчили культуру взаємовідносин. По-друге, для досягнення комунікації між людьми ми боролися з пасивністю. Стимулювали людей активніше входити в процес розробки, пропонувати свої ідеї: чому не можемо запустити MVP в продакшн? яких речей не вистачає? з якими спеціалістами треба поспілкуватися для вирішення труднощів?
Ключове завдання скрам-майстра у цьому проєкті було розбудити, розшевелити людей, задати імпульс. Потім ми досягнули динамізму: не у розробці, а в прийнятті рішень.
З яких проєктів треба починати скрам?
Існує хибна думка, що запроваджувати скрам в компанії чи організації треба з простих проєктів. «Обкатати» підхід на них, а потім вже каскадувати досвід на складніші проєкти. Насправді історія скраму заперечує цей підхід, бо він був “рятівним кругом” для безнадійних проєктів.
Це дуже дивно вірити, що у компаніях, де все добре функціонує, зненацька виникла ідея створити ідеальну методологію, яку б протестували та почали використовувати в кращих проєктах.
Історично скрам почали застосовувати у двох випадках: а) критичні проєкти для компанії, бізнесу, організації; б) проєкт рухається у неправильному напрямку – розтягується у термінах, з’являється низка помилок та проблем.
Як раз для вирішення цих двох ситуацій запрошували Кена Швабера і Джеффа Сазерленда. Відомий кейс Швабера як він врятував ФБР – виправив проблеми системи управління справами Sentinel, яка покликана замінити цифрові і паперові процеси на цифрові під час розслідувань.
Візьміть найризикованіший та найкритичніший проєкт — це буде найкращий варіант, щоб обкатати скрам.
Інгредієнти порятунку продукту скрамом
По-перше, керівництву організації та відповідальним за результат варто змиритися, що підсумком впровадження скраму і того, що буде на виході – це не те що вони очікують.
Скрам допоможе зрозуміти реальну ситуацію і приймати правильні рішення, аби витягнути максимум з безнадійних, ризикованих і проблемних проєктів.
По-друге, це запрошення компетентної та авторитетної людини, яка розуміє проблематику, буде казати що є правильним, а що ні. До цієї людини дослухатимуться. Ця персона розуміє комплексність: чому в складних проєктах виникає багато пожеж. Адже вони лежать в площині емпіричного управління проєктом. А виправлення спирається не на прогнози, а на актуальні дані та реальності, в якій знаходимося.
В ідеалі таким запрошеним експертом на позицію скрам-майстра є Кен Швабер. Звісно, це мало вірогідно, але це приклад та орієнтир того, хто потрібен організації.
Часто компанії у пошуках Agile-коуча, хоча їм потрібен кваліфікований скрам-майстер, який прийде і без зайвих сесій, тренінгів і коучінгу візьме на себе відповідальність за реалізацію проєкту.
Скрам – це релігія чи «одноразовий скальпель»?
На цьому кейсі я зайвий раз переконався, що багатьом компаніям не потрібен Agile і Scrum на рівні всіх команд. У різних компаній є свій бізнес, налаштовані процеси. І допоки механізм стабільно функціонує і немає «гарячої платформи», компанії не переймаються питанням Agile-трансформації.
Однак у будь-яких компаніях виникає потреба реалізовувати ризикові, критичні та складні проєкти, з великою кількістю невідомих змінних, які по своїй природі ніколи не будуть стабільними. Тому навіть компанії, які не мають Agile-культури, можуть безболісно запускати такі проєкти по скраму.
Повертаємося до нашого кейса. Ми успішно завершили проєкт. Усі сторони були задоволені співпрацею. Але компанія не стала з нього робити кейс, мовляв, тепер всі проєкти будуть по скраму.
Тут буде доречним використати метафору про «одноразовий хірургічний скальпель», який виконує критичну процедуру, де важлива стерильність для запобігання поширення інфекції. Після цього він утилізується і не використовується повторно в інших задачах.
Також скрам не є релігією, тобто догматичним набором правил, яким необхідно неухильно дотримуватися незалежно від обставин та контексту. Скрам, як будь-який інструмент, підходить до своєї ситуації.
ДОЛУЧИТИСЯ ДО AGILE.LIVE
Підписатися на сторінку у LinkedIn
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live