⚡️ Отказ от Спринтов не решает проблему

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

Часто встречаю призывы отказаться от Спринтов и перейти в «настоящий поток». И каждый раз ловлю себя на мысли, что спор идет совсем не о том.

Я много лет подряд рассказываю про one-piece flow. Если вы давно знаете меня, то знаете, что я всегда выступал за максимально маленький размер работы, быстрый поток и отсутствие очередей. Самый известный пример — кейс СБП c 4х кратным ускорением. Команды работали практически без внутренних очередей. По сути, оставалась одна внешняя очередь — Бэклог Продукта. Поток был настолько быстрым, что Канбан был просто не нужен.

Именно поэтому меня удивляют призывы отказаться от Спринтов. Скрам вообще не говорит, как вам организовать поток работы. Хотите выкатывать изменения десять раз в день — отлично. Хотите делать Continuous Delivery — пожалуйста. Хотите работать по одной задаче за раз — тоже прекрасно.

В Руководстве по Скраму говорится, что Спринт — это контейнер для всех остальных событий. Смысл этих событий очень простой: регулярно остановиться и проверить, приближаемся ли мы к Продуктовой цели (Product Goal). Посмотреть на результаты, обсудить обратную связь, скорректировать Бэклог Продукта и решить, что делать дальше. Вот для чего нужен Спринт.

Спринт — механизм эмпирического контроля. А поток — это способ организовать выполнение работы. Это две разные вещи, которые прекрасно сочетаются друг с другом.

Когда я слышу призывы отказаться от Спринтов ради потока, мне кажется, что люди спорят не со Спринтами. Они спорят с батчингом. И батчинг действительно стоит убирать. А вот регулярную инспекцию и адаптацию я бы точно оставил.

Что думаете?