Как я перестал верить в спринты

Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.

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

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

Пока проекта нет в проде, спринты ничего не ломают

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

Мы просто последовательно выкатывали запланированное до первой продакшен‑версии. Двухнедельная нарезка была сверху и ни на что не влияла.

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

Запуск

Дальше проект выходит в прод, и ломается примерно все. Приоритеты скачут от критических багов к критическим фичам, без которых Самый Важный Клиент точно не будет пользоваться системой. План, составленный в понедельник, к среде устаревает.

Сначала я пытался описывать это через смену методологии. Есть же утверждение, что пока проблему не сформулировали, то и решать нечего. А использование названий методологий как будто бы сразу и решение предлагает — если не подходит одна, значит нужно просто использовать другую. Но по сути дело не в том, что вотерфол превратился в канбан. Скорее изменилась одна величина — горизонт планирования. Насколько далеко вперед можно планировать, прежде чем реальность обнулит план. До прода он измерялся месяцами. А после запуска парой задач. Но зато появилась величина которую мы можем измерять:‑)!

Эту величину не надо согласовывать, ее просто видно. Достаточно посмотреть, сколько живет составленный план, прежде чем его приходится переписывать: три дня, две недели, два месяца.

Спринт превращается в узкое место

Горизонт схлопнулся, а спринт остался. Вокруг него по‑прежнему строится вся работа команды.

В терминах теории ограничений спринт в этот момент становится узким местом системы. Пропускная способность определяется самым узким звеном, и на фазе запуска этим звеном оказывается двухнедельная итерация. Она не ускоряет работу, а замедляет ее.

Фрустрация с двух сторон

Формально критическую задачу нельзя брать в работу сразу, потому что это нарушит договоренность о том, как мы работаем. Но взять ее все равно приходится, и тогда нарушается обязательство на спринт. Что бы мы ни выбрали, одна из договоренностей ломается.

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

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

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

Усилия были направлены не туда

Мы подстраивали горизонт планирования и бэклог под рабочие итерации. А надо было наоборот: подстраивать итерации под то, как система работает на самом деле.

Любопытно, что это ровно то, что написано в Аджайл манифесте. Там же фокус не на спринтах, оценках, или двухнедельных итерациях. Там говорится о том, что люди и взаимодействие важнее процессов и инструментов, а готовность к изменениям важнее следования плану. Команда, которая держит итерации, мешающие ей работать, будет прямо таки анти‑эджайл. Не смотря на все термины и ритуалы, все эти скрам‑борды, ретро‑митинги, planning poker и прочие термины которые кто‑то укажет у себя в линкедине. Ну то есть мы пытались быть гибкими, но только гнуть пытались горизонт планирования, который зависел от внешних факторов, вместо того чтобы изменить методику работы, которая была внедрена на абсолютно другом этапе жизни проекта.

Что с этим можно делать

Первый вариант — перейти на канбан. Задачи двигаются по статусам, очередь ротируется без влияния на соседние задачи, вместо обязательства на две недели вперед действует лимит на одновременную работу.

У этого выбора есть цена, про которую я сперва не подумал. Канбан переносит решение на уровень каждой отдельной задачи. Пока поток мелкий и однородный, команда приоритизирует сама. Но как только задачи разнородные и дорогие, решение по каждой поднимается до продакта, и он превращается в диспетчера, согласующего каждую карточку в бэклоге. Это противоположно тому, ради чего он там нужен. А точнее противоположно тому, чем я хотел бы заниматься каждый день. Поэтому продолжил искать решение дальше.

Второй вариант — остаться в спринтах, чтобы сохранить общее направление работы, но договориться на всех уровнях команды об одном: состав спринта в начале и в конце будет разным. Так устроена эта фаза.

Тогда задача не в том, чтобы все успеть, а в том, чтобы удерживать объем выполнимым. Влетела новая задача — что‑то из хвоста уходит сразу.

Здесь есть сложность, ответа на которую у меня пока нет. Влетевшую задачу нельзя оценить до того, как ее нормально проработали, то есть взяли в работу и какое‑то время помусолили. Значит, непонятно, сколько именно выбрасывать из хвоста. В итоге размен приходится делать по факту в конце спринта, а не в момент влета.

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

Как понять, что фаза закончилась.

Я считаю, что из фазы разработки в фазу запуска проект переходит получив первые реальные внешние деньги. Ну то есть можно до посинения гонять внутренние тесты хоть на сто долларов, хоть на сто тысяч, но это не сможет подтвердить принятие клиентами нашей готовности. Все расходы на тесты — это по сути именно наши расходы, рост оборотов по таким тестам будет ростом расходов. А вот когда продукт получит сто долларов от настоящего клиента — вот это уже доход, который в дальнейшем может превратиться и в десять тысяч. Этот критерий нельзя подделать никакой внутренней готовностью.

Следующий переход — из фазы запуска в фазу стабильной работы и развития. Я бы назвал его «по предсказуемости». Это момент когда платформа начинает выполнять бизнесовые планы, причем планы нормальные, без скидки на молодость проекта и оговорки, что это лишь тесты. На самом деле такое начинает ощущаться раньше чем становится видно в отчетах — по сути бэклог перестает переписываться каждые несколько дней и задачи запланированные на все более длительный срок начинают выполняться без влетов.

Если совсем коротко, то команда перестает действовать реактивно и начинает проактивно. Результаты с ней больше не случаются, она к ним приходит.

Дальше становится легче

Динамика проекта в какой‑то момент стабилизируется, и команда естественным путем приходит к спринтам, в которых содержимое действительно не меняется. Причем приходит сама, до того как кто‑то предложит это внедрить: горизонт планирования растет, и однажды дорастает до двух недель.

Главное — дожить до этого момента, не перессорившись внутри и не разочаровав стейкхолдеров настолько, чтобы команду разогнали.