Fake Agile: Чи кожна Scrum-команда є гнучкою?
Ні, на жаль, не кожна Scrum-команда насправді є гнучкою.
Дозвольте мені пояснити: Скрам-команда - це команда, яка працює відповідно до фреймворку Scrum: Тобто вона має спринти, певні ролі та ритуали. А оскільки мета фреймворку Scrum - допомогти командам працювати гнучко, Скрам має автоматично зробити кожну команду гнучкою, чи не так?
На жаль, на практиці організаціям завжди вдається впровадити Scrum і зробити свої команди якими завгодно, тільки не гнучкими. Це часто називають "зомбі-скрамом".
Які причини підробки Agile?
З мого досвіду, найпоширенішими причинами підробки Agile на практиці є наступні:
Підробка Agile Причина #1: Немає відгуків від клієнтів
Якщо гнучка команда не отримує прямого зворотного зв'язку від користувачів, вона не може працювати гнучко. На практиці запити клієнтів часто формулюються керівництвом і передаються командам через власників продуктів – Реальні петлі зворотного зв'язку з клієнтами в'януть або навіть не існують.
Гнучка команда потребує прямого контакту з клієнтом!
Підробка Agile через #2: зосередьтеся на швидкості та сюжетних моментах
Невже у 2025 році нам потрібно ще багато говорити про сторіпоінт? Гадаю, ми всі маємо достатньо досвіду, щоб зрозуміти, наскільки зосередженість на швидкості та сюжетних моментах стоїть на заваді користі для клієнтів.
Приклад: Що відбувається, якщо функція формально готова після першої ітерації, але ще не досягає користі для клієнта? Якщо вигода клієнта важлива для нас, то ми працюємо над нею доти, доки вона не буде досягнута. Зрештою, це може зайняти 3 ітерації, але принаймні клієнт тепер задоволений.
Але зачекайте, зараз мій менеджер раптово виходить з-за рогу і скаржиться, що моя команда реалізувала менше сюжетних моментів в останньому спринті. Тож для моєї швидкості було б краще, якби ми просто залишили нецінну функцію і працювали безпосередньо над наступною функцією, щоб ми могли створити більше сюжетних моментів.
Яка дурниця, чи не так? Якщо ми повторимо цей процес ще кілька місяців, то отримаємо продукт з великою кількістю функцій, які створюють дуже мало користі для клієнта.
Тож не дивно, що і клієнти, і команди розробників стають незадоволеними і йдуть.
У більш загальних рисах, мова йде про загальновідомий закон: Закон Гудхардта
"Коли захід стає метою, він перестає бути хорошим заходом".
Підробка Agile Причина #3: диктатура догми
Інженери люблять, коли є чіткі правила для всього. Це робить процеси планованими.
Що було б, якби ми також могли повністю визначати наші методи роботи за допомогою правил –? Хіба це не було б чудово? Ні, не було б.
Завдяки одному лише Scrum та його численним правилам і настановам, гнучка робота для багатьох команд вже відчувається як робота за жорсткими інструкціями. Це не повинно бути так.
Тож не погіршуйте ситуацію, додаючи більше правил та інструкцій до гнучкої роботи.
У найкращих гнучких командах, які я знаю, робота відчувається людською, живою, спонтанною та спільною.
І слід визнати, що більшість гнучких команд цього не роблять.
У цьому пості я вже писав про кроки, необхідні для захисту скрам-команд від зомбі-скраму: Виправити зомбі-скрам
Підробка Agile справжня: як захистити себе?
Ніщо не може повністю захистити вас від фальшивої спритності. Але є одна річ, яка може захистити вас якнайкраще: Ефективний процес, зосереджений на постійному вдосконаленні.
Звичайно, це починається з хорошої ретроспективи, в якій члени команди можуть відкрито ділитися своїми думками та ефективно розробляти і впроваджувати заходи для покращення.
Поки цей процес працює, потенціал справжньої гнучкості у вашій команді не втрачається.
Якщо ви хочете підняти свої гнучкі ретроспективи на новий рівень, я рекомендую – Звичайно, – Echometer, наш інструмент для ретроспектив. Ви можете спробувати його безкоштовно тут: Спробуйте Echometer
