6 признаков, что ваш Agile не работает: какие сигналы говорят о необходимости пересмотреть подход к управлению проектами
Многие компании сталкиваются с ситуацией, когда после внедрения Agile скорость разработки стагнирует, релизы по-прежнему задерживаются, а число процессов и согласований только растет.
Centicore Group о том, какие признаки говорят, что внедрение гибкой методологии пошло не по плану, и что с этим делать?
Почему Agile не работает
С ростом популярности Agile его часто воспринимают не как инструмент для оптимизации процессов, а как набор обязательных практик и ритуалов, которые автоматически должны изменить бизнес к лучшему. Но внедрение спринтов, ретроспектив и стендапов не означает, что команда работает по Agile. Без смены системы управления гибкая методология часто превращается в формальность: команды начинают работать короткими итерациями, но бюджеты по-прежнему выделяются под проекты, ключевые решения проходят через комитеты, а приоритеты определяются за пределами команды.
Одновременно сами Agile-практики превращаются в ритуалы: стендапы посвящают отчетам, на ретроспективах обсуждают одни и те же проблемы, а в качестве KPI выбирают второстепенные метрики. В результате компания вроде бы получает все внешние атрибуты Agile, но на практике сталкивается с теми же проблемами, которые и пыталась решить с помощью гибкого управления.
Есть несколько характерных сигналов, которые говорят, что Agile в вашей компании перестал работать так, как задумывалось изначально.
1. Решения принимаются вне команды
Один из самых явных симптомов проблемного Agile — ситуация, когда команда, отвечающая за реализацию, практически не влияет на продуктовые решения. Формально в компании может существовать Product Owner, однако реальные приоритеты определяются сверху, а обратной связи от пользователей практически нет. Иначе говоря, команда не может самостоятельно управлять развитием продукта. В результате разработка фактически остается частью классической иерархической системы управления, когда процессы меняются, а структура принятия решений остается прежней.
2. Новая проблема — новый процесс
Любопытный парадокс: Agile изначально создавался как альтернатива избыточной бюрократии, но на практике многие компании, которые его внедряют, начинают воспроизводить прежнюю модель управления — только с другим набором терминов.
Не успевает команда столкнуться с новой проблемой, как появляется дополнительная встреча, новая роль, отдельная синхронизация или очередной уровень согласований. Постепенно количество процессов растет быстрее, чем скорость разработки. Если каждая проблема решается добавлением нового процесса, а не устранением причины, это обычно означает, что команда постепенно теряет гибкость.
3. Постоянная пересборка бэклога
Один из популярных мифов про Agile — что он позволяет отложить важные решения на потом и разобраться по ходу проекта. На практике такой подход часто дает негативный эффект: команда продолжает двигаться вперед, но ясности в продукте, архитектуре и приоритетах не становится больше. Если команда месяцами возвращается к одним и тем же требованиям, регулярно меняет приоритеты и постоянно пересобирает бэклог, это говорит не о способности адаптироваться, а о накоплении неопределенности.
Зрелый Agile работает иначе: каждая итерация должна снижать уровень неопределенности. Если этого не происходит, ищите проблему не в процессах разработки, а в управлении продуктом.
4. Рост рабочей нагрузки не ускоряет разработку
Хотя во многих компаниях высокая загрузка по-прежнему считается признаком эффективности, для Agile это один из тревожных сигналов.
Когда число параллельных задач растет, сотрудники начинают постоянно переключаться между инициативами, увеличивается число зависимостей, а незавершенных задач становится все больше. Как итог — команда занята весь день, но срок прохождения задачи от идеи до релиза увеличивается.
Чем больше проектов одновременно запускает компания, тем медленнее будет продвигаться каждая отдельная задача. Поэтому вместо загрузки сотрудников смотрите на скорость прохождения работы через систему и количество незавершенных тасков.
5. Чрезмерное внимание к метрикам
Количество story points, velocity, процент выполнения спринта и число закрытых задач могут быть полезны для планирования — но когда они становятся показателями эффективности, вместо работы команда фокусируется на оптимизации самих метрик. Задачи дробятся, оценки завышаются, скорость в отчетах кажется высокой, но в реальности релизы занимают столько же времени. Задачи вроде бы выполняются в срок, но бизнес по-прежнему не видит ни ускорения разработки, ни улучшения пользовательского опыта, ни роста ключевых продуктовых показателей.
Вместо внутренних метрик намного оптимальнее фокусироваться на скорости поставки изменений, стабильности системы и влиянии разработки на бизнес-результат.
6. За пределами команды Agile заканчивается
Эта проблема особенно часто встречается в крупных компаниях: внутри команды Agile работает практически идеально, но как только задача выходит за ее пределы, начинаются долгие согласования, проверки безопасности, инфраструктурные ограничения и бесконечное взаимодействие с другими подразделениями. В результате скорость определяется уже не эффективностью команды, а количеством организационных зависимостей. Чтобы этого избежать, нужно пересматривать процессы на более глобальном уровне и давать продуктовым командам большую автономию.
Что делать дальше
Если вы нашли у себя какие-то из этих признаков, это не значит, что нужно срочно отматывать все назад и возвращаться к Waterfall. Чаще всего проблема заключается не в Agile: обычно причина находится на уровне организационной структуры, системы принятия решений, управления продуктом или взаимодействия между командами.
Поэтому вместо вопроса «а правильно ли мы используем Agile» нужно спросить себя: помогает ли вам Agile быстрее принимать решения, снижать неопределенность и доставлять ценность клиенту? Если ответ отрицательный, нужно пересматривать не отдельные процессы, а сам подход к управлению.
