Уже более года я работаю с клиентами, у которых есть проблемы с масштабированием Agile. Но не тот вид проблем, о котором все говорят: один продукт и множество команд. Нет, всё это время я пытался придумать способ, как быть, если у вас одна команда, которая поддерживает множество продуктов с разными архитектурами, заказчиками, технологиями и прочим. И вот чему мне удалось научиться.

Вернемся к начальному вопросу: как можно избежать данного антишаблона? Позвольте перефразировать вопрос: есть ли у команд альтернатива, если стандартная процедура не срабатывает?

При таком подходе каждый спринт превращается в маленький двух- или четырехнедельный проект, с четко очерченным кругом задач, ясным началом и фиксированной конечной датой (у большинства спринтов период фиксирован). Однако этот подход не так прост, как кажется.

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

Кен, вы в Скраме долгое время, более 10 лет. Это на самом деле совсем иной подход к разработке ПО. Что побудило вас тогда, в те давние годы, перейти от прогнозирующего подхода к эмпирическому?