Scrum-fall
Тема дорожной карты · Agile / Scrum / Kanban
Scrum-fall (или 'Water-Scrum-fall', Forrester 2011) — это наиболее распространённый антипаттерн в области управления проектами и разработки программного обеспечения. Организация придерживается waterfall-планирования ('что мы строим в Q3?') и waterfall-релизов ('релиз раз в полгода'), вставляя Scrum-исполнение посередине. Такой подход часто приводит к тому, что команда не чувствует себя ответственной за весь процесс от начала до конца и не ощущает обещанной скорости разработки, характерной для Agile. Исправление этой ситуации обычно требует изменения окружения команды, а не самой команды.
Как это работает
В Scrum-fall требования приходят большими батчами сверху ('вот спека Q3'), команда разбивает их на спринты, но не может релизить пользователям между батчами и не может влиять на то, что войдёт в следующий батч. Все Scrum-церемонии проходят — Sprint Planning, Daily Scrum, Review, Retro — но команда работает в waterfall-оболочке, которая ограничивает все ключевые аспекты работы. Это приводит к тому, что команда не может эффективно реагировать на изменения и быстро адаптироваться к новым требованиям.
Когда применять
Диагностировать Scrum-fall можно, задав команде три ключевых вопроса: (1) Можем ли мы релизить пользователям в середине спринта, если бы захотели? (2) Можем ли мы влиять на то, что будет включено в Q3-roadmap? (3) Изменился ли roadmap прошлого квартала на основе того, что мы узнали? Если ответы на все эти вопросы 'нет-нет-нет', то у вас Scrum-fall. Команда придерживается Scrum, но организация не внедряет Agile.
Типичные ошибки
Самая частая ошибка — попытка исправить Scrum-fall на уровне команды. Например, Scrum Master усиливает коучинг, команда добавляет дополнительные церемонии, но ничего не улучшается, потому что оболочка не меняется. Для решения этой проблемы необходимо изменить окружающую систему: разрешить midcycle-релизы, дать Product Owner (PO) реальное влияние на квартальные приоритеты, относиться к roadmap как к гипотезе, а не как к обязательству. Без этих структурных изменений команда может делать идеальный Scrum и всё равно чувствовать ограничения.