TL;DR: Индустрия Agile консалтинга переупаковывает философию, изначально ориентированную на человека и технологии, в стандартизированную, всепогодную методологию по снижению проектных рисков. После того, как Agile продали управленческим огранизация, их менеджеры среднего звена превращают Agile в современную версию тейлоризма для работников умственного труда . Помимо этого метауровня, причины, по которым инженеры презирают 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-самозванцев
