Чому Scrum не працює: дві проблеми компаній з продуктовими командами

Для успішного запуску Scrum потрібно врахувати два важливі компоненти – мета та люди (кросфункціональні команди, кожен учасник якої її усвідомлює). Без розуміння мети всіма учасниками розробки існує високий ризик нівелювання скрам-підходу.

Проблема

Більшість скрам-майстрів, що приходять до нас на тренінги, а також топ-менеджерів компаній, що звертаються до нас по допомогу в запровадженні скрам-підходу або вирішенні проблем, пов’язаних із його функціонуванням, ставлять такі запитання:

1. Чому постулати Scrum в теорії прості, а реалізовувати їх на практиці складно?
2. Чому в офіційному посібнику “Скрам” (Scrum Guide) ключові поняття сформульовані чітко та зрозуміло (фрази на зразок “Скрам-команда має складатися зі скрам-майстра, власника продукту і розробників”), але роз’яснень того, як вони реально працюють в бізнесі, немає?
3. У нас свій контекст. Чому ви кажете, що ми не можемо змінити скрам?

Два ключові питання

Звісно, що питань щодо застосування Scrum у повсякденній роботі, значно більше, проте хочу наголосити на двох принципово важливих сферах, що є і причиною, і відповіддю на ці проблеми, — мета і люди:

1. Присутність єдиної мети, що об’єднує всіх учасників розробки.
2. Належне функціонування скрам-команди.

1. Мета

Спостерігаючи за грою київського “Динамо”, у багатьох уболівальників складалося враження, що футболісти забули, навіщо вийшли на поле. Вони не “грали”, а “ходили” у футбол. Довгі поперечні передачі (щоб м’яч летів якомога довше, аби не вперед), пас назад воротарю, зрештою, відсутність ударів по воротах супротивника — усе вказувало на відсутність мети. Полем пересувалося одинадцятеро професіоналів — невідомо, заради чого.

Щось схоже відбувається в бізнесі, коли менеджери запроваджують скрам, не до кінця розуміючи його специфіку. Одне з питань, яке вони часто не усвідомлюють, “Навколо чого потрібно формувати команду?” Заради якої мети?

Обидва поняття (мета і команда) тісно пов’язані між собою. Адже учасникам розробки потрібні передумови, щоб “склеїтися” в єдину кросфункціональну команду для спільної взаємодії і досягти піку своєї продуктивності. Першою цією передумовою є мета, яку розуміє кожен учасник розробки.

Кейс 1. Капелюх “Скрам”

Один із найбільших світових виробників телекомунікаційного обладнання звернувся до нас, щоб ми підвищили кваліфікацію кількох десятків скрам-майстрів, і ми не були проти.

Судячи з очікувань фахівців, що прийшли на тренінг, усі чекали на “диво”, митєві покращення й успіх завдяки генію тренера. З’ясувавши контекст, мені довелося відверто засмутити присутніх.

Річ у тім, що ззовні все відповідало вимогам посібника (Scrum Guide) — наявність команди розробників, власника продукту й скрам-майстра, беклогу продукту, спринтів, інкременту, ретроспектива та ін.), окрім одного несподіваного “нюансу”: тестувальники працювали окремо від розробників як окрема скрам-команда. Відповідно, дублювали всі елементи й артефакти, запроваджували власні спринти. З’ясувалося, що те ж саме стосувалося і дизайнерів!

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

Почувши про мету, щоб має об’єднувати всіх учасників розробки, один із учасників не витримав: “Славо, весь фреймворк, про який ти розповідаєш, у нас є, але спільної мети немає! Нам дають різні завдання, які ми просто маємо виконати, не розуміючи, навіщо. Як нам діяти?”

Більшість присутніх зрозуміла: першими на тренінг мають приходити керівники компанії. Тільки після того, як лідери по-справжньому розумітимуть специфіку скрам-команд хай навіть для пілотних проектів, буде позитивний результат. Інакше компанія втратить час, фінансові ресурси, кадри.

Цікаво, що після тренінгу учасники набралися мужності й кинули виклик керівникам: “Після тренінгу ми зрозуміли, що все, що ми тут робимо, взагалі не скрам. Вам потрібно піти на тренінг, щоб робити все правильно”.

Кейс 2. Курка без голови

Чи доводилося вам спостерігати брутальну картину відрізання голови курці? Голови вже нема, а вона досі бігає.

Щось схоже відбувалося із запуском Scrum в одному банку, що входить у десятку найбільший у світі за показником щоденних транзакцій. Його керівництво запросило мене як скрам-коуча, щоб проаналізувати поточний стан скрам-моделі (то був недоскрам) і покращити ситуацію.

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

З’ясувалося, команда не розуміла мети. То була “курка без голови”. На вході “курка” отримувала певну кількість завдань, на виході мала виконати їх.

Цікаво, що існувала особа, яка добре розуміла мету (нею був власник продукту), але ділитися знаннями з іншими й вибудовувати понятійну конструкцію на рівні всіх учасників розробки він не хотів.

