Agile ругают за пустые ритуалы, водопад — за медлительность. Но спор чаще идёт о форме, нежели о сути. Когда-то бюрократия — в духе Макса Вебера и его рационально-легальной модели — научила организации масштабироваться: стандарты, роли, предсказуемость. Цена этой масштабируемости — тяжёлый пересмотр решений и медленный разворот. Agile — следующий шаг эволюции: он учит быстро учиться в процессе поставки, а не только планировать. Смысл — в коротких циклах, где каждая итерация заканчивается работающим инкрементом и проверкой гипотез на реальности.
Противоречия между Agile и Waterfall нет. Можно рассматривать Waterfall как одну из конфигураций Agile, когда из-за требований/рисков команда выбирает очень длинный спринт с единым выпуском в конце.
Почему Agile часто не принимают
1) Инертность «старого менеджмента»
Люди, воспитанные в логике годовых планов и phase-gates-модели, оптимизируют предсказуемость и контроль. Их KPI — «по плану и в срок», зачастую игнорируя выученные уроки. Итерации для них выглядят как «незавершёнка», а видимые переработки — как провал, хотя это нормальная цена за ранние факты.
Плюс срабатывает выученная модель: «сначала всё решает начальник, потом команда просто реализует». Agile переворачивает это местами: команде приходится чаще принимать решения, а менеджеру — мириться с тем, что путь меняется по дороге.
2) Нежелание разбираться в сути и областях применимости
Agile подменяют ритуалами и пытаются применять «везде одинаково».
Итерации тащат в зоны необратимых решений (критичные данные, публичные контракты, безопасность) — получаются дорогие ошибки, после чего делают вывод «Agile не работает».
Или, наоборот, объявляют «гибкость» синонимом хаоса: без Definition of Done, наблюдаемости, критериев «достаточно» и guardrails. Тогда Agile превращается в оправдание «делать что хотим».
В обоих случаях это не Agile по смыслу, а просто плохо настроенный процесс с другим названием.
3) Конфликт с системой мотивации и корпоративным планированием
Топ-менеджмент пишет годовые планы с KPI, спускает их на линейных менеджеров и одновременно требует «работать по Agile». На бумаге — спринты и бэклог, в реальности — жёстко зафиксированный объём, сроки и метрики запуска «как в плане».
В таких условиях Agile на линейном уровне превращается в пародию:
команда должна делать вид, что «гибко адаптируется»,
но её оценивают по тому, насколько она не отклоняется от изначального годового плана.
Любая попытка честно скорректировать курс по результатам итерации воспринимается как «неисполнение плана», а не как нормальное обучение. Естественно, после такого у людей возникает стойкое отвращение к слову Agile.
Неприятие нового: уроки MBO
Само по себе неприятие Agile — не что-то уникальное. Почти любое серьёзное управленческое новшество проходит долгий цикл — десятилетиями — через фазы: страх → неприятие → торг → принятие → базовая норма. Хороший пример — **Management by Objectives (MBO) Питера Друкера: когда-то идея управлять через согласованные цели, а не только через приказы сверху, пугала и казалась «теорией консультантов»; компании проходили через торг — цели формально ввели, но часто просто переписывали их из планов руководства. Сегодня MBO и его наследники (KPI, OKR) стали фоном: почти никто не спорит, что у команды должны быть понятные цели, спорят уже о том, как именно их формулировать. С Agile происходит тот же процесс, только объект изменений другой: не сами цели, а способ движения к ним — длинными монолитными циклами или короткими витками обучения.
Другие знакомые сюжеты
Точно такой же паттерн можно увидеть и в более близких примерах:
Ещё недавно идея «команда работает из дома» или «учиться можно онлайн» воспринималась как временная мера или вынужденный компромисс. Сейчас онлайн-форматы стали частью нормы, хотя до сих пор есть те, кто не принимает это как состоявшийся факт.
Когда-то требование мыть руки между пациентами вызывало яростное сопротивление и воспринималось как сомнение в профессионализме врача. Сегодня отказ от гигиены — маргинальное поведение, а не «альтернативный подход».
Во всех этих историях новое сначала кажется опасным, лишним или «модой», затем идёт долгий период торга и полумер, и только потом наступает стадия, когда вчерашняя инновация превращается в baseline — фон, с которого начинается следующий виток изменений.
С Agile, скорее всего, будет то же самое: через какое-то время спорить будут не о том, «нужен ли Agile в принципе», а о том, как именно конфигурировать процессы и архитектуру работы под конкретную организацию, считая итерационную работу и обучение на поставке чем-то само собой разумеющимся.
Зачем вообще Agile, если Waterfall и бюрократия не умерли
Если отбросить лозунги, Agile нужен не для того, чтобы «всем было весело на стендапах». Он про другое: как дешевле учиться на реальности, когда окружение меняется быстрее наших планов.
Бюрократия и классический проектный подход решают задачу предсказуемости: чтобы люди знали свои роли, процессы повторялись, а результат можно было встроить в годовой план. В мире, где изменения редкие и медленные, этого достаточно.
Проблема начинается там, где:
требования двигаются вместе с рынком и технологиями,
цена задержки становится выше, чем цена возможных переделок, а «идеальное ТЗ» устаревает быстрее, чем его успевают согласовать.
Agile в такой среде меняет точку оптимизации:
вместо «минимизировать переделки» — минимизировать задержку обучения на ошибках,
вместо «сделать один большой правильный выстрел» — провести короткую разведку боем,
вместо «дотянуть любой ценой до финального релиза» — иметь право остановиться раньше, когда ценности уже достаточно или направление оказалось тупиковым.
Отсюда и вся остальная механика: инкременты, экспериментальность, короткие циклы. Не потому что так написано в книжке по Scrum, а потому что это дешёвый способ регулярно задавать себе два простых вопроса:
*«Мы всё ещё делаем то, что нужно?» и «Не пора ли остановиться или повернуть?»
А как же оптимизация? В такой формулировке Agile действительно не выглядит «идеально вылизанным»: лишние инкременты, разведка боем, работа над ошибками. Возможно, в моменте так и есть — по локальным затратам классический водопад иногда выглядит выгоднее. Но всё поддаётся сравнению на длинной дистанции. Гипотетически проект можно провести по Waterfall достаточно быстро, возможно даже быстрее, чем по Agile… вопрос только в том, принесёт ли он пользу в той реальности, в которую придёт через год. Как говорится, большое видится на расстоянии* на коротком отрезке мы экономим на «лишних» итерациях, на длинном — часто расплачиваемся за это годами поддержки не того решения.
От идеи до GA: знакомый Agile, который мы не всегда замечаем
Если оглянуться назад на классический путь фичи или инициативы — Idea → Prototype → PoC → MVP → Pilot → GA — становится видно, что это по сути тоже конфигурация Agile.
Во-первых, каждый этап даёт **ощутимый инкремент**, пусть и не всегда в продакшене.
💡Идея оформлена и проговорена — уже инкремент по сравнению с неоформленным хаосом.
🧠 Прототип позволяет «пощупать» UX.
⚙️ PPoC проверяет техническую реализуемость.
👥 MVP — это уже рабочий продукт для ограниченной аудитории.
💼 Пилот даёт реальный опыт эксплуатации.
Каждый из этих шагов можно показать, обсудить, на нём можно учиться.
Во-вторых, такой workflow даёт возможность «съехать» на любой стадии с минимальными потерями. Если что-то не взлетает на уровне прототипа или PoC, мы теряем существенно меньше, чем если бы сразу шли к большому релизу. Это и есть та самая управляемая гибкость: мы не обязаны бежать до GA любой ценой, у нас есть несколько точек выхода по дороге.
Более того, в Agile совершенно нормально начать с одной идеи, а реализовать в итоге другую — и это не провал, а признак здорового процесса обучения. Об этом я расскажу в следующей статье.
Читайте мою серию: Усталый Босс
