Питання масштабування команд часто з’являється у порядку денному топ-менеджерів, коли перед ними відкриваються нові можливості — швидко отримати дохід, отримати суттєві інвестиції, вивести компанію на вищий рівень тощо.
Дев’ять вагітних не народять за один місяць.
Народна мудрість
Чому керівники беруться масштабувати продуктові команди?
Питання масштабування команд часто з’являється у порядку денному топ-менеджерів, коли перед ними відкриваються нові можливості — швидко отримати дохід, отримати суттєві інвестиції, вивести компанію на вищий рівень тощо.
Усе це зазвичай пов’язане із просуванням нового продукту на ринок (бажано, зробити це швидко, щоб обійти конкурентів). Та спочатку його потрібно розробити, що передбачає впровадження сучасних гнучких підходів, де лідером є Scrum.
Розуміючи “скрам” чи ні, представники бізнесу (банківської, авіаційної, нафто-промислової та інших галузей) звертаються до ІТ-компаній і ставлять завдання: терміново і якнайшвидше створити продукт.
Продуктом може бути нова функціональність уже готового програмного забезпечення, створення нової послуги, задоволення потреб бізнесу (наприклад, у царині кібербезпеки, захисту даних, автоматизації процесів) тощо.
Одне з питань, що найбільше хвилює будь-який бізнес, — вартість реалізації проекту, на яку впливають такі чинники:
- Складність завдання (чи потрібно залучати науковий потенціал, чи існують готові й аналогічні рішення, що можуть прискорити розробку, чи є необхідність залучати додаткові технології або експертизу з інших галузей тощо).
- Вимоги щодо продукту (випливають із потреб споживачів та завдань бізнесу).
- Аналіз вартості аналогічних продуктів.
- Попередній розрахунок людського ресурсу, необхідного для реалізації продукту.
- Розрахунки звичайних економічних чинників, що впливають на вартість (витрати постійні, витрати змінні тощо).
Керуючись даними попереднього аналізу і власною експертизою, топ-менеджери доходять висновку: для реалізації проекту потрібно, умовно кажучи, 100 фахівців на шість місяців. Саме з таким “готовим рішенням” і звертаються до розробників: “Створіть нам систему автоматизації за півроку — терміново. Щоб виконати це завдання швидко, ми хочемо бачити, як над проектом працюють десять команд по десятеро осіб у кожній”.
Ось вона, міна сповільненої дії.
Чому запроваджувати Scrum одразу з великою кількістю команд небезпечно
Кейс із аерокосмічної розробки
У 2012 році мене запросили як скрам-коуча в одну із топових компаній з розробки програмного забезпечення у Східній Європі працювати над замовленням для аерокосмічної галузі.
Проект саме набирав оберти. Чималий беклог сформували (понад 1000 користувацьких історій!). Проведено попередній аналіз, розписано вимоги до продукту — зібрано достатньо даних для того, щоб розрахувати середній прогнозований термін реалізації — півтора роки. Вартість першого проекту — десять мільйонів доларів. У разі успіху відкривалися двері до значно більших можливостей.
Для всіх було очевидним те, що невеличкій скрам-команді не під силу впоратися з масштабним і складним проектом.
Щоб з’ясувати, скільки команд знадобиться, ми вирішили вирахувати средню швидкість однієї та перенести її показники на всі інші. Ця логіка була зрозумілою для обох сторін. Контракт підписали.
Доволі швидко ми залучили цілий натовп фахівців. Щомісяця додавали по 20 осіб! Мета — 12 команд.
З позиції раціо я розумів логіку менеджерів, та інтуїція скрам-коуча посилала мені сигнал тривоги.
На щастя, я саме перебував у Солт-Лейк-Сіті, штат Юта, США, на конференції, присвяченій Аджайл-маніфесту. Там мені випала честь особисто познайомитися з Кеном Швабером, одним із “батьків” Scrum. Я зізнався Кенові, що мене непокоїла проблема одночасного запуску багатьох скрам-команд. Він уважно вислухав мій кейс, після чого дав непопулярну відповідь: “Негайно іди до топ-менеджерів і скажи їм не йти цим шляхом! Ви конче провалитеся, і ось чому….”
Позиція Швабера
Кен продовжив: “Суть комплексного домену полягає у створенні релізів. Річ не у команді, яка розробляє ту чи ту функціональність. Складність масштабної розробки полягає в інтеграції. Поєднати напрацювання багатьох команд в єдиний готовий інкремент — надскладне завдання!”
— Чи випустили ви уже реліз із своїми командами? — уточнив Кен Швабер.
— Ні. Поки що ми зосереджені на самій розробці. Делівері ще не було.
— Коли плануєте?
— За місяць.
— От якраз і зупиніться. Зробіть спочатку перше делівері. Доти не масштабуйте нічого.
Далі Кен видав зловісне пророцтво: “Ось побачиш. Мине місяць. До вас прийде замовник і скаже: я вже нічого не хочу. Зробіть хоч щось, чим наші клієнти могли б користуватися”.
Кен порадив сформувати одну скрам-команду, яка інтегрує всі напрацювання, щоб зробити перший реліз. Якщо вдасться це зробити, то можна поступово нарощувати “виробничу потужність”.
Я повернувся до Києва й одразу передав своїм босам послання Швабера, на що почув таку відповідь: “Славо, язик на замок! Роби собі тихенько свою справу. Десять мільйонів доларів у нашій кишені”.
Менеджери справді були налаштовані оптимістично. Тоді ми домовилися: якщо таки зуміємо втілити свою авантюру, то напишемо книгу “Помилка Швабера”.
Невдовзі ми зрозуміли, що писати нам доведеться іншу книгу. Все сталося так, як провіщав Кен. Прийшов замовник і слово-в-слово передав його послання.
Наслідки
Ми саме закінчили формувати дванадцяту команду… Проте слово замовника — закон. Інтеграцією зайнялася одна скрам-команда. Всіх інших поставили на паузу на декілька місяців.
Згодом понад сто фахівців залишилося на вулиці. Проект закрили як фейл. Компанія отримала негативний рейтинг за напрямом “аерокосмічна розробка”. Кілька мільйонів доларів потрапило на її рахунок, та у довготривалій перспективі компанія втратила мільйони доларів від недоотриманих прибутків від аерокосмічної галузі й зазнала непоправних репутаційних втрат.
Інші кейси
Цікаво, що таких кейсів багато.
Минуло майже десять років. Одна компанія запросила мене як скрам-коуча. Гроші були, але фахівців для вчасного завершення роботи над складним продуктом бракувало. Тож менеджери вирішили найняти додатково дві команди з аутсорсу — інкогніто, щоб не привертати зайву увагу.
Я їм сказав (уже на третій тиждень роботи!) щось схоже на зловісне пророцтво Швабера: “Запевняю вас, колеги, на 99%: задум провалиться. Ви втратите час і гроші”. Менеджери здивувалися: “Звідки ти це знаєш? Тобі щось відомо про ту аутсорс-компанію?”
Я просто не чув, щоб після одночасного додавання кількох команд з вулиці, ще й на півдорозі проекту, вийшло щось путнє за короткий час.
Наслідки рішення управлінців: запуск продукту відклали на 6 місяців!
Питання: чому топ-менеджмент не дослухається до думки професіоналів (скрам-коучів, у нашому випадку)?
Чому керівники самовпевнено приймають рішення, що вимагають фахових знань, ігноруючи думку експертів?
Нарешті успішний кейс
У фінансову кризу 2008 року чимало банків зазнало краху. Одна з причин — відсутність регулярного стрес-тестування ліквідності більшості з них.
Найбільший інвестиційний банк, що входить у десятку найпотужніших в світі за кількістю транзакцій в день, звернувся до нас із проханням розробити автоматизовану систему стрес-тестування ліквідності.
Наша рекомендація здивувала менеджерів: “Знайдіть найкращих 10 людей, не більше. Дайте їм кілька місяців на те, щоб сфокусуватися на кожній ітерації, кожному спринті, для створення інтегрованого продукту. Це дасть нам змогу побачити, як насправді працює команда, з якою швидкістю і продуктивністю. Після цього можемо продовжити нашу розмову про масштабування скрам-команд”.
Менеджери мали протилежний план — запустити багато команд, ще й одразу! Ми жорстко відповіли, що в такому разі не зможемо співпрацювати через високий ризик невдалого результату.
Нашу думку почули. Коли з’ясувалося, що швидкість команди удвічі менша, ніж очікувані розрахунки менеджерів, ми відчули холодок поза шкірою. Не дивно, що деякі керівники лютували й тиснули на пришвидшення темпів удвічі.
Реалістично оцінивши ситуацію, ми постановили зробити за півроку тільки найцінніше і найпотрібніше.
Ми чіткіше сформували продуктову мету і таки створили продукт. Він не мав усіх дрібничок і забаганок, але виявився напрочуд якісним і задовольняв усі найголовніші потреби замовника, серед яких — безпека, надійність, точність.
Згодом ми дізналися, що то був перший випадок запуску продукту “без головного болю” у контексті банку.
Працювали над тим продуктом ми разом із моїм теперішнім партнером, співзасновником Agile.Live, Сергієм Прохоренком — одним із провідних фахівців із масштабування гнучкої розробки SAFe (Scaled Agile Framework).
Вишенькою на тору була персональна подяка топ-менеджера банку, який отримав саме те, що хотів.
Помилки бізнесменів у ІТ-рішеннях
З огляду на зазначені проблеми, хочу виокремити кілька типових помилок, на які варто звернути увагу кожному керівнику:
- “І швець, і жнець, і на дуду грець” — ілюзія фаховості у всьому.
- Нерозуміння скрам-підходу.
- Нерозуміння ролі команди в скрам зокрема.
- Нерозуміння труднощів рекрутингу фахівців інтелектуальної сфери.
- Нерозуміння моделі Такмана щодо формування команди й відповідної кількості часу: Forming → Storming → Norming → Performing.
Рекомендації
- Для успішного масштабування варто дати простір одній команді (не більше 10 учасників) для того, щоб зосередитися на якісних ітераціях, створенні цінного інкременту та регулярних релізах.
- Про вдале масштабування варто говорити, маючи хоча б одну вдалу скрам-команду.
- Те ж саме стосується стратегії інвестування. Ефективна скрам-команда створює можливість природно й поступово нарощувати інвестиційну потужність паралельно з таким же природним і поступовим масштабуванням.
- Сама команда має вирішувати, як часто, скількох і яких нових людей потрібно додавати(наприклад, раз у місяць, а за досягненні певної кількості утворювати дві команди, після чого природним чином — три і так далі).
Поступовий природний розвиток допомагає вчасно й безболісно усувати “залежності” команд одна від одної та швидко досягати необхідної інтеграції у створенні цінного інкременту. Цей підхід ми називаємо органічним масштабуванням.
Позиція скраму
Важливо знати офіційну позицію скрам-підходу. За посібником Scrum Guide 2020, незалежно від кількості команд, у Скрамі на один продукт можуть бути тільки:
- Один беклог продукту (product backlog).
- Один власник продукту (Product Owner).
- Одна мета продукту (product goal).
- Єдина екосистема для всіх команд
- Єдиний інтегрований інкремент.
Звідси, власне, й витікала порада Кена Швабера.
Висновки
- Менеджерам варто пам’ятати: дев’ять жінок не народять дитину за один місяць.
- Коли йдеться про великі гроші, великі проекти, великі команди, то керівники схильні покладатися на власну компетентність і не чути голосу скрам-коучів та інших фахівців, через що наступають на ті самі граблі й втрачають.
- Лідерам не варто приписувати собі компетентність, якої в них насправді немає.
- Керівникам конче необхідно радитися зі спеціалістами, що володіють фаховими знаннями.
- Менеджерам необхідно зрозуміти стратегію органічного масштабування (починаючи від однієї скрам-команди з 5-10 осіб).
- Ми не рекомендуємо розпочинати проект із одночасного запуску багатьох скрам-команд (крім випадків трансформації вже існуючих великих команд за допомогою SAFe).
- Запроваджуючи Scrum для масштабного проекту, варто спочатку створити належні умови для функціонування “десятьох”.
- Керівникам варто усунути бюрократичні та інші перепони на шляху функціонування скрам-команди, якщо вони прагнуть справжньої цифрової трансформації компанії та передових позицій на ринку.
Автор: Слава Москаленко
Рекомендовані статті про скрам-команди та масштабування
П’ять рівнів переходу на Agile: самокеровані команди
Рольова модель Scrum
Рольова модель Scrum: як виникла і чому важлива
Самокеровані та самоорганізовані команди: Початок
Мій перший фейл у запровадженні аджайл-культури
SAFe: Які компанії потребують масштабування?
ДОЛУЧИТИСЯ ДО AGILE.LIVE
- Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Product Owner (PSPO), Advanced Scrum Master with PSM II Certification
- Підписатися на сторінку у LinkedIn
- Підписатися на Telegram-канал Agile.Live
- Підписатися на You-канал Agile.Live