Мету не було озвучено з самого початку проекту і це стало міною сповільненої дії. Якимось чином розробники поступово скотилися зі скраму у вотерфол. Спочатку програмісти виконали всю свою роботу. Після цього (в останню хвилину) кидали її тестувальникам, утворюючи технічний борг. Незавершену роботу переносили в наступний спринт. Врешті-решт, тестувальники працювали в окремому від програмістів спринті. Це важко назвати скрамом або ефективним підходом.

2. Люди

Взагалі 80-85% пілотних проектів запускаються як “недоскрам”. Керівники часто не до кінця розуміють специфіку Scrum-підходу або як він працює на практиці. Найбільше проблем виникає зі скрам-командами.

Ось перелік типових проблем:

1. Немає скрам-майстра або його роль дисфункціональна.
2. Нерозуміння ролі власника продукту.
3. Люди є, кросфункціональності немає.
4. Команда не розвивається, як цього вимагає “Скрам”.
5. В компанії різні департаменти — як їм співпрацювати у межах скрам-підходу?

У разі розрізненості й відокремленості структурних підрозділів організації одне від одного запровадити скрам-підхід надзвичайно складно. Просто прочитати посібник чи книгу недостатньо.

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

Це не раз було і в моїй практиці розробки продукту. Я персонально зустрічався з керівниками інших департаментів, чия діяльність пов’язана з розробкою продукту, щоб скоординувати дії навколо спільної мети. Реалізувати це справді непросто.

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

У разі відсутності налагодженої взаємодії між департаментами:

1. Постійно виникає напруга між різними учасниками розробки;
2. Витрачаються зайвий час, фінансові та інші ресурси;
3. Суттєво затримується реліз продукту.

Невміння або неспроможність об’єднати людей навколо мети спокушає керівників скасувати “цей експеримент”, вважаючи, що проблема в “підході”.

Тому перед запуском пілотного проекту керівникам варто поставити кілька простих питань:

1. Чи достатньо в нас фахівців для того, щоб зробити реліз? Якщо ні, скількох саме не вистачає?
2. Чи потрібна допомога спеціалістів інших галузей (із інших відділів), щоб зробити реліз? Якщо так, то яких саме? Скількох?
3. Що маємо зробити, щоб усі учасники розробки розуміли мету? (Насамперед це завдання власника продукту).

Кейс 3. Самотній департамент

Щоб зробити перехід на Scrum безпечним, ми рекомендуємо розпочати з однієї команди.

Так і зробили наші колеги з іншої консалтингової компанії, запустивши “пілотний проект”, мета якого полягала у тому, щоб навчити співробітників одного з найбільших банків у Східній Європі, які відповідали за розробку продукту, основам Scrum, після чого масштабувати скрам-підхід.

На жаль, помітних переваг від “першої ластівки” банкіри не відчули.

Першу команду створили, мету сформували, всі елементи скраму забезпечили. Проблема полягала в іншому:

а) у команді були тільки програмісти;
б) кросфункціональної команди не було створено.

Проект потребував взаємодії з іншими відділами, та вони не вважали його своїм. Коли програмісти завершували свій спринт, виникала необхідність в ручному режимі підключати фахівців із інших відділів — тестувальників, спеціалістів з безпеки й відповідності (Security and Compliance) та ін.

Результатом вийшло те, що називають недоскрамом (англ. — “scrumbut”, рос. — “скрамно”).

Незважаючи на це, лідери банку вирішили не опускати руки й перезапустити “пілот”, усунувши виявлені недоліки й привести модель у відповідність зі скрамом.

Нагадаю, що за постулатами Scrum, кожна скрам-команда повинна мати продуктову мету (product goal). Вона має об’єднувати всіх розробників продукту і пронизувати всі процеси, з ним пов’язані. Це особливо відчутно, коли продуктова мета триває 3-4 місяці.

Забрати мету означає позбавити команду стриженя, що її об’єднує і тримає. Якщо KPI — це виконання завдань, говорити про мету, яка надає сенс проекту, доволі складно.

Вся скрам-команда покликана працювати над розробкою інкременту в межах одного спринта, щоб досягти мети продукту (product goal).

Висновки

Для успішного запуску Scrum потрібно врахувати два принципово важливі компоненти: а) мета; б) люди — кросфункціональні команди, кожен учасник якої її усвідомлює. Без розуміння мети всіма учасниками розробки існує високий ризик нівелювання скрам-підходу й унеможливлення усіх його переваг, головна з яких — швидкий вивід продукту на ринок, що дозволяє успішно конкурувати в умовах сучасної кон’юнктури.

ДОЛУЧИТИСЯ ДО AGILE.LIVE

• Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Product Owner (PSPO), Professional Agile Leadership Essentials (PAL-E)
• Підписатися на сторінку у LinkedIn
• Підписатися на Telegram-канал Agile.Live
• Підписатися на You-канал Agile.Live