И нужно ли вообще выстраивать всю работу команды только вокруг него? Мой опыт показывает, что нет.

Scrum часто воспринимают как готовую операционную систему для команды: есть спринт, планирование, дейли, ревью, ретро. Окей, значит, мы работаем правильно.

Но Scrum - не универсальный рецепт.

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

Но бывают ситуации, когда именно Scrum начинает замедлять команду. Например, если вы работаете в быстрорастущем стартапе.

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

Вам нужен результат сейчас.

И здесь может оказаться, что важнее не идеально спланировать следующие две недели, а быстро принять решение, взять задачу в работу и довести её до результата.

Не всегда нужно создавать подробное ТЗ, в котором заранее описана каждая деталь реализации. Иногда достаточно чётко понимать проблему, которую мы решаем, и дать команде возможность быстро найти решение.

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

Именно поэтому в таких условиях Kanban может оказаться более подходящим подходом. Есть задача с высоким приоритетом - команда берёт её в работу. Задача готова? Берём следующую. Приоритет изменился? Меняем порядок. Появилась срочная проблема? Команда может отреагировать на неё без необходимости ждать окончания спринта.

Это не значит, что Scrum плохой, а Kanban хороший.

Это значит, что способ организации работы должен соответствовать контексту. Команда поддержки работает с непрерывным потоком запросов - хорший пример идельного канбан в его естественной среде обитания. Так как команда занимается инфраструктурой и реагирует на инциденты здесь и сейчас. В таком направлении жёсткие двухнедельные спринты могут только мешать.

Продукт находится на ранней стадии и приоритеты меняются каждый день?  Возможно (все зависит от конкретной ситуации), вам нужна более гибкая система работы.

И здесь мы можем вернуться к моему раннему посту о том, какие метрики должен знать продакт? То вы с легкостью поймете, что задавать вопрос: Какой фреймворк мы должны внедрить? И строить вектор развития команды, руководствуясь тооолько жескими фреймворками - плохая идея.

Лучше начать с другого: Как устроена наша работа и что сейчас действительно мешает нам двигаться быстрее?

Посмотрите на скорость принятия решений. -На количество зависимостей. -На частоту изменения приоритетов. -На то, сколько времени проходит от появления идеи до результата для пользователя.

И главное, конечно же, на то, насколько ваша система работы помогает, а насколько начинает ограничивать команду. Потому что иногда команда действительно нуждается в спринтах и планировании.

А иногда ей просто нужно иметь возможность сказать: Это сейчас самое важное. Давайте сделаем это.(Конечно же, просчитав приоритеты по райсу))

Не нужно выстраивать работу вокруг Scrum, Kanban или любого другого фреймворка.

Нужно выстраивать её вокруг контекста и результата.

Иногда это будет Scrum, Иногда - Kanban, а Иногда даже гибрид. Или вообще несколько простых практик без попытки назвать их каким-то фреймворком. Хороший процесс - это не тот, который идеально соответствует скрам гайду из ПМБука. Хороший процесс - который помогает команде создавать ценность, быстро получать обратную связь и принимать решения с той скоростью, которую требует рынок.

А как вы выстраиваете работу в своей компании?