Agile без ритуалов — эволюция после бюрократии⁠⁠

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 совершенно нормально начать с одной идеи, а реализовать в итоге другую — и это не провал, а признак здорового процесса обучения. Об этом я расскажу в следующей статье.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• От PoC к масштабу — как превратить пилот в повседневную реальность

• Виды логики и их влияние на мышление

• Эволюция современной службы поддержки

• Когнитивные искажения в ИТ: коротко, по-человечески и с примерами

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент