Не кожна Scrum-команда є гнучкою: підробка Agile

Fake Agile: Чи кожна Scrum-команда є гнучкою?

Ні, на жаль, не кожна Scrum-команда насправді є гнучкою.

Дозвольте мені пояснити: Скрам-команда - це команда, яка працює відповідно до фреймворку Scrum: Тобто вона має спринти, певні ролі та ритуали. А оскільки мета фреймворку Scrum - допомогти командам працювати гнучко, Скрам має автоматично зробити кожну команду гнучкою, чи не так?

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

Що таке «Fake Agile»?

«Fake Agile» — це команди, які офіційно працюють з гнучкими фреймворками та методами, але не мають фактичних циклів навчання з клієнтами. Отже, Fake Agile означає, що або a) інкременти взагалі не поставляються клієнтам ітеративно, або b) прямий відгук клієнтів про інкремент не використовується для короткострокового визначення пріоритетності.

Які причини підробки Agile?

Існує багато причин для «Fake Agile». З мого досвіду, найпоширенішими причинами Fake Agile на практиці є:

Підробка Agile Причина #1: Немає відгуків від клієнтів

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

Гнучка команда потребує прямого контакту з клієнтом!

Підробка Agile через #2: зосередьтеся на швидкості та сюжетних моментах

Невже у 2025 році нам потрібно ще багато говорити про сторіпоінт? Гадаю, ми всі маємо достатньо досвіду, щоб зрозуміти, наскільки зосередженість на швидкості та сюжетних моментах стоїть на заваді користі для клієнтів.

Приклад: Що відбувається, якщо функція формально готова після першої ітерації, але ще не досягає користі для клієнта? Якщо вигода клієнта важлива для нас, то ми працюємо над нею доти, доки вона не буде досягнута. Зрештою, це може зайняти 3 ітерації, але принаймні клієнт тепер задоволений.

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

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

Тож не дивно, що і клієнти, і команди розробників стають незадоволеними і йдуть.

У більш загальних рисах, мова йде про загальновідомий закон: Закон Гудхардта

«When a measure becomes a target, it ceases to be a good measure.»

Підробка Agile Причина #3: диктатура догми

Інженери люблять, коли є чіткі правила для всього. Це робить процеси планованими.

Що, якби ми також повністю встановили правила для наших способів роботи – хіба це не було б чудово? Ні, не було б.

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

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

Команди Agile повинні мати принаймні достатньо свободи, щоб мати можливість гнучко співпрацювати з клієнтами. Якщо правила та процеси перешкоджають цьому, їх слід ретельно переглянути.

У цьому пості я вже писав про кроки, необхідні для захисту скрам-команд від зомбі-скраму: Виправити зомбі-скрам

Підробка Agile справжня: як захистити себе?

Ніщо не може повністю захистити вас від фальшивої спритності. Але є одна річ, яка може захистити вас якнайкраще: Ефективний процес, зосереджений на постійному вдосконаленні.

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

Поки цей процес працює, потенціал справжньої гнучкості у вашій команді не втрачається.

Якщо ви хочете підняти свої гнучкі ретроспективи на новий рівень, я рекомендую – Звичайно, – Echometer, наш інструмент для ретроспектив. Ви можете спробувати його безкоштовно тут: Спробуйте Echometer