Почему Agile не приносит результатов: возможные причины неэффективности методологии в компании

Agile не приносит ожидаемых результатов? Задачи накапливаются, как лесные пожары, технический долг растёт, а команды не справляются. В чём может быть причина? Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. Я убеждён, что если Agile не работает в вашей компании, то проблема не в методологии. Давайте разберёмся, в чём же настоящая причина и как её можно решить. **Agile превратился в формальность** Многие компании используют Agile механически, проводя ежедневные встречи, ретроспективы и спринты лишь для вида, а не для достижения конкретных целей. Приведу пример, который мне рассказал коллега. К его команде обратился заказчик с проектом на три месяца. Заказчик заявил: «Отлично, теперь запустите его по Agile — нам нужен результат через месяц». Некоторые считают, что Agile — это своего рода магическое заклинание, которое ускоряет работу. Однако это не так. Agile подразумевает адаптацию и обучение. То же самое касается и мероприятий. Например, ежедневные встречи в Scrum, предназначенные для синхронизации команды и выявления препятствий, по манифесту должны длиться 15 минут. Однако я сталкивался с компаниями, где эти встречи растягивались на 30–40 минут, поскольку каждый участник отчитывался по всем своим задачам. Люди не слушали друг друга, а просто ждали своей очереди. Это не способствовало улучшению работы команды, а лишь создавало видимость контроля для менеджера. Ещё в 2014 году один из авторов Agile-манифеста, Дейв Томас, заявлял, что Agile «умер», поскольку превратился в набор ритуалов. Аналогичная ситуация происходит и с планированием. Некоторые компании внедряют Scrum Poker, тратят время на оценку задач, но затем эти оценки не используются. Однако звучит это красиво: «Мы применяем Scrum Poker». Именно поэтому возникают жалобы: «Ваши гибкие методологии — это сплошные встречи». Давайте подсчитаем: в двухнедельном спринте по Scrum 2 часа уходит на планирование, 1,5 часа на ретроспективу и 2,5 часа на ежедневные встречи по 15 минут каждый день. В сумме это составляет 6 часов за две недели. По сравнению с 80 рабочими часами это менее 5% времени. Проблема не в количестве встреч, а в том, что их затягивают и не видят в них ценности. **Почему ИТ-команды страдают от неправильного применения Agile** Когда Agile используется формально, это приводит не к гибкости, а к потере управляемости. Вот несколько примеров из практики: 1. **Реакция на «пожары приоритетов»**. В каждом спринте приоритеты меняются, команда не может сосредоточиться, не завершает старые задачи и начинает новые. В результате накапливается множество незавершённых задач. Это связано со скоростью разработки: если команда работает медленно из-за неэффективных процессов, то у бизнеса приоритеты меняются быстрее, чем успевают реализовать функциональность. Решение заключается в том, чтобы понять, почему команда не успевает. Приоритеты бизнеса могут меняться обоснованно. Необходимо разобраться, что не так во взаимодействии бизнеса и разработки. 2. **Стремление уложиться в спринт порождает технический долг**. Команды создают временные решения и костыли, чтобы показать результат к концу спринта. В следующем спринте приходится исправлять накопленный технический долг.