Если еще пять лет назад Agile в диджитал-командах считался чуть ли не золотым стандартом, то в последнее время рынок все более осторожно относится к гибкой методологии. Почему система, задуманная как борьба против бюрократии, превратилась в набор формальностей, как избежать процессов ради процессов, где Agile реально приносит пользу, а где лучше выбрать гибридный подход, рассказывает Centicore Group
От гибкости к формализму
Изначально методология Agile появилась как альтернатива тяжеловесному Waterfall — каскадному управлению проектами, где между постановкой задачи и получением результата могли проходить месяцы. Agile предлагал другой подход: короткие циклы работы, быстрые проверки гипотез, постоянную обратную связь и возможность адаптировать продукт по ходу разработки.
Но со временем рынок начал воспринимать Agile не как способ управления неопределенностью, а как набор обязательных практик. В результате многие компании формально работают по Agile, но на практике сталкиваются с теми же проблемами, что и раньше: медленным принятием решений, перегруженностью команд, бесконечными согласованиями и ростом операционной бюрократии.
Во многих компаниях Agile начали воспринимать как возможность начинать разработку без предпроектного обследования, достаточной проработки продукта, архитектуры и ограничений. Детали уточняются по ходу, процессы дособираются по остаточному принципу, требования корректируются после запуска. И вместо гибкости эта корпоративная мутация приводит к дорогостоящему хаосу — особенно в крупных компаниях.
При этом манифест Agile не продвигал отказ от дисциплины: да, он утверждал, что люди и взаимодействие важнее процессов, работающий продукт важнее детальной документации, а готовность к изменениям — следования плану. Слово «важнее» постепенно заменилось на «вместо».
Agile на практике
Проблема Agile чаще кроется на уровне не отдельных процессов, а на уровне самой организационной модели. Если бюджет по-прежнему выделяется под разовые проекты, решения проходят через длинную цепочку согласований, а изменения происходят со скрипом, Agile фактически становятся новой оболочкой для старого Waterfall.
Так, в британской государственной программе Universal Credit попытка одновременно внедрить гибкую разработку и по ходу пересобрать саму логику системы привела к серьезным проблемам с управлением проектом. Среди причин провала — отсутствие понятных запросов бизнеса и четкой операционной модели, проблемы со встраиванием Agile в существующую систему контрактов и governance-процессов, а также недостаточную проработку архитектуры на старте.
Похожие проблемы возникали и у других компаний. Например, во время внедрения Agile в Kroger команды столкнулись с недоверием со стороны менеджмента, жесткой системой финансирования проектов и сопротивлением со стороны проджект-менеджмента. Причина — попытка внедрить Agile поверх старой системы управления, не меняя саму организацию. А в кейсе российского разработчика софта Goodt смешение продуктовой разработки и бесконечных клиентских кастомизаций под лозунгом Agile привело к конфликтам требований, росту техдолга и постоянным доработкам. В результате компании пришлось жестко разделить два контура: проектные внедрения перевести в каскадную модель, а продуктовую разработку оставить в Scrum.
Именно это и становится одной из главных тенденций: компании отказываются от идеи «универсального Agile» и начинают выбирать модель управления под конкретный тип задач.
Что убивает систему
Чаще всего проблемы Agile появляются в момент, когда процессы начинают существовать отдельно от их первоначальной цели.
Спринт как единица отчетности
Одна из самых частых проблем — когда команда начинает воспринимать спринт не как цикл обучения и проверки гипотез, а как способ отчитаться о выполненном объеме задач. В результате фокус смещается с быстрого получения фидбека и адаптации продукта на то, чтобы закрыть обещанное к концу спринта. Любое изменение внутри спринта начинает восприниматься как угроза стабильности процесса, хотя сама идея Agile изначально строилась вокруг способности быстро реагировать на изменения.
Дейлики — новая бюрократия
Ежедневные синхронизации задумывались как короткий инструмент координации команды: кто над чем работает, где появились препятствия и нужна ли кому-то помощь. Но на практике дейлики часто превращаются в мини-отчет перед менеджером. Вместо обсуждения проблем и зависимостей люди начинают перечислять задачи из Jira, а сама встреча только отнимает рабочее время. То же самое касается демонстраций результатов. Если на ревью приходит двадцать человек, которые никак не влияют на продуктовые решения, встреча быстро превращается в формальность.
Product Owner без реальных прав
Назначить на проект Product Owner’а не значит автоматически перейти на Agile. Часто роль этого специалиста остается формальной: приоритеты озвучивает бизнес, сроки задает руководство программы, а решения проходят ряд длинных согласований. В итоге ключевые решения принимаются медленно и вне самой команды, список задач постоянно меняется «сверху», а обратная связь от пользователей и команды почти не влияет на приоритеты разработки.
Превращение скорости в KPI
Еще одна типичная проблема — попытка измерять эффективность команды через скорость (velocity). Изначально скорость в Agile задумывалась как локальный инструмент прогнозирования, а не метрика продуктивности. Как только команды начинают использовать ее как KPI, они неизбежно переключаются с создания ценности на оптимизацию стори поинтов («весов» задач). Начинается дробление задач, инфляция оценок и имитация высокой скорости разработки без реального ускорения поставки продукта.
Выбор подхода
Несмотря на все проблемы, Agile не исчез и вряд ли исчезнет в ближайшие годы. Методология по-прежнему отлично работает там, где высока неопределенность и критична скорость обратной связи. Прежде всего это цифровые продукты, AI-сервисы, мобильные приложения, customer journey-команды, сервисы с высокой пользовательской неопределенностью, где можно быстро проверить гипотезу и откатить неудачное решение.
Но там, где высока цена ошибки и критична предсказуемость, эффективнее будут классические или гибридные подходы. Это касается ERP-внедрений, сложных интеграций, государственных платформ, промышленного ПО и других систем с жесткими требованиями к надежности и архитектуре.
Именно поэтому многие зрелые компании сегодня строят гибридные модели управления: архитектурные решения, критичные зависимости и регуляторные ограничения фиксируются заранее, а внутри безопасного контура команды работают короткими итерациями и быстро получают обратную связь.
Как вернуть Agile эффективность
Первое, что нужно менять компаниям, где Agile стопорит процессы — сам подход к организации работы. Гибкая методология плохо работает в среде, где команду оценивают по сроку сдачи проекта, а не по способности стабильно развивать продукт и приносить бизнесу результат. Поэтому компании постепенно переходят от временных проектных команд к постоянным продуктовым. Даже если вы пока не готовы полностью перестраивать финансирование под продуктовый подход, полезно хотя бы закрепить за командой стабильный объем ресурсов и ограничить количество внешних срочных задач.
Второй важный момент — метрики. Вместо погони за скоростью, стори поинтами и посещаемостью стендапов полезнее смотреть, как быстро изменения доходят до продакшена, как часто происходят релизы, сколько времени уходит на восстановление после ошибок и насколько часто изменения приводят к сбоям. Рядом обычно добавляют одну бизнес-метрику — например, конверсию, удержание пользователей или SLA — и метрику потока работы: сколько задач одновременно находится в работе и как долго они «висят» в системе.
Третий блок — сокращение коммуникационного шума. Вместо регулярных длительных отчетов лучше перейти к асинхронным обновлениям статуса, оставляя живые обсуждения только для действительно сложных вопросов.
Еще один важный вопрос — распределение ответственности и масштабирование Agile между командами. Одна из главных причин замедления разработки — переизбыток зависимостей между отделами. Оптимальнее создать внутри команды два центра принятия решений: специалист, который отвечает за продуктовые приоритеты, и специалист, отвечающий за техническую целостность системы.
В качестве вывода хочется отметить, что эффективность Agile определяется не количеством церемоний и не строгостью соблюдения Scrum Guide. Куда важнее другое: насколько быстро команда может принимать решения, получать обратную связь и проводить изменения через систему без роста организационного хаоса. И, возможно, именно это сегодня становится главным маркером зрелой разработки: неспособность идеально соблюдать процессы, а умение не превращать гибкость в новую форму бюрократии.