Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

Методология Agile достаточно давно пользуется неизменной популярностью при организации процессов управления проектами. Но очень часто, все начинается вроде бы прекрасно: приходит новый ИТ‑директор или нанимают крутого Agile‑коуча. Команды садятся в кружок, доска в Jira расцвечена всеми цветами радуги, спринты нарезаны ровно по две недели. И вроде бы все счастливы.

По прошествии нескольких месяцев этот же ИТ‑директор с горящими глазами рассказывает совету директоров, что они «увеличили скорость доставки на 40%». Но почему‑то доля рынка падает, ключевой конкурент выпустил фичу, которая числится у нас в бэклоге уже полгода, а бизнес‑заказчики матерятся в кулуарах. Это типичная ловушка «эпического» спринта. По сути, это не Agile, а бюрократия, замаскированная под гибкость.

Далее мы попробуем разобраться, в чем проблема, и что руководитель может сделать для ее решения.

Как «Гибкость» превращается в «Бетон»

Итак, ошибка номер один — это перенос тактики на уровень стратегии. Scrum прекрасно работает для команды из семи человек, которая решает конкретную инженерную задачу: починить поиск, оптимизировать запросы, сверстать экран. Но когда эту же механику натягивают на портфель из пятнадцати проектов и годовую стратегию развития продукта, происходит подмена понятий.

Команды начинают мыслить спринтами. Не кварталами, не полугодиями, а двухнедельными отрезками.

Так, например, в одном крупном маркетплейсе можно было наблюдать такую картину: стратегическая инициатива по внедрению персонализированных рекомендаций была разбита на 28 спринтов. Двадцать восемь, Карл! Каждые две недели команда отчитывалась о прогрессе, показывала «инкременты» в виде очередного микросервиса, который никому не был нужен без двух других смежных модулей.

Через полгода выяснилось, что алгоритм машинного обучения, который они должны были интегрировать, устарел морально еще на старте. Но спринты шли по плану. Движение было, а прогресса — ноль.

Ловушка Velocity или почему скорость ≠ результат

Многие менеджеры влюбляются в метрику Velocity. Это та самая кривая сгорания задач, которая показывает, сколько Story Points команда переваривает за спринт. И здесь начинается игра в цифры. Чтобы кривая не падала, команды начинают дробить задачи. Одна маленькая фича превращается в десять эпиков, потому что так проще показать «закрытие».

Например, был случай в логистической компании, когда разработчики настолько привыкли оценивать всё в Story Points, что начали закладывать время на «поддержание уровня Velocity» в каждый спринт. Был отдельный бэклог‑item под названием «Технический долг — рефакторинг», который тянули из спринта в спринт чисто для галочки.

Однажды тимлид честно признался на ретроспективе: «Мы не пишем этот рефакторинг уже четыре месяца. Мы просто переносим эту задачу, потому что, если её убрать, наш показатель упадет, и нас начнут спрашивать, почему мы стали медленнее». Вот она, цена погони за метрикой. Команда врала сама себе, чтобы сохранить лицо перед руководством.

А стратегия тем временем стояла на месте. Потому что никто не задавался главным вопросом: «А ту ли мы фичу делаем?». Вопрос был только: «Как быстро мы её делаем?».

История про «Умный склад»

В качестве примера рассмотрим живой кейс. Есть компания средних размеров, занимающаяся автоматизацией складских систем. У них была амбициозная цель на год — сделать систему прогнозирования запасов, которая сократит издержки на 20%. То есть в этом заключалась их стратегия. Они наняли продакт‑менеджера из банка, тот построил процесс по SAFe. Создали три команды, каждая крутилась в своем спринте.

Первая команда делала интерфейс для аналитиков. Вторая — интеграцию с 1С. Третья — саму математическую модель.

За этим интересным занятием прошло три квартала. Интерфейс был красивый, прямо как в приложениях Apple. Интеграция работала быстрее, чем требовалось. А модель прогнозирования… Ну её не было. Её откладывали каждый спринт, потому что она была «слишком сложнооцениваемая» и «не вписывалась в ритм спринта».

В итоге бизнес‑заказчик пришел через девять месяцев, посмотрел на пустую красивую витрину и спросил: «Где прогнозы?». Ему показали графики сгорания задач и бэклог, расписанный на год вперед. После этого он уволил ИТ‑директора.

Почему это произошло? Потому что фокус сместился с результата на процесс. Менеджеры управляли спринтами, а не стратегическими рисками. Самый сложный, самый неопределенный блок (математика) был отложен в долгий ящик, потому что он «ломает статистику» спринта. Стратегия принеслась в жертву тактическому удобству отчетности.

Лечение: Как вернуть стратегию в Agile

Теперь давайте поговорим о том, как можно правильно использовать Agile в подобных случаях.

• Первый шаг — признать, что спринты хороши для «строительства», но не для «проектирования». Нельзя засунуть исследование или архитектурный прототип в двухнедельный конвейер. Это творческий, итеративный процесс, который требует времени и права на ошибку.

В приведенных выше примерах стоило бы сделать простую вещь: разделить поток работы. Операционные задачи (баги, мелкие фичи) оставить в спринтах, а стратегические инициативы вывести в отдельный трек с квартальными вехами. Там нет Story Points, вместо этого там есть только Checkpoints: “гипотеза подтверждена”, «гипотеза провалена», «идем дальше».

• Второе правило: перестать мерить успех спринта. Начните мерить успех релиза. Если фича не доходит до пользователя за два спринта, это не провал спринта, это провал планирования. Спринт — это конвейер, а релиз — это выходной контроль качества. Не стоит их путать.

• И третье, самое сложное для многих руководителей верхнего уровня: разрешите команде останавливаться. Если в середине спринта выяснилось, что фича не нужна рынку — не доделывайте её «для галочки». Лучше убейте её, ведь спринт — это не контракт, это инструмент. Инструмент не может быть важнее цели.

Итог

В классическом Agile есть принцип: «Лучший способ донести информацию — это личная беседа». Но мы заменили личные беседы отчетами по спринтам. Мы перестали говорить о стратегии на стендапах, мы говорим о задачах. Мы перестали спрашивать «Зачем?», мы спрашиваем «Насколько?».

Ошибка масштабирования Agile в том, что мы пытаемся экстраполировать линейную модель (сделали задачу — получили результат) на нелинейный мир стратегии. В стратегии нет повторяющихся циклов, так как там каждый шаг уникален.

Поэтому, если вы видите, что ваша стратегическая инициатива расписана по спринтам ровными рядами, как солдаты на параде, — остановитесь. Снимите с неё эту форму и дайте ей возможность дышать. Позвольте команде сказать: «Этот спринт мы потратим на то, чтобы понять, рабочая ли наша идея, а не на то, чтобы допилить кнопку».

Иначе вы рискуете оказаться в той же ситуации, что и тот самый ИТ‑директор склада: с идеальным процессом и мертвым бизнесом.

Гибкость начинается там, где вы готовы переписать бэклог завтра утром, несмотря на то, что сегодня вечером закрывается спринт. Если вы на это не готовы — вы не Agile. Вы просто используете дорогую обертку для старого доброго водопада.

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

Этим темам посвящены два открытых урока:

• 19 августа, 20:00. «Метрики Delivery Manager: что измерять, а что — пустая трата времени». Записаться

• 8 сентября, 20:00. «От технического лидера к CTO: как начать принимать решения на уровне бизнеса». Записаться

Полный список бесплатных уроков августа смотрите в дайджесте.