КЕЙС #17

Подготовительный спринт

Скрам-мастер работает в компании уже пять лет. Это отличный и крупный энтерпрайз, у которого множество интересных клиентов, для которых создаются сложные программные продукты. Команды работают в Скрам уже более двух лет, их Скрам-церемонии, как правило, продуктивны, у спринтов есть четкие Цели, а на выходе большинства из них — Инкременты в состоянии «Готово».

Однако в последнее время в компании появилось довольно много новых внутренних проектов и Скрам-мастер отметил одну вещь, которая сильно его напрягла. На старте таких проектов команды стали планировать то, что часто называют «подготовительным спринтом». Во время него они активно общаются с заказчиком или инициатором проекта, пишут спецификацию, создают архитектурный план и частично разрабатывают первоначальный дизайн. Только когда заказчик утверждает результаты, подписывается договор и выделяются инвестиции на будущие спринты.

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

Эта ситуация уже привела к довольно напряженным переговорам с руководством, которое не против оставить эти «подготовительные спринты». Но сам Скрам-мастер убежден, что в этой ситуации можно найти другой подход.
Будучи Скрам-мастером, какую альтернативу вы бы предложили руководству и своей команде? Какие «подводные камни» у таких спринтов? Как это влияет на способность работать эмпирически?