Почему agile-трансформация буксует. Три ошибки, которые совершают почти все

Agile-трансформация в крупных компаниях обычно начинается одинаково. Руководство принимает решение «переходим на agile». Нанимаются скрам-мастера, покупается Jira, команды перестраиваются. Через год руководство смотрит на результаты и задаёт закономерный вопрос: «Мы потратили время и деньги, а скорость доставки не выросла. Agile вообще работает?»

Agile работает. Но трансформация часто буксует по причинам, которые не имеют отношения к самому agile. Три из них встречаются настолько часто, что их можно назвать стандартными.

Ошибка первая: менять процесс, не меняя структуру принятия решений

Самая распространённая ситуация. Команды переведены на Scrum, проводят все церемонии, работают спринтами. Но процесс принятия решений остался прежним: приоритеты определяет руководитель направления, scope утверждается на квартальном ревью, изменения в плане требуют согласования на двух уровнях вверх.

В такой среде Scrum превращается в waterfall с двухнедельной итерацией. Команда планирует спринт, но не может менять приоритеты. Проводит ретроспективу, но не может реализовать выводы без одобрения. Product Owner существует, но реальных полномочий у него нет.

Суть этой ошибки в том, что agile требует определённого уровня автономии команды. Если команда не может принимать решения о том, что и как она делает, церемонии становятся формальностью. Перестройка процесса принятия решений обычно сложнее и болезненнее, чем внедрение Scrum, и именно поэтому её часто откладывают или вовсе обходят стороной.

Ошибка вторая: измерять не то

Компания внедрила agile и хочет видеть результат. Что измеряют? Velocity. Количество закрытых story points. Процент завершённых задач спринта. Эти метрики легко считаются и хорошо выглядят в отчётах. Проблема в том, что они измеряют активность, а не результат.

Velocity 80 story points за спринт выглядит впечатляюще, пока не выясняется, что ни одна из закрытых задач не дошла до пользователя, потому что релизный процесс занимает два месяца. Или что velocity стабильно растёт, а ключевая бизнес-метрика стоит на месте, потому что команда работает над задачами, которые не влияют на результат.

Метрики, которые стоит измерять при трансформации: cycle time (от постановки до пользователя), частота релизов, удовлетворённость клиентов. Они сложнее в сборе, но показывают реальную картину.

Ошибка третья: внедрять agile без обучения

Это звучит очевидно, но происходит на удивление часто. Компания решает «переходить на agile», нанимает пару скрам-мастеров, и ожидает, что остальные 200 человек разберутся сами. Scrum Guide ведь на 13 страниц, что тут сложного?

На практике разработчик, аналитик или менеджер, который не понимает, зачем нужны церемонии и как они связаны друг с другом, воспринимает их как бюрократию. Daily standup становится отчётом перед скрам-мастером. Sprint planning превращается в раздачу задач. Ретроспектива воспринимается как пустая трата времени.

Без общего понимания agile-подходов на уровне всей команды (включая менеджеров и бизнес-заказчиков) трансформация превращается в борьбу скрам-мастера с командой, которая не видит смысла в том, что делает.

Что делать, если трансформация застопорилась

Начать стоит с честной оценки того, на каком уровне находится проблема. Если церемонии проводятся, но решения принимаются по-старому, проблема в структуре принятия решений. Если метрики зелёные, а бизнес-результат стоит на месте, проблема в метриках. Если команды сопротивляются процессу, возможно, проблема в отсутствии общего понимания.

Для каждой ситуации нужны разные инструменты. Иногда достаточно начать измерять cycle time вместо velocity, и это уже запускает правильные разговоры. Иногда нужно обучение для всей команды, чтобы создать общий язык. Иногда нужна работа с менеджментом над изменением структуры принятия решений.

Где развивать навыки

Базовая программа Certified Agile Professional решает проблему общего языка. Когда все в команде, включая менеджеров и бизнес, понимают agile-подходы одинаково, трансформация идёт проще. Сертификат ICP подтверждает это понимание.

Скрам-мастерам и agile-коучам, которые ведут трансформацию, полезна программа Advanced Scrum Master & Agile Coach. Работа с сопротивлением, фасилитация сложных обсуждений с менеджментом, управление изменениями.

Менеджерам проектов, которым нужны правильные метрики и прогнозирование, подойдёт Agile Project Management. Flow-метрики, прозрачность для бизнеса, работа с неопределённостью.