Фейковые Спринты
Работая с большим количеством продуктовых групп и компаний, мы замечаем паттерн — команды не умеют создавать готовый к релизу инкремент каждый Спринт. Команды опираются не на свои возможности, а на опыт других команд/компаний: начинают работать двухнедельными Спринтами.
Мы называем такие Спринты фейковыми, потому что они не завершаются полными циклами обратной связи. Несмотря на то, что команды формально проводят Обзор Спринта и Ретроспективу Спринта, отсутствует готовый к релизу инкремент. Значит, эмпирический контроль не работает, стейкхолдеры не могут инспектировать прозрачный инкремент на Обзоре Спринта и своевременно работать с возникающими рисками.
Сердцем Скрама является Спринт, период времени не более одного месяца, в течение которого создается потенциально готовый к релизу инкремент продукта (Руководство по Скраму\Scrum Guide, 2017).
Спринт контролирует риски
В продуктовой разработке инновации обычно создаются в трех категориях. Первая — пользовательский опыт (UX). Первый iPhone хороший пример того, как уникальный пользовательский опыт сделал продукт невероятно успешным. Вторая категория — технологии. Появление на рынке LED телевизоров и DVD-плееров в свое время было новым словом в технике. Третья категория — бизнес-модели. Платформы AirBnb, Uber, облачный сервис Amazon изменили наше представление о том, как можно строить бизнес. По сути, речь идет о трех видах риска, с которыми работают в продуктовой разработке:
- Desirability: пользовательский опыт и функциональность продукта востребована клиентами.
- Feasibility: техническое решение реализуемо.
- Viability: продукт приносит прибыль, бизнес-модель масштабируется.
Спринт — ключевой инструмент управления рисками. Как минимум раз в Спринт команда создает готовый к релизу инкремент, чтобы снижать каждый из трех видов рисков.
Спринты поддерживают предсказуемость, обеспечивая инспекцию и адаптацию прогресса к достижению Цели Спринта, по крайней мере, каждый календарный месяц. Спринты ограничивают стоимость риска календарным месяцем (Руководство по Скраму\Scrum Guide).
Хочу поделиться историей из своего личного опыта. Восемь лет назад я был начинающим Скрам-мастером и работал со своей первой Скрам-командой. Во время недельного старта мы определили видение и Бэклог Продукта, сформировали DoD, который обеспечивал releasable. Начало было многообещающим.
Через несколько Спринтов мы получили первую эмпирическую информацию. Провели релизное планирование с Владельцем Продукта и выяснили, что функциональность, на которую он рассчитывал, не будет готова даже через год, исходя из эмпирической информации.
Владелец Продукта и стейкхолдеры не сомневались в том, что они знают, чего хотят конечные пользователи. Они излучали уверенность, когда тема касалась понимания потребностей рынка. По их словам, вопрос был только в недостаточной скорости.
На Команду Разработки стали оказывать давление, чтобы увеличить количество выдаваемых фичей в Спринт. Я как Скрам-мастер не смог защитить команду, команде пришлось жертвовать качеством и скоро Definition of Done (DoD) стал неактуален и забыт. Команда перестала заниматься авто-тестированием и следить стандартам качества кода. За несколько месяцев, несмотря на то, что это был небольшой стартап, технический долг вырос как снежный ком.
Наконец, Владелец Продукта принял решение о выходе в релиз. Команда не смогла это сделать сразу. Ей понадобился месяц. Результаты первого релиза были крайне неутешительными. Фичи, на которые делали ставки, оказались никому не нужны. Продукт, как говорится, “не взлетел”. У стартапа оставалось финансирования на полгода. И когда Владелец Продукта понял, что стартап теперь находится на грани выживания, осознал необходимость в быстрой проверке гипотез, которые бы сделали функциональность привлекательной (desirable). К сожалению, накопленный за месяцы технический долг теперь жестко ограничивал Владельца Продукта в возможности качественных частых релизов.
Итересно, чем все закончилось? Финал истории: продукт, о котором вы никогда не узнаете, потому что он мертв. Вот так несоблюдение правил Скрама и, в первую очередь, создания готового к релизу инкремента как минимум раз в Спринт — помешали бизнесу взять контроль над рисками и создать успешный продукт.
Чем определяется длина Спринта
Готовый к релизу инкремент тесно связан с длиной Спринта. С точки зрения системного мышления, оптимальная длина Спринта является результатом двух балансирующих петель. Первая из них — объем риска, который берет Владелец Продукта. Чем больше длина Спринта, тем больше объем риска и его стоимость.
Но Скрам понимает, что люди бывают излишне оптимистичными, как в той истории, которой я поделился. Поэтому максимально допустимый объем риска в Скраме — месяц. С другой стороны, длина Спринта ограничивается возможностями Команды Разработки. Уменьшая длину Спринта, транзакционные расходы, скорее всего, возрастают (встречи, ручное тестирование и т.д.). Это снижает эффективность разработки (efficiency) и повышает ее стоимость. Таким образом длина Спринта — договоренность Скрам-команды об отрезке времени, за который бизнес готов брать на себя определенный объем риска, а Команда Разработки может поставить готовый к релизу инкремент как минимум раз в Спринт.
В течение многих лет я, как практикующий Скрам-мастер, толерантно относился к тому, что мои команды не могут за двухнедельный Спринт поставлять готовый к релизу инкремент. И да, мы работали фейковыми Спринтами. Сейчас, когда я начинаю работать с новой командой, мы формируем Definition of Done (DoD) = releasable и начинаем соблюдать его с первого же Спринта. И тогда часто выясняется, что две недели — не самый оптимальный таймбокс. И команды начинают работать Спринтами длиной три или даже четыре недели, потому что накладные расходы слишком велики, чтобы поставлять готовый к релизу инкремент каждый Спринт. В хорошем Скраме команды никогда не жертвуют качеством и прозрачностью артефактов.
Масштабируемый Скрам — тот же Скрам
Мой опыт последних лет связан исключительно с масштабируемой разработкой, когда много команд работают из одного Бэклога Продукта с одним Владельцем Продукта. Меняется ли что-то в этом случае? Мы часто повторяем, что масштабируемый Скрам — всё тот же Скрам.
Независимо от количества команд, продуктовая группа обязана поставлять интегрированный и готовый к релизу инкремент каждый Спринт. Принципы управления рисками и эмпиризм остаются актуальными. И тогда два важных вопроса, которые вы можете задать командам уже завтра, звучат так:
- Исходя из текущего уровня инженерных практик команды, какая должна быть оптимальная длина, если каждый Спринт должен заканчиваться готовым к релизу инкрементом?
- Учитывая, что Definition of Done (DoD) = releasable, какой реалистичный объем работы вы возьмете в Спринт?
Ответы на эти вопросы могут вас удивить.
Основные мысли статьи:
- Спринт фейковый, когда он не завершается готовым к релизу инкрементом.
- Спринт контролирует три вида риска: desirability (привлекательность), feasibility (техническая реализация), viability (монетизация).
- Длина Спринта определяется объемом допустимого риска, который берет на себя бизнес, и способностью Команды Разработки поставить готовый к релизу инкремент.
- Стартуйте с Definition of Done = releasable.
- Масштабируемый Скрам — все тот же Скрам: один Бэклог Продукта, один Владелец Продукта, один готовый к релизу инкремент.
