Чому інженери зневажають Agile

Технології 10 січня 2025

TL;DR: Індустрія Agile консалтингу переупаковує філософію, спочатку орієнтовану на людину і технології, в стандартизовану, всепогодну методологію зі зниження проектних ризиків. Після того, як Agile продали управлінським огранізація, їхні менеджери середньої ланки перетворюють Agile на сучасну версію тейлоризму для працівників розумової праці. Крім цього метаурівня, причини, з яких інженери зневажають Agile, можна розділити на п'ять категорій: управління, маніпуляції, моніторинг, технології та командна робота.

Проблеми, за якими інженери зневажають Agile
I. Контроль
II. Маніпулювання
III. Наглядач
Технологія IV.
V. Робота в команді
Що ви думаєте?
Для подальшого читання
Публікації за темою

Проблеми, за якими інженери зневажають Agile

Коли я написав статтю Agile Failure Patterns In Organizations, резюмуючи типові анти-патерни застосування Agile в організаціях, я був здивований коли побачив, яку увагу вона отримала на HN.

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

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

Не дивно, що серед інженерів є чимало відкритих критиків. Не зрозумійте мене неправильно: не всі інженери зневажають Agile. Але вони висловлюють серйозні побоювання, які можна розділити на п'ять категорій:

I. Контроль

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

Детальніше про аспект Agile-мікроменеджменту: Agile Micromanagement in the Era of Autonomy, Mastery and Purpose.

II. Маніпулювання

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

Не можна сказати, що цей метод повністю ігнорує принцип Щю-Ха-Рі, що використовується для вивчення нової техніки:

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

Швидше, він починається із застосування «правил» на першому етапі, а потім продовжує їх дотримуватися, ігноруючи другий і третій етапи. Роблячи так, скелет Agile'a перетворюється на ще один стиль управління, який закликає слідувати плану - тільки через більш короткі проміжки часу, звані спринтами.

III. Наглядач

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

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

Роблячи «технологію» видимою для нетехнічних людей, це дозволяє їм отримати свого роду «» управлінський контроль над територією «», який вони не могли здійснювати раніше.

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

Технологія IV.

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

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

V. Робота в команді

В Agile немає місця для особистості. Він не враховує трудовий стаж і особисте зростання окремого інженера, оскільки більше немає техлідів.

Замість того принципу «індивідууми і взаємодія важливіші процесів та інструментів», Agile знову перетворює окремих розробників на гвинтики машини, створюючи одноразові клони в рамках більш-менш анонімного процесу. Що також є причиною перетасовки членів команди в терміновому порядку.

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

Незважаючи на всю втрату почуття власності, очікується, що члени команди будуть активно брати участь у церемоніях: від стендапів і уточнень беклога, які забирають багато часу, до ретроспектив - ритуалів «самовдосконалення», заснованих на спринтах.

Що ви думаєте?

Чи можете ви навчити старого (менеджмент-) пса, що пройшов соціалізацію в командно-адміністративному середовищі, новим трюкам Agile?

По-перше, я вважаю, що є виверт 22: «хороший менеджер» за традиційними стандартами визначається тим, що він знає, що робити і як вирішувати завдання.

А якщо нова ідея вимагає прямо протилежного: визнати, що менеджер не знає? Що, якщо мова йде про те, щоб бути відкритим для навчання, експериментів і невдач, а також про надання командам можливості знайти рішення, а не надати його команді самостійно?

Отже, чи застрягли ми в Agile карго-культі на цілу вічність? Або він пройде повз, як і інші причуди менеджменту? Або ми зможемо розгорнути човен?

Особисто я все ще вірю в підхід Джорджа С.Паттона: «Не кажіть людям, як робити, кажіть їм, що робити, і дозвольте їм здивувати вас своїми результатами».

Що ви думаєте з цього приводу?