Внедрили Agile, проводите дейли и ретроспективы, делите работу на спринты — но результата нет. Пожары задач, техдолг растет, команды не успевают. В чем проблема?
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. Я считаю, что если Agile не работает в вашей компании — то методология тут ни при чем. Разберемся, в чем настоящая проблема и как ее решить.
Agile стал ритуалом, а не инструментом
Компании применяют Agile формально — проводят дейли, ретроспективы и спринты для галочки, а не ориентируясь на цель.
Расскажу историю, которую услышал от коллеги. К его команде пришел заказчик с проектом на три месяца реализации. Заказчик сказал: «Отлично, теперь запустите его по Agile — нам нужен результат через месяц».
Многие считают Agile магическим словом, после которого все происходит быстрее. Это не так. Agile про другое: про адаптацию и обучение.
Та же история с мероприятиями. Возьмем дейли из Scrum — инструмент синхронизации команды, который помогает выявлять блокеры на пути к целям. По манифесту он занимает 15 минут. Я видел компании, где дейли растягивались на 30–40 минут, потому что каждый отчитывался по всем своим задачам. Никто не слушал друг друга — просто ждали своей очереди. Это не помогало команде работать, это создавало видимость контроля для менеджера.
— Dave Thomas, один из авторов Agile-манифеста, уже в 2014 году говорил, что Agile «умер», потому что превратился в набор ритуалов
История повторяется с планированием. Многие компании внедряют Scrum Poker, тратят время на оценку задач, но потом эти оценки нигде не используют. Зато красиво звучит: «Мы применяем Scrum Poker».
Именно поэтому появляются претензии: «Ваши гибкие методологии — это сплошные встречи». Давайте посчитаем: в двухнедельном спринте по Scrum 2 часа уходит на планирование, 1,5 часа на ретроспективу, и 2,5 часа на дейли по 15 минут каждый день. Итого: 6 часов за две недели. Относительно 80 рабочих часов это меньше 5% времени. Проблема не в количестве встреч — проблема в том, что их растягивают и не видят в них ценности.
Почему ИТ-команды страдают от неправильного Agile
Когда Agile применяют формально, процессы приводят не к гибкости, а к потере управляемости. Приведу несколько примеров из практики.
Команды реагируют на «пожары приоритетов»
Каждый спринт приоритеты меняются. Команда не может сконцентрироваться, не доделывает старые задачи, начинает новые — в итоге получается 100 брошенных задач. Это связано со скоростью разработки: если команда работает медленно из-за плохих процессов, у бизнеса приоритеты меняются быстрее, чем успевают реализовать функциональность. Через спринт задача уже не актуальна.
Решение — понять, почему команда не успевает. Приоритеты бизнеса могут меняться обоснованно. Нужно разобраться, что не так во взаимодействии бизнеса и разработки.
Стремление уложиться в спринт порождает техдолг
Команды делают костыли и временные решения, чтобы показать результат к концу спринта. В следующем спринте приходится исправлять накопленный техдолг. Многие считают, что Scrum не работает именно поэтому: за две недели команда ничего не успевает сделать качественно, все ломается.
— Исследования DevOps Research & Assessment (DORA) прямо показывают, что погоня за скоростью ухудшает качество, если жертвовать инженерными практиками
Важно различать: мы стремимся не закрыть как можно больше задач, а выполнить цель. Любой костыль в итоге обойдется бизнесу дороже, чем сделанное хорошее решение. Лучше делать маленькие, но качественные решения, чем большие на костылях.
Метрики не отражают реальность
Velocity, количество закрытых задач — эти показатели не говорят о создании бизнес-ценности. Более того, когда метрики становятся KPI, команды начинают их «рисовать».
Пример из кейса одного крупного банка. Они вывели диаграмму сгорания спринта на телевизор рядом с каждой командой: руководство могло пройти мимо и посмотреть, как команда поработала за день. Идея была сделать процессы прозрачными. На деле это привело к тому, что команды начали декомпозировать задачи и писать скрипты, которые просто списывали задачи. График получался красивый, но смысла не было — это никак не влияло на работу.
Таких примеров много. Как только метрики ставят в KPI или цели, они начинают рисоваться, а не отражать реальную картину мира.
Решение — не ставить KPI на метрики, а научиться ими управлять и отслеживать. Диаграмма сгорания спринта — хороший инструмент для команды, чтобы подсветить проблему: «Коллеги, мы не успеваем, мы слишком засиделись с разработкой, давайте подключим ресурсы или обсудим с владельцем продукта». Метрики должны быть инструментами, триггерами о том, что что-то происходит неправильно или что мы поменяли процесс и хотим посмотреть, как это изменилось. Метрики — инструмент отслеживания, а не обязанность.
Agile используют по кусочкам
Компании внедряют Agile фрагментарно — берут инструменты, но игнорируют принципы. В результате методологии не решают главную проблему: как создать единый поток разработки и поддержки продукта.
— Объединение команд разработки и технической поддержки: сквозные процессы ITSM в управлении разработкой
Agile отвечает на вопрос «как создавать продукт», но не объясняет «как его поддерживать». Scrum не предлагает чётких методик управления критичным инцидентом, который останавливает всю команду. Можно отменить спринт, но это разрушает планы и метрики — не системное решение. В Kanban ситуация ещё сложнее: методология запрещает превышать WIP-лимиты, а параллельный инцидент должен пройти по доске. Как его провести — отдельная проблема.
Главное, что большинство команд не понимают центральный принцип Agile: фокус важнее загруженности. Scrum требует решать одну задачу одновременно. Если три человека — аналитик, разработчик, тестировщик — работают над одной задачей, это быстрее, чем если они параллельно делают две задачи. Да, кто-то может простаивать. Но сама задача пройдёт по доске быстрее.
Принцип противоречит привычному менеджменту, где важнее, чтобы все работали 8 часов без простоя. Но если цель — быстрее выпускать фичи, команда должна концентрироваться, а не распыляться.
Вместо установки фокуса компании копируют внешние признаки методологий. Берут Kanban, делают 10 статусов с WIP-лимитом по 3–4 задачи на каждый — получается 30 задач в работе одновременно.
Доска выглядит «по-канбановски», но команда не становится быстрее — она постоянно переключается между задачами. Те, кто снижает WIP-лимиты до разумных значений, сразу видят результат: меньше задач на доске, но работа идёт быстрее.
Методологии недостаточно — нужна экосистема
Компания может использовать любую методологию как отправную точку, но адаптировать ее придется под свою ситуацию. Возьмем базовый Scrum — он отлично работает для небольших компаний с одной-двумя командами. Когда команд становится пять и больше, начинаются проблемы с синхронизацией. Scrum также не подходит компаниям, которые не могут быстро тестировать гипотезы на рынке.
Бизнесу нужна экосистема управления продуктом, где техническое совершенство и поток создания ценности выходят на первый план и метрики показывают время от идеи до продакшена и влияние на бизнес-показатели, а не скорость закрытия бессмысленных тикетов.
Сделайте сквозную прослеживаемость от потребностей клиентов до релизов
Компании тратят силы на поиск очередного Scrum-мастера или delivery-менеджера, который будет проталкивать задачи через систему. Правильнее выстроить процессы так, чтобы вся команда участвовала в понимании потребностей клиентов и видела путь задачи до релиза.
Представьте классическую ситуацию: отдел продаж собирает обратную связь, идет к delivery-менеджеру, тот — к владельцу продукта, владелец продукта — к команде. Пока задача проходит этот путь, все забывают, зачем она вообще нужна. Связь с клиентом теряется — получается сломанный телефон.
Важно выстроить процессы так, чтобы обратная связь клиентов попадала в бэклог команды как можно быстрее. Идеально, когда это происходит автоматически: есть форма обратной связи, клиент пишет, что хочет добавить, команда видит запрос и может его реализовать. Это работает лучше, чем цепочка через отдел продаж, delivery-менеджера и владельца продукта.
Интегрируйте разработку и поддержку
Интеграция между системами управления сервисами (ITSM) и жизненным циклом разработки (SDLC) решает проблему сломанного телефона. Техдолг и обратная связь от пользователей должны автоматически попадать в бэклог команды.
В идеале, когда приходит инцидент в ITSM-систему — сразу создаётся дефект в SDLC-системе. Когда клиент оставляет запрос на улучшение — он попадает к разработчикам без промежуточных звеньев. Отдел технической поддержки не оторван от разработчиков — все видят, что происходит с продуктом.
— Практика Known Error Database (KEDB) и её примеры — ITIL wiki
Объединение ITSM-подходов с Agile позволяет использовать инструменты из обеих методологий. Например, KEDB для создания временных решений при критичных инцидентах и затем более прогнозируемого их решения с помощью Agile-методологии.
Опыт команды SimpleOne
Мы в компании пробовали много разных методологий. Начинали со Scrum, переходили к SAFe и в итоге пришли к Kanban.
У нас своя стратегия: мы не обновляем сервера автоматически, а отдаем версии интеграторам, которые обновляют стенды наших клиентов. Цикл обновлений специфичный, обратная связь приходит не сразу. Нам важно было сконцентрироваться на процессах, поэтому мы остановились на Kanban.
Но главное — мы выстроили экосистему. Наши ITSM и SDLC-системы связаны: как только приходит инцидент — сразу создается дефект. Мы хорошо это отслеживаем, удобно с этим планируем. Отдел технической поддержки не оторван от разработки — мы хорошо понимаем, что происходит с продуктом.
Кроме того, мы связали системы, которые отвечают за процессы разработки и поддержки, с CRM. Отдел продаж тоже интегрирован с разработкой. Пример: каждый релиз мы выпускаем видео с обзором обновлений. Благодаря интеграции достаточно двух кликов — как только релиз готовится к выпуску, автоматически создается задача для маркетинга на подготовку и монтаж видео. Это ускоряет обратную связь с клиентами.
Мы думаем не только о том, как управлять продуктом, но и о том, как взаимодействовать с другими отделами. Это и есть экосистема.
***
Сталкивались с ситуацией, когда команды начинали «рисовать» метрики ? Как решали эту проблему?
Комментарии (21)
MEGA_Nexus
27.11.2025 13:34Внедрили Agile, проводите дейли и ретроспективы.
Agile не требует дейли и ретроспективы. Их требует Scrum.
Заказчик сказал: «Отлично, теперь запустите его по Agile — нам нужен результат через месяц».
Ну так дайте ему результат. Вы же помните картинку про Agile и автомобиль? На первом этапе у вас получается скейтборд, на втором самокат и т.д.
Agile тем и хорош, что первые результаты будут достаточно быстро. Это не WaterFall, где результаты лишь в самом конце.
Agile про другое: про адаптацию и обучение.
Agile манифест с вами не согласен.
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
в двухнедельном спринте по Scrum 2 часа уходит на планирование, 1,5 часа на ретроспективу, и 2,5 часа на дейли по 15 минут каждый день. Итого: 6 часов за две недели. Относительно 80 рабочих часов это меньше 5% времени. Проблема не в количестве встреч — проблема в том, что их растягивают и не видят в них ценности.
Это проблема Scrum, а не Agile. В Канбан, например, такой фигни нет, хотя Канбан - это Agile.
Каждый спринт приоритеты меняются. Команда не может сконцентрироваться, не доделывает старые задачи, начинает новые — в итоге получается 100 брошенных задач.
Один из принципов Agile - Гибкость.
Гибкость: Изменения в требованиях приветствуются даже на поздних стадиях, так как команда готова адаптироваться к новым условиям, а не следовать устаревшему плану.
Значит, вы просто недостаточно гибкие )))
Команды делают костыли и временные решения, чтобы показать результат к концу спринта. В следующем спринте приходится исправлять накопленный техдолг.
Это проблема Scrum. В Канбан такой ерунды нет.
Velocity, количество закрытых задач — эти показатели не говорят о создании бизнес-ценности.
И это тоже проблема Scrum.
Итого: почти всё описанное в статье - это проблемы мертворождённого Scrum, а не Agile. Так что либо используйте принципы Agile напрямую, либо используйте Канбан. Scrum мёртв от рождения и его лучше закопать и не вспоминать.
art241111
27.11.2025 13:34Ну так дайте ему результат. Вы же помните картинку про Agile и автомобиль? На первом этапе у вас получается скейтборд, на втором самокат
А этом примере заказчик хотел все и сразу, а не инкрементную поставку. Нужно понимать, что далеко не все на нее готовы
Это проблема Scrum, а не Agile. В Канбан, например, такой фигни нет, хотя Канбан - это Agile.
Это не совсем так. В kanban есть также дэйлики (team kanban meeting, workflow kanban meetings), ретроспективы (team retrospective, flow review, service delivery review) и этапы планирования, причем на разных уровнях зрелости их разное количество
Velocity, количество закрытых задач — эти показатели не говорят о создании бизнес-ценности.
И это тоже проблема Scrum.
В случае kanban это может быть метрика t2m или любая другая
Итого: почти всё описанное в статье - это проблемы мертворождённого Scrum, а не Agile. Так что либо используйте принципы Agile напрямую, либо используйте Канбан. Scrum мёртв от рождения и его лучше закопать и не вспоминать.
На самом деле kanban порой не подходит для продуктовой разработки, например в b2b. Там нет возможности проверять каждую фичу и проще проверять релиз в целом. А это нарушает принцип kanban. Поэтому он тоже не всегда подходит
А scrum не мертв и не плох) его просто мало кто знает и мало кто хорошо разбирается. Он хорошо подходит для проверки гипотез и выпуска инновационных продуктов
Как видите, даже мы с Вами поспорили о методологиях и терминах. В этом и проблема слепого следования за ними. Цель статьи показать что не методология плохая, а то что она или не подходит, либо ее не понимают
mazdai19
27.11.2025 13:34ну бывает ещё вариант, что аджайл просто не подходит.
ну или вон как в примере, "команды делают костыли чтобы успеть к концу спринта", ну так может спринты реально слишком короткие, причем тут аджайл.. нигде же гвоздями не прибито что спринт должен быть 2 недели.
vlad4kr7
27.11.2025 13:34Каждый спринт приоритеты меняются. Команда не может сконцентрироваться, не доделывает старые задачи, начинает новые — в итоге получается 100 брошенных задач.
Планируйте, чтобы задача влезала в спринт. Для этого типа планирования всей команды присутствовать не обязательно, достаточно Тимлид, ПМ и сеньор.
15 минут на стандап - много, должно хватать 7-8. Пинайте скрам мастера, чтобы следил.
Из 6ти часов , получится 2-3 на 2 недели.
Правильнее выстроить процессы так, чтобы вся команда участвовала в понимании потребностей клиентов
да! давайте мидлов нагрузим работой PO - ProjectOwner.
Представьте классическую ситуацию: отдел продаж собирает обратную связь, идет к delivery-менеджеру, тот — к владельцу продукта, владелец продукта — к команде. Пока задача проходит этот путь, все забывают, зачем она вообще нужна. Связь с клиентом теряется — получается сломанный телефон.
ДМ здесь лишний, а ПО обязательный.
Важно выстроить процессы так, чтобы обратная связь клиентов попадала в бэклог команды как можно быстрее.
И как быстро бэклог завалят? А приоритеты задачам выставлять кто будет?
art241111
27.11.2025 13:34Планируйте, чтобы задача влезала в спринт. Для этого типа планирования всей команды присутствовать не обязательно, достаточно Тимлид, ПМ и сеньор.
Цель спринта не сделать задачу, а выполнить цель спирта (это не всегда одно и тоже)
Тимлида и ПМ нет в scrum)
А всю команду стоит подключать, чтобы все были в контексте и понимали что и зачем делают. Я часто встречаюсь с паттерном "команде это знать не надо" и в этот момент теряется куча контекста внутри
да! давайте мидлов нагрузим работой PO - ProjectOwner.
Если мидл не знает ценности того что делает, то не сможет сделать хороший продукт
Даже DDD говорит о том, что важно разработчику знать бизнес процессы
И как быстро бэклог завалят? А приоритеты задачам выставлять кто будет?
Для этого есть po и работа с бэклогом
vlad4kr7
27.11.2025 13:34Цель спринта не сделать задачу, а выполнить цель спирта
это пять!
"команде это знать не надо"
я такого не говорил.
Чтобы не завалило задачами, и чтобы эффективно работалось - задачи должны закрываться. Для этого их надо нарезать на 2-3 недели, а не на 2 месяца. И именно для анализа и нарезки задач, не планирования спринта и не демо, всю команду дергать не обязательно. Если большинство задач тяжелые, то лучше 4х недельные спринты сделать.
И не забываем, что выполнения задачи - результат командный. Сильно желательно, чтобы над задачей работало больше одного человека.
Если мидл не знает ценности того что делает, то не сможет сделать хороший продукт
А если продукт получился плохой, значит мидлу не рассказали его ценность? А ценность в каждом спринте меняется?
art241111
27.11.2025 13:34Чтобы не завалило задачами, и чтобы эффективно работалось - задачи должны закрываться. Для этого их надо нарезать на 2-3 недели, а не на 2 месяца. И именно для анализа и нарезки задач, не планирования спринта и не демо, всю команду дергать не обязательно. Если большинство задач тяжелые, то лучше 4х недельные спринты сделать.
А можно приходить к команде не с задачами, а с целями. И тогда команда в начале придумает как сделать, а потом как декомпозировать. Надо понимать, что каждый член команды может знать больше чем лид, просто засчет того, что делал ту часть, которую лид не делал. Поэтому совет такого разработчика может значить много
А если продукт получился плохой, значит мидлу не рассказали его ценность? А ценность в каждом спринте меняется?
Нет) конечно все зависит не только от знаний и погружений разработка. Но это один из важных пунктов
vlad4kr7
27.11.2025 13:34А можно приходить к команде не с задачами, а с целями.
А можно не заваливать команду работой Тимлида и Оунера? не перегружать митингами, где будем регулярно перетирать как все важно?
Команде останется кодинг, а РО - общение, приоритизация, ТЛу - помощь в определении сложности.
Может производительности команды увеличится? Но ПО/ПМу прийдется работать!
art241111
27.11.2025 13:34Тимлида нет в скрам) поэтому вопрос подходов с которыми Вы работаете
Если команда будет отвечать только за коддинг, то когда их заменит ИИ? Сейчас самые лучшие разработчики это те, кто в том числе понимают продуктовую специфику
Поэтому спорно. Производительность вырастает именно из-за погружения, а не от того, что спихивается работа с PO
themen2
27.11.2025 13:34Команде действительно знать не надо. Есть разделение труда - давно придумали
art241111
27.11.2025 13:34Это грустно, если Вы считаете, что команде знать не надо
Могу сказать из практики, что как только команда начинает знать что делает, T2M вырастает на 20%. Только за счет знания и погружения!
MinimumLaw
27.11.2025 13:34А как вам вариант - потому что в компании Agile внедрили только "для негров", а остальные как живут как раньше и генерят кучу задач, которую исполнители физически не в состоянии переварить? Только по каким-то причинам руководителям казалось, что это не они генерируют шторм из заданий, а бардак на уровне исполнителей и Agile все моментом вылечит. Нет, чуда не будет - количество работы, которую делают исполнители, оно строго ограничено сверху. Если это понимать, то Agile по сути не сильно и нужен, а если нет то он не поможет. Впрочем, если это понимают, то всегда можно сказать что Agile уже есть, только "правильно адаптированный под нужды конкретной компании". И здесь это "действительно инструмент, а не просто ритуал".
tenzink
27.11.2025 13:34Давайте посчитаем: в двухнедельном спринте по Scrum 2 часа уходит на планирование, 1,5 часа на ретроспективу, и 2,5 часа на дейли по 15 минут каждый день. Итого: 6 часов за две недели. Относительно 80 рабочих часов это меньше 5% времени
А теперь давайте учтём, что для инженера любая встреча выбивает из потока за X-минут до и после встречи (оценим по минимуму минут в 15 минут, хотя, мне кажется, что нужно закладывать больше). Поэтому daily тратит не 15 минут, а примерно 45. К тому же вы забыли про обязательное демо в scrum - 1.5h (+ 2*15min на до и после)
И тогда затраты за 2 недели получаются
45x10 (daily) + 2 (ретро) + 2.5 (planning) + 2 (демо) = 14 часов, то есть уже 17.5%
Это не значит, что в других подходах оверхеда нет, но он не такой конский по временным потерям.
art241111
27.11.2025 13:34Спасибо про комментарий о демо, мы правда не учли
Если ставить daily на начало дня, то не будет траты на первые 15 минут :)
Но спасибо! Это интересная мысль
MilPavel
27.11.2025 13:34А я думаю: как люди, не разбирающиеся в предметной области, берутся что-то программировать? Они не видят, как люли пользуются их продуктом, не видят живых данных. Как такое возможно?
sibirrr
27.11.2025 13:34У нас в одной команде дейли превратились в 40-минутные монологи. Никто не слушал, все ждали конца. Плюс метрики рисовали, чтобы босс не рычал. Agile тут точно ни при чём. Виноваты мы, люди, которые превратили его в театр абсурда
art241111
27.11.2025 13:34Да, Вы правы. Поэтому мы и хотели в этой статье как раз это и подсветить, что проблема не в методологии, а в людях и понимании
MilPavel
27.11.2025 13:34И в методологии тоже. Что говорит Agile: программист должен разбираться в предметной области?
nolirpaf
Потому что это всё - торговля воздухом. Пока за пицунду на кукан не пообещаешь подвесить - никто не пошевелится должным образом. Все эти "тренеры", "MBA" и прочие клоуны сливают проекты на раз-два. И потом актоэтосделал.jpg
art241111
Для чего нужны паттерны в программировании? Можно же писать без них и жить хорошо
Зачем знать, что такое "Строитель"?
И тут тоже самое. Можно построить организацию так как хочешь. Можно кнутом бить всех и все будет работать
А можно знать разные подходы и использовать их делая свою компанию лучше (так же как и паттерны просто ускорят написания кода и сделают его понятнее)