[Перевод] Почему инженеры презирают Agile
TL; DR: Индустрия Agile консалтинга переупаковывает философию, изначально ориентированную человека и на технологии, в стандартизированную, всепогодную методологию по снижению проектных рисков. После продажи организациям команд и управления, их менеджеры среднего звена превращают Agile в версию тейлоризма 21-го века для работников умственного труда. Помимо этого метауровня, причины, по которым инженеры презирают Agile, можно разделить на пять категорий: управление, манипуляции, мониторинг, технологии и командная работа.
Проблемы, по которым инженеры презирают Agile
Когда я написал статью Agile Failure Patterns In Organizations, резюмируя типичные анти-паттерны применения Аgile в организациях, я был удивлен когда увидел, какое внимание она получила на 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 карго-культе на всю вечность? Или он пройдет мимо всех остальных, как и другие причуды менеджмента? Или мы сможем развернуть корабль?
Лично я все еще верю в подход Джорджа С. Паттона: «Не говорите людям, как делать, говорите им, что делать, и позвольте им удивить вас своими результатами».
Каковы ваши мысли на этот счет?
Для дальнейшего чтения
Если вы хотите глубже разобраться в проблемах, по которым инженеры презирают Agile, я рекомендую в качестве отправной точки следующие публикации и видео:
Энди Хант: Провал Agile
Майкл О. Черч: Почему Agile и в особенности Scrum внушают ужас
ayasin: Agile — это новый водопад
Гарри Харролд, Руперт Редингтон: Апокриф по Agile и Ad-Hoc манифест
Публикации по теме
Паттерны провала Agileв организациях
Почему Agile превращается в микроменеджмент
Найм: 38 вопросов на собеседовании для скрам-мастера, чтобы избежать Agile-самозванцев